Как заставить linux,epoll передавать управление программе после каждого полученного tcp сегментa?

ТС пытается строить логику прикладного уровня, основываясь на логике транспортного уровня (TCP) - это бред

Мне кажется, что он просто латентность хочет снизить. Но тут, мне кажется, либо низкая латентность, либо мониторить 5к сокетов одновременно — придётся выбрать что-то одно.

ТС, если у тебя реально серьёзная задача с серьёзными требованиями к latency (и, желательно, серьёзным бюджетом:) — то тебе нужно либо писать кастомный модуль для ядра (в духе ядерных веб-серверов и т.п.), либо пилить что-то на DPDK.

Нужно простого - чтобы вагончики в алгоритм попадали с частотой их отправки 70мкс по одному, а не паровозиком по три-четыре штуки и с задержкой 210 и более мкс.

конечно я разделю паровозик на вагончики,но суть еще в том что для принятия решения мне нужно лишь два первых tcp сегмента последовательности из четырех (а не весь состав).

В таком случае тебе нужна отдельная физическая линия, на которой будут только отправитель и получатель, и свой протокол. ip здесь не подойдёт.

Ничего у него не потеряется, у него локалка и она не перегружена ничем (речь же про микросекундные тайминги). Узкое место - ОС/софт на приёмнике, проблема только в нём.

ip тут ничем не мешает.

Если у него локалка, которая не перегружена ничем, пусть плюётся udp-датаграммами, а не хотеть странного.

f-stack попробуй.

интересно даже получится/нет

Он вообще нужен только при одновременной работе минимум с сотнями сокетов

А что тогда ему на замену? Скажем у нас ~ 2-10 соединений.

Я так понимаю, у ТС проблема не в самой склейке сегментов данных в один большой. А то, что возникает непонятная задержка неизвестно где, и успевает прийти ещё один сегмент, до того, выгребли предыдущий. Мне вот интересно, а что TC думает о io_uring?

нет

у ТС проблемы в понимании работы сети

и он хочет получать сообщения в том же размере, как их и отправили

и поэтому решил что в идеальной ситуации когда сегмент=отправленное сообщение

у него будет абсолютно всегда

плюс у ТС видимо все это крутиться в одном ивент лупе

поэтому он хочет все последовательно обрабатывать

и когда epoll или recv висит изза того что это TCP

ТС хочет уже прерваться и делать обработку дальше

вообщем трешь полный

кто то явно собеседуется на позицию HFT/трейдинг или мониторинг чего то

можно ему посоветовать сразу искать другую вакансию

А что тогда ему на замену? Скажем у нас ~ 2-10 соединений.

poll или select. Или вообще делать по отдельному потоку на каждый и использовать блокирующий i/o

А сколько времени тратится на обработку после пробуждения? Замеры делались? Микросекунды - это очень мало. Это масштаб времени на котором у многих операций время выполнения уже нельзя считать «условно нулевым».

poll или select.

Разница условная.

по отдельному потоку

Но тогда это будет многопоточка со всей болью и BDSM, характерной для неё.

Но тогда это будет многопоточка со всей болью и BDSM, характерной для неё.

Смотря сколько нужно взаимодейтсвия между потоками. Если мало, то мало и боли. Как вариант — использовать многопроцессность (perfork) с обменом данными через потоки ввода/вывода и пайпы, такой код обычно проще многопоточки.

При использовании libpcap задержки между tcp сегментами получились

первая посылка 4 х tcp сегментов

timestamp 7: 504500.183044

timestamp 8: 504500.183051

timestamp 9: 504500.183053

timestamp 10: 504500.183054

вторая посылка 4 х tcp сегментов

timestamp 5: 504509.084040

timestamp 6: 504509.084046

timestamp 7: 504509.084048

timestamp 8: 504509.084050

«.» отделяет секунды от микросекунд.

timestamp - ы складываю в массив по совету firkax, чтобы исключить задержки printf.

Но все равно вопросы остаются. Почему в tcpdump файле между сегментами по 70мкс,а использование libpcap дает задержки единицы мкс. )) это конечно слегка удивительно. надо осознать)).

посылка - в смысле «принятая посылка»

Кстати, для тех, кто считает микросекунды. А что ТС думает о сырых пакетах и режиме PACKET_RX_RING (Create a memory-mapped ring buffer for asynchronous packet reception.) Может это ему поможет уменьшить драгоценные микросекунды?

https://www.kernel.org/doc/Documentation/networking/packet_mmap.rst

Я правда, сам таким не пользовался, не знаю, поможет оно или нет.

1. Насколько серьезна задача? Есть возможность использовать kernel-bypass сетевую карточку?

2. Привязан ли поток к ядру процессора?

3. Изолировано ли ядро процессора?