Работа сетей Ethernet с медленными каналами связи, методы сопряжения и конвертации Опции

[Волощенко]

Здравствуйте!
Кто сталкивался с подобной проблемой, когда разные фрагменты сети Ethernet, отстоящие друг от друга на десятки километров, соединены между собой низкоскоростными телекоммуникационными каналами связи типа ИКМ30. Такие каналы используют конверторы и структура канала такая: Ethernet-ИКМ30-Соединительная Линия-ИКМ30-Ethernet, а пиковая скорость передачи равна 64кБит*N, где N=1..30.
Для согласования скорости из Ethernet в ИКМ30, по моему представлению, используются такие методы:
- «шлюза», когда принятые, но еще не переданные пакеты накапливаются в очереди;
- «метод обратного давления», когда во время передачи текущего пакета, прием всех новых пакетов блокируется путем создания коллизий – одновременной передачей из конвертора в сеть Ethernet любого встречного пакета.
Мне нужно найти правильный выход, так как с помощью сниффера Ethereal четко заметил, что новый пакет приходит из Ethernet в конвертор до того, как в ИКМ30 передан предыдущий - а это приводит к отказам. Возможно, здесь есть еще тонкости применения в протоколе TCP/IP.
Хотел бы обменяться мнениями с теми, кто сталкивался с данной проблемой.
Спасибо.

[Krys]

насколько я представляю работу стека протоколов, при переполнении входного буфера вашего узкого горлышка, пакеты канального уровня теряются, никуда не деться. Но выше этого уровня есть транспортный, в частности, протокол TCP. Глубоко не вникал в его работу, но этот протокол должен по количеству недошедших пакетов подстраивать скорость передачи пакетов, чтобы они не терялись и не образовывались задержки, связанные с повторной передачей пакетов.
Я пока начинаю работать над похожей задачей и надеюсь, что так и будет, как я выше описал.
А все перечисленные вами ранее методы бесполезны: если в каналах разная скорость, это обязательно когда-то приведёт к невозможности доставить очередной пакет. Например, метод шлюза работает, пока не переполнится буфер. А потом всё равно пакеты потеряются.
Метод обратного давления приводит к бесполеному "торможению по цепочке". Вообще, коллизии имеют место только в полудуплексном режиме (я работаю с полным дуплексом на гигабитном изернете). В полном дуплексе есть механизм управления потоком, описываемый стандартом IEEE 802.3х (см. тему http://electronix.ru/forum/index.php?showtopic=15533 К стати, я с этим механизмом до конца так и не разобрался, так что был бы благодарен за помощь с русскоязычными текстами, поясняющими его). Что будет происходить: переполнится входной буфер вашего узкого горлышка, он будет оказывать обратное давление (хоть коллизией, хоть через механизм контроля потоков) на стоящее перед ним (по ходу передачи пакета) оборудование канального уровня (в первую очередь, коммутирующее), которое должно приостановить передачу пакета. В этом случае уже в этом предыдущем устройстве начнёт заполняться буфер и переполнится. Он опять должен оказывать обратное давление на предыдущее устройство и т.д. по цепочке. Это всё лишнее, если протокол TCP нормально выполняет свои функции и не даёт переполняться буферам, обеспечивая скорость "на грани"