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

[Волощенко]

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

[Волощенко]

Схема организации связи такая: Я отключаю свой компьютер от локальной сети, и ставлю два конвертора, так, чтобы между собой они были связаны по Е1, а каналами Ethernet подключались один к сети, а другой к моему компьютеру. При использовании 4 канальных интервалов (КИ) - пиковая скорость 256 kbit/s, с большим числом КИ в Е1 я пока еще не успел поработать. Экспериментировал с DounLoadMaster, загружая с Интернета pdf-файлы размером по 1Мбайт (используя при этом 4 КИ). DounloadMaster показал здесь пиковую скорость 8кбайт/с (т.е. 64 kbit/s), и загружал этот файл за время около 4 мин (здесь сетевая скорость 10Мбит/с). Таким образом, средняя скорость была около 30 kbit/s, в восемь раз ниже пиковой для 4-х КИ. Конечно, были потери, так как при детальном просмотре через sniffer, были видны сообщения типа:"TCP Previous segment lost", "TCP Retransmission". Так что черепашка действительно еще где-то зарыта.
Для справки этот же файл загружался напрямую, через сеть за 4 сек (без моего конвертора, при скорости в сети 100Мбит/с и с пиковой скорость до 500кбайт/с ).
Вопросы остались: Почему не удается связаться через конверторы с соседними компьютерами локальной сети предприятия? На ping они отвечаю без проблем, а вот просмотреть содержимое с помощью Windows Commander – не удается (хотя без конверторов это получается). Может сетевое управление осуществляется по другим протоколам, для которых транспортная задержка через конверторы является критической?

[zltigo]

Может сетевое управление осуществляется по другим протоколам, для которых транспортная задержка через конверторы является критической?

Задержка - нет, а потери смертельны.