Any benefit to multiple sockets between a server and a single client instance using Boost Beast?

[ryanlandvater]

From what I have read it seems to me that because IO calls to the kernel cannot be execute in a parallel manner, there’s really no benefit to opening multiple separate sockets on different ports between a client and server instance.

For context, working on an application that transmits huge amount of image data between a server instance and a client application for diagnostic image viewing (I use beast for its awesome performance). Because the amount of data is so immense, I’ve been trying to really optimize the amount of data I can push through.

[vinniefalco]

The first thing to try is to do as much work as possible per I/O. That means, you want to transfer large buffers of data. Say, at least one megabyte per I/O call. If you have very many small buffers you should try to combine them into a single BufferSequence, or try copying them into a single, large destination buffer. You will need to measure these approaches.

Are you using HTTP, or Websocket?

[ryanlandvater]

Awesome thank you! And just to help others reading this from our separate email thread, there is no benefit from opening multiple separate sockets on different ports between a client and server instance. It won't improve raw throughput.

I am using websocket as I think the upgraded protocol and ability to push data as it becomes available to the server from disk is most beneficial for this implementation.

If there is packet drop, does that delay the transmission to other clients or does the packet failure and TCP resend get a new spot in the the io_context run queue? As there will be many clients expecting imaging data from each containerized instance, ensuring all do not slow down due to one client's poor connection was another motivation for multiple sockets per client design.

[ashtum]

If there is packet drop, does that delay the transmission to other clients or does the packet failure and TCP resend get a new spot in the the io_context run queue? As there will be many clients expecting imaging data from each containerized instance, ensuring all do not slow down due to one client's poor connection was another motivation for multiple sockets per client design.

TCP packet retransmission (and other low-level tasks like sequence checking) is handled by the operating system's network stack, and they don't directly impact the application.

[ryanlandvater]

Thank you