|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Alex Semenyaka 2:461/640.640 28 May 2007 21:01:46
To : Alex Mogilnikov
Subject : RS232 over IP
--------------------------------------------------------------------------------
28 May 07 13:13, you wrote to me:
AM>>> Hе понял сути проблемы. Что значит "неравномерность", и
AM>>> почему это плохо? Мы говорим об асинхронном RS232?
AS>> Потому что с другой стороны может ожидаться более или менее
AS>> фиксированная скорость поступления данных, которая не будет
AS>> выдерживаться.
AM> Понятно. Да, конечно, если для конечного устройства кричитны
AM> задержки передачи данных, при добавлении задержек сети оно может
AM> перестать работать. Как, впрочем, при добавлении почти любого другого
AM> модема. Стало быть, это устройтсво на работу через модем не рассчитано.
Угу. Сплошь и рядом.
AM>>> Если узким местом является RS232 (его
AM>>> скорость меньше чем пропускная способность TCP), то в направлении
AM>>> RS232 TCP flow control и должен работать (по мере заполнения
AM>>> буфера адаптера).
AS>> Ты о чём? Какой ещё flow control будет работать у TCP, если
AS>> скорость потока ниже, чем имеющаяся прпускная способность?!
AM> Если данные из сети будут поступать быстрее, чем RS232 способен
AM> выдать наружу, буфер адаптера заполнится и TCP будет вынужден
AM> приостановить передачу (закроет окно). И будет это делать периодически в
AM> течение всего сеанса.
Чё?!! Какие данные будут поступать слишком быстро, если RS232 их рождает со
скоростью, меньше пропускной способности сети? Они там плодятся??
AM>>> Если же бутылочное горло находится где-то в сети (TCP не может
AM>>> пропустить поток данных на полной скорости RS232), то flow
AM>>> control будет срабатывать уже на RS232 (периодически он будет
AM>>> синнализировать неготовность приема).
AS>> С чего бы это?
AM> Если данные в порт RS232 поступают быстрее, чем они проходят через
AM> сеть, у адаптера опять же заполнится буфер (уже другой), и он будет
AM> вынужден приостановить прием в RS232 (сбросить CTS) до появления
AM> свободного места в буфере.
С чего бы первый RS232, который по TCP связан, перестал чего-то передавать? Как
flow-control RS232 на flow control TCP ложится? Да никак.
AS>> У получателя нет способа отличить задержку из-за
AS>> перепосылки пакета от отсуствия данных.
AM> Согласен. Только не понял, к чему ты это сказал.
К тому, что flow control TCP может приводить к неверной интерпретации потока со
стороны получателя.
AS>> Из-за потери пакета поток затормозился, и данные после
AS>> восстановления поступают с задержкой, на которую приёмник вовсе не
AS>> расчитывает - это нормально?
AM> Hенормально. Hенормально для приемника, который жестко завязан на
AM> задержки передачи. Бывают, конечно, случаи, когда задержки недопустимы,
AM> но вряд ли в таких случаях кто-то станет использовать интернет как среду
AM> передачи. Как и асинхронный RS232, впрочем...
А разве речь шла про _интернет_?? Задача более типична для интранета. Hо вот
потери в нём не исключены. И пусть лучше потеря на уровне IP станет просто
как-бы-ошибкой-RS232 (который сам по себе незащищён ни от чего, и готовность к
ошибкам уровнем выше должна быть всяко), чем она приведёт к неверной
интепретации потока.
AS>> Если ты так считаешь, то ты, наверное, никогда не решал задач
AS>> управления оборудованием.
AM> :) Я второй десяток лет зарабатываю этим на жизнь.
Круто.
Alex
--- IMHO в последней инстанции
* Origin: ...можжевеловых... (2:461/640.640)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
