Отмена буферизации на сокете

вообще говоря, это невозможно. если вы про tcp, конечно.
TCP_NODELAY не поможет, вам нужен datagram протокол.

например, SOCK_SEQPACKET.

> вообще говоря, это невозможно.

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

Речь идет о TCP/IP. Как известно, FTP может работать и через одно соединение в passive режиме, интересно как это реализовано.

Мне кажется, что проще просто отключить буфер, тогда send будет подвисать пока не передаст сообщение - то что надо.

Отключение алгоритма Нейгла не помогло, тут дело именно в буферизации.

> Мне кажется, что проще просто отключить буфер, тогда send
> будет подвисать пока не передаст сообщение - то что надо.

не понимаю, о чем вы говорите, о каком буфере?

что бы вы не имели в виду, это работать не будет :)

Под буфером я подразумеваю SO_SNDBUF: setsockopt(sock, SOL_SOCKET, SO_SNDBUF, &optval, sizeof(optval));

Но это не срабатывает ...

> Под буфером я подразумеваю SO_SNDBUF:
> Но это не срабатывает ...

разумеется, это не может работать.

tcp - reliable протокол, он _не_ может работать без
буферизации, мне и в голову не пришло, что вы надеетесь
выставить sk_sndbuf в 0.

подумайте хотя бы о том, что tcp протокол должен повторно
посылать данные, если не придет ack. как минимум это
означает, что эти данные нужно где-то сохранять.

только не надо думать, что у сокета действительно есть
один буфер, в котором все происходит. SO_SNDBUF означает
верхнюю границу для sk->sk_wmem_queued, а это есть сумма
skb->truesize.

Можешь попытатся заюзать T/TCP

это можно былобы сделать только в случае если бы tcp не был таким быстрым и оптимизиравонным.

посланные данные должны храниться до тех пор пока их другая сторона не за-ackает. У тебя всегда должно быть место где эти данные можно временно хранить, если нет места то send может заблокировать и ждать пока появится место

если возникнет мемент когда tcp решит что данные надо переслать(не пришел ack за какое то время), то tcp может например склеить данные с вновь поступившими, тем самым уменьшив реальный трафико обмен(вместо двух пакетов посылается один) - это увеличит производительность tcp

поэтому по сути send() возвращает что данные посланы хотя на самом деле они еще не за-ackаны.

tcp позволяет тебе организовать достоверную доставку данных в достоверном порядке и делает это достаточно оптимизированно

весь остальной контроль(если требуется) за пересылкой данных должен лежать на более верхнем уровне .. то есть ты сам это контролируешь. Помни лишь что контроль доставки повех протокола с контролем доставки это неэфективно