вопрос по openSSL - таймауты и проч.

так ты же сам создаёшь сокет и передаешь его в контекст OpenSSL

https://wiki.openssl.org/index.php/Simple_TLS_Server

ага. только что сам вот нашел…я то думал, что сокет там внутри закопан. спасибо. надо попробовать, сможет ли оно в небуферизованую моду.

должно, один фиг весь сетевой обмен сводится к read/write системным вызовам

У опен SSL есть BIO API (Basic Input Output)

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

https://www.openssl.org/docs/man1.1.0/man3/bio.html

Небуферизируемых сокетов не бывает. Пока не будет собран skb сокет в юзерспейсе ничего не получит. Единственное(кроме non-blocking) что ты можешь сделать - это читать по одному байту, что является оверкилом из-за частых свичей. В non-blocking режиме, как выше было сказано, уже полишь сокет и в memory BIO пишешь данные, но это опять же будет буфер, т.к. openssl нужно получить все байтики для расшифровки сообщения.

Небуферизируемых сокетов не бывает.

я специально указал setsockopt( fhandle, IPPROTO_TCP, TCP_NODELAY, &lflag, sizeof(lflag) ); TCP_NODELAY это отключение вот этого самого - https://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC_%D0%9D%D0%B5%D0%B9%D0%B3%D0%BB%D0%B0

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

Ох хорошо бы.

Ты не понимаешь что это такое. Этот алгоритм собирает пакеты в кучку тогда, когды ты рандомно читаешь и постоянно пишешь мелкие чанки. Он позволяет отправить данные в случае если превышен MTU и если нет наакнутых данных(независимо от размера). Когда ты упираешься в него, то скорее всего ты делаешь что-то не так.

Когда ты упираешься в него, то скорее всего ты делаешь что-то не так.

один я что-ли упираюсь? для того и есть флаг TCP_NODELAY, чтобы все, кто упирается в нагла, в него не упирались. а случаи, когда нагл мешает описаны в разьяснениях к этому флагу.

читаем IBM knowlege base: https://www.ibm.com/support/knowledgecenter/ssw_aix_72/performance/tcp_nodelay_tcp_nagle_limit.html

In AIX®, the TCP_NODELAY socket option is disabled by default, which might cause large delays for request/response workloads, that might only send a few bytes and then wait for a response. TCP implements delayed acknowledgments, as it expects to piggy back a TCP acknowledgment on a response packet. The delay is normally 200 ms.

Most TCP implementations implement the nagle algorithm, where a TCP connection can only have one outstanding small segment that has not yet been acknowledged. This causes TCP to delay sending any more packets until it receives an acknowledgement or until it can bundle up more data and send a full size segment.

Applications that use request/response workloads should use the setsockopt() call to enable the TCP_NODELAY option. For example, the telnet and rlogin utilities, Network File System (NFS), and web servers, already use the TCP_NODELAY option to disable nagle. However, some applications do not do this, which might result in poor performance depending on the network MTU size and the size of the sends (writes) to the socket.

Этот алгоритм собирает пакеты в кучку тогда, когды ты рандомно читаешь и постоянно пишешь мелкие чанки.

это не нагл, это TCP_CORK/TCP_NOPUSH

тут разжевано: https://thoughts.t37.net/nginx-optimization-understanding-sendfile-tcp-nodelay-and-tcp-nopush-c55cdd276765

Не знаю где там разжевано. TCP_CORK это механизм управления буфером из юзерспейса. Он безусловен.

For example, the telnet and rlogin utilities

Да, поэтому лучше использовать Mosh, который основан на UDP.