deathsoft wrote:Простой промышленный протокол - передача данных из компьютера в модем (именно данных а не окманд, уже после того как модемы законектились), данные можно слать непрерывно, пока модем не укажет что его буфер переполнен, при этом абсолютно не важно, с какой скоростью модем разгребает этот буфер и передает его в телефонную сеть (а там и ретрансмиты есть и црц и т.д.).
И что с того? В любом случае - PC реализовывать всё тот же алгоритм - "запрос-подтверждение". RTS-CTS полезен в том и только в том случае, когда длина пакета больше, чем размер буфера модема, например - непрерывный поток данных. Чего в реальности наблюдается крайне редко. По крайней мере, за 8 лет разработки аппаратуры передачи данных, мне ни разу не встретился полноценный модем (GSM, ТЧ, Спутниковй), буфер которого не схавал бы за раз 1.5 - 2 кБайта. Единственное короткобуферное устройство - радиоудлиннители модульного исполнения. Там буфер 16 байт - но это ни фига не "полноценные модемы". И то - сокращаем длину пакета до 16 байт и живём жорошо, поскольку надёжность радиосвязи - оставляет желать лучшего.
deathsoft wrote:Ну и на последок, тото дураки добавили в ethernet протокол спец пакеты для управления нагрузкой rx/tx flow control (в гигабитных картах).
RS232 - это "гигабитная карта" ?)
ИМХО, какого нефритового стержня теоретезировать?
Задача - яйца выеденного не стоит. Так что пляшем от задачи, а не от "гигабитных карт", "марсианских домов" и т.п.
Самый простой способ - передавать пакет (короткий заголовок, данные, CRC) и получать подтверждение - (заголовок, CRC).
Временные затраты - минимальны. Надёжность - максимальна.
А самая главная фишка - что это будет работать одинаково как по 3м проаодкам, так и через два модема, подсоединённые всё по тем же 3м проводкам. Разница - только инициализация модема + дозвон.
Из практики:
Предположим, что данные передаются пакетами по 256байт (ну, скажем для удобства - сектора TRD).
Заголовок и СRC - 5 байт (скажем - адрес источника 1б, приёмника 1б, флаги - 1б, ID пакета - 1б, CRC - 1б).
Т.е. Длина Посылки - 261 байт, длина ответа - 5 байт.
При скорости 19200 цикл запрос-ответ уйдёт (в иделе) время (261+5)/1920 = 0.14 сек
Если пакеты складываются в память - то таймаута 1сек для ожидания ответа - достаточно.
Если пакеты пишутся на диск - просто увеличиваем таймаут - и всё.
По сути получается то самое "управление потоком" - только не модемом (которого может и нет) - а получателем, который точно знает, что готов принять данные и посылает подтверждение.
Ведь подтверждение можно слать не по приёму, а по концу обработки пакета.
Одни плюсы - CRC - гарантия целостности пакета. Подтверждение = разрешение отправки следующего пакета. И никаких лишних проводов. Можно хоть по токовой петле за 5 км слать
ZX-Phoenix.
Pentevo ZX-Evoluton Rev. B (зелёная)
