Всем добрый день.
Около полугода назад была необходимость в поднятии собственного высокопроизводительного и простого TCP\IP стека. Могу поделится своими трудами.
Есть вещи которые стоило бы допилить, но в рамках проекта они были не нужны.
С удовольствием выслушаю критику. А если кто-то захочет допилить мелочи, то отвечу на все вопросы.

Ах, да! забыл сказать стек документирован на русском языке

Подозрительно: кода всего 600 строчек. А все RFC, имеющие отношение к TCP, потянут скорее на 600 страниц. Видимо, этот TCP работает только в очень особых случаях.

смотря что вы называете особыми случаями. Если вас интерисуют DNS запросы, работу через gateway, DHCP - то кончено же нет. А если вас например интерисует передача большого объема данных по протоколу UDP в пределах одной подсети - то это то что надо.
TCP реализован не идеально(огрехи описаны в документации), но опять таки, для моей задачи достигнутой пропускной способности было достаточно.
тот же DHCP например дописать для разбирающегося человека - не проблема, другое дело, что в рамках моей задачи он небыл необходим

По-видимому, повторная посылка в случае потери пакета не реализована. То есть при потере пакета сессия TCP повисает. Если так, то это и есть главное ограничение.

дока в pdf, вместо odt



повторная посылка реализована
основное ограничение tcp - следующий пакет данных не посылается до получения подтверждения. то есть данные будут посылаться повторно до получения подтверждения или сброса соеденения(ACK | RST)

Что-то я там нифига не вижу ни описания, ни примера использования. Так, огрызочек, хотя кое-что можно разобрать.



По поводу высокопроизводительности у меня масса вопросов. malloc там как-то совсем инородно выглядит. Не видать Fast Retransmit и вообще не ясно, как организована работа с подтверждениями и перепосылками.

Собственно говоря, вообще не очень ясен программный интерфейс к собственно стеку, но это к вопросу выше.

Проверки на валидность всех полей в пакетах все-же очень желательна.

Не видно работы с опцией MSS.

Пока писал, появились ответы на некоторые вопросы.



О какой производительности стека может идти речь?

25 Мбит\с

А по UDP - 80 Мбит\с

там ведь все написано

Вы не дочитали описание: предлагается залезть в реестр Windows и отключить Delayed ACK.
Кстати, если я правильно помню, uIP тоже допускает только один неподтверждённый пакет. Там сразу сказано, что это сделано для упрощения и экономии памяти. Здесь, видимо, что-то похожее.

Руки бы отрывал за то, что крутят бездумно эти параметры.



Дочитал. Фтопку.



Это для оправдания рукожопия сделано Или нежелания сделать красиво.



Это не производительность. Нормальный стек дает более 80МБит на TCP.

Если так не делать, то прийдется хранить все время в буффере все неподтвержденные пакеты, что увеличит объем использованной памяти во много раз.
Штука полезная, но мне было проще отключить задержку ACK в WIN


Никто ж не заставляет этот параметр менять) без него скорость падает(точно не помню), но предполагаю, что до 3-5 Мбит\с.

Познавательно меряться размером выходного кода. У меня


Сделан под LPC17xx. Реализован достаточно близко к требованиям RFC; TCP, ICMP, UDP, ARP (упрощенный, без кэша); адекватно работает с отложенными ACK; Fast Retransmit штатно поддерживает только для передачи, можно прикрутить и для приема; практически работает в режиме zero-copy.

Размер каждого TCP-сокета - 49 байт (ну ибо zero-copy).

Программный интерфейс - не bsd-style, а событийный.

Со скоростью там все в порядке

а что не ясно то? отсчет таймаутов идет с помощью systick таймера(описано в документации)
по истечении заданного промежутка времени происходит перепосылка данных используя DMA контроллер МК, чтоб не отнимать время у приложения пользователя. Все по-моему логично

А не надо так делать. Надо генерировать пакеты по необходимости.

У меня в стеке есть три callback'а для режима передачи

SEND - сгенерить новых данных для передачи (не более стольки-то) и вернуть количество сгенеренных данных.
REGENERATE - откатиться на точку последнего подтверждения
ACK - переместить точку последнего подтверждения на сколько-то байт.



В начале out и ack указывают на начало буфера передачи.

На самом деле в реальности там нет memcpy. Это псевдокод для иллюстрации. На самом деле там какой-то циклический буфер, или железка, или еще чего - например, http-сервер в виде машины состояний, который непосредственно печатает в p, а ack и out для него - не более чем состояние.



Да уже все ясно. Однопакетный стек. Тысячи их, uip впереди колонны шагает.