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

Это как-бы это помягче, не упрощение, а чистый геморрой своими руками . Просто Автор имеет совсем поверхностно-идеалистические представления об TCP/IP. Для начала даже самую общую задачу не сформулировал



Или наоборот - еще бОльшие проблемы из-за TCP.

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

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

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

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

Я хочу не найти готовую халяву, а взять "стартовую точку" повыше... Естественно придётся всё самому дорабатывать и корректировать, онако с чего-то начинать нужно.

Тут, эээ...., дело такое, чем выше точку возьмете, тем в большем количестве мусора придется разбираться, сносить, выносить сор....
Вам хочется быстрее устроить "праздник первого пинга"? Ну так возьмите первое попавшееся под руку.
А для приличного, по любому начинать придется медленно и печально с того-же железа, ибо, не знаю, правда, какая ситуация с STR9xx, но по ~20летнему опыту работы с разнообразнейшии MACами, 99:1, что ничего приличного для высокопризводительных решений, даже для уровня драйвера в интернете нет .

Я себе всё примерно так и представляю, однако, ввиду малого опыта конфигурирования STR912 (а на мой взгляд конфигурирование у него до жути корявое), мне нужно что-то на чём всё править. Т.е. собираюсь взять готовый драйвер, готовый стек (хоть сколько нибудь пригодный для правок), запихнуть в уже существующую программу. Далее первый этап оптимизации - изменение драйвера на свой толк: DMA, прерывания по фрэймам и т.д.
Если при этом у меня не будет стека будут трудности с проверкой этого дела. Снифер конечно поможет, но всё-таки могут выясниться попутно какие-то ограничения на переделку драйвера. Вобщем хотелось бы править "на живую", чтобы не пришлось потом всё переделывать, когда в конце пути выяснится, что изначально в концепции была ошибка где-то...

Так это только оверхед по данным в пакете!!!
По такому подходу вы и можете сделать протокол повер UDP - и все будет просто и бытсро работать!
А в TCP все намного сложнее почитайте про -
медленный старт
алгоритм нагла
выбор размера окна...
таймеры, которые использует TCP

Пожалуй соглашусь всё-таки... буду делать свой протокол поверх UDP. Всем спасибо!