Стеки TCP/IP с примерами на STR912, OpenTCP, lwIP, тесты производительности Опции

[Pechka]

Здравствуйте! Понадобилось реализовать "быстрый" канал по Ethernet на str912. Нашёл много упоминаний о openTCP, lwIP, даже какие-то тестовые результаты скорости по TCP. Однако нигде не нашёл исходников используемых портов. (общий C код есть, однако хочется с примерами на конкретном железе). Кто может поделиться такими реализациями? (обязательное условие - без операционки).
Заранее благодарю.

[Pechka]

Свой протокол поверх UDP не хочется городить т.к. тогда понадобится писать драйвер для этого сетевого устройства, иначе программисты PC будут ругаться, плеваться и т.д. Хочется что-то стандартное, возможно упрощенное. Да и в целом TCP достаточно удобно сделан для соединений с гарантированой доставкой: вроде бы ничего лишнего. Однако в моем случае можно будет ещё упростить его тем, что пакеты будут приходить в верном порядке.

[KRS]

Да и в целом TCP достаточно удобно сделан для соединений с гарантированой доставкой: вроде бы ничего лишнего.

Конечно! Если у вас пакет проходит по разнородным каналам с разной скоростью и MTU, через маршрутизаторы...
То да - ничего лишнего там нет

[Pechka]

Конечно! Если у вас пакет проходит по разнородным каналам с разной скоростью и MTU, через маршрутизаторы...
То да - ничего лишнего там нет

А какими средствами достигается контроль такой сложной системы? просто номер пакета и ACK. Звучит круто, а реальных накладных расходов на это не так уж и много... Сложно следить сразу за кучей соединений и процессов, которые хотят достучаться до сети, а когда нужно соединение типа точка-точка (но, правда, через некоторое количество коммутаторов), то большинство проблем и накладных расходов не требуется...

[zltigo]

Звучит круто, а реальных накладных расходов на это не так уж и много...

... особенно, когда, например, через многие десятки секунд программисты на PC узнают, что все,что они посылали никуда не дошло.
Ну а на контроллере обратный канал будет забиваться ACK а неподтвержденные придется буферизировать и перепередавать, не забывая о том, что новые сыпятся. Для сколь-нибудь реального времени TCP это хреновое решение и даже не из-за стороны контролера (где можно поработать, хотя Вы хотите готовую халяву ), а из-за стека на PC (хоть Win, хоть Lin) и обработки ошибок на низком уровне, на которую все, начиная с разработчиков драйверов, забили - пусть TCP все разгребает, как может.

[aaarrr]

...из-за стека на PC (хоть Win, хоть Lin) и обработки ошибок на низком уровне, на которую все, начиная с разработчиков драйверов, забили - пусть TCP все разгребает, как может.

Это да. Помнится, лет восемь назад мне очень изрядно попортила кровь реалтековская сетевая карта со своими замечательными драйверами - внутри ethernet-фреймов периодически проскакивали пары нулей: <данные пакета><00 00><продолжение данных пакета>. Стоит ли говорить, что причину возникновения этих нулей я очень долго пытался найти у себя. Случайно только обнаружил, что при подключении к этой карте другого компьютера на нем подозрительно начинает ползти счетчик ошибок контрольных сумм TCP-пакетов.

И ведь действительно разгребает и вытягивает