caxapa.ru :: Интересно, насколько тяжким планируется стек? Типа "улучшенный uIP" или "лучше чем в linux"? :-)

LightElf (20.02.2026 01:58, просмотров: 153) ответил OlegPowerC на Таки всем шалем! вопрос по tcp/ip стеку.В течение месяца - двух, хочу выложить его как опенсурс, вопрос про желаемое поведение.

Интересно, насколько тяжким планируется стек? Типа "улучшенный uIP" или "лучше чем в linux"? :-)

По ARP: палка о двух концах. С одной стороны построение записей ARP за счёт данных из входящего пакета упрощает жизнь, снижает бродкастовый трафик и требования к ОЗУ на буферирование (не нужно ждать, пока отработает ARP запрос-ответ). С другой стороны расширяются возможности спуфинга, все-таки контролировать летающие по сети ARP пакеты (на предмет не завёлся ли в сети злодей) гораздо проще, чем контролировать вообще все пакеты. Так что тут хорошо бы иметь выбор хотя бы на этапе компиляции.

А вот обновлять TTL существующим записям ARP при получении соответствующего IP-пакета крайне полезно и относительно безопасно.

По фичам, selective ack конечно круто, но только после корректного partial ack/overlapped segment handling. Его отсутствие у uIP сильно портит жизнь.

Не надо делать мне как лучше, оставьте мне как хорошо

Ответить

- Планируется простой, например сборку фрагментов я сделал - но в итоге удалил. оно избыточно и если правильно делать то выкинь пару а то и все 10 кило на буферы. АРП из входящего у меня разумеется только нужный добавляется (потому что он не добавляется а обновляет время записи). То есть абы кого не пускаем. По TCP только начну оптимизировать - я его написал лет 10 назад - решил доделать до "хорошо" - OlegPowerC(20.02.2026 21:25)
  - Сборка фрагментов в стеке для МК - лишняя сущность. А вот корректную отправку/прием перекрывающихся сегментов в мелком стеке было бы полезно. Я как-то фиксил uIP на эту тему, позволяло резко повысить отзывчивость и TCP почти как у нормального стека работал, не затыкаясь на Delayed ACK. - LightElf(26.02.2026 18:32)

Микроконтроллеры