I am writing a protocol in Boost::ASIO which has the following requirements:
Are there additional TCP socket flags or Boost::ASIO settings I should use?
socket_.set_option(boost::asio::ip::tcp::no_delay(true)); // enable PSH
socket_.set_option(boost::asio::socket_base::keep_alive(true)); // enable SO_KEEPALIVE
socket_.set_option(boost::asio::detail::socket_option::integer<SOL_TCP, TCP_KEEPIDLE>(120)); // secs before keepalive probes
socket_.set_option(boost::asio::detail::socket_option::integer<SOL_TCP, TCP_KEEPINTVL>(10)); // interval between keepalive
socket_.set_option(boost::asio::detail::socket_option::integer<SOL_TCP, TCP_KEEPCNT(5)); // failed keepalive before declaring dead
TL;DR - The protocol will handle what is called "thin streams" and they are quite well documented, if my answer will not be enough. The biggest advantage should come from no_delay(true)
and async
reads/writes (for normal operation) and dupACK and linear timeouts (for failure-recovery). For more details (including static/server TCP options) and additional remarks see below.
In general I would go about choosing these options by considering the following:
Having chosen the underlying protocol on which I want to build - investigate tuning options 4 that protocol. For TCP those are:
Not surprisingly, SSR can have a significant impact on performance of long-lived TCP connections that may idle for bursts of time — e.g., due to user inactivity. As a result, it is generally recommended to disable SSR on the server to help improve performance of long-lived HTTP connections.
Taken from here. The option: sysctl -w tcp_slow_start_after_idle=0
tcp_thin_dupack
should be ON. It reduces the time a sender waits before re-transmitting a lost segment. Be careful to read and experiment with the precautions (can be specified per socket, see point immediatelly below).tcp_thin_linear_timeouts
- this allows for faster recovery on packet loss, it can be specified per socket: https://nnc3.com/mags/LJ_1994-2014/LJ/219/11180.html
TFO_FASTOPEN
(TFO): - shortens the initial connection establishment. Not very applicable for long lived connections, but could be considered. Some infrastructure details that the application should handle or the protocol documentation could specify.
If your protocol is tuned for telnet like communication, you can see this telnet implementation. Basically it's full of async writes and reads: https://lists.boost.org/boost-users/att-40895/telnet.cpp
Some nice reads:
https://www.extrahop.com/company/blog/2016/tcp-nodelay-nagle-quickack-best-practices/ https://sourceforge.net/p/asio/mailman/asio-users/?page=257 - for additional help.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With