0

I'm looking at the source code for a client - server program that communicates using TCP sockets. 5 connections are used to communicate, named very_slow, slow, medium, fast and very_fast. A socket is chosen based on the size of the message being sent. I believe this is done so that messages containing only a few bytes don't have to wait in a queue of larger messages to finish before they are sent.

This design seems to work fine, but it got me wondering if there is any other way of achieving the same functionality (i.e. messages getting assigned a priority based on its size, or any other factor) using only a single connection?

Improve this question

1 Answer 1

Reset to default
2

There are a lot of details to consider in evaluating the effectiveness of the 5-socket approach and whether a single socket can have equivalent behavior.

First, look at the existing system:

  • Is the server process single-threaded? If yes, it can only make scheduling decisions when it has completed a message, so processing of a large message will still delay handling the smaller messages.

  • Can the client have multiple outstanding messages which might be processed in a different order, or may only messages from different clients get prioritized treatment?

  • Is network throughput an issue, i.e. is it the transfer of the large messages that holds up smaller ones, or is it the processing within the server?

Once you know how the existing system actually behaves (which may be different from the intended behavior underlying the 5-socket design) you can look at possible alternative solutions and see how well they meet expectations.

A possible server architecture would be to have one incoming socket (which means one connection per client,) a container for unprocessed messages, and a receive process or thread which reads messages from client connections and puts them into the container. One or several worker processes or threads pick messages from the container according to some schedule (for example, you may have workers which preferrably process smallish messages, and workers that pick large messages so that they are not starved, etc.)

Clients may opt to open another connection to the socket when they are multi-threaded, and one thread is currently occupied with a huge message that may take considerable time to transmit. The new socket may allow a message to overtake the huge message in transit, and get a response from the server even before the huge message has even be completely sent.

Improve this answer
3
  • In this case both the server and the client are multi-threaded (one thread sending and receiving on each socket). The client can also have multiple outstanding messages. On the last point I'm not quite sure to be honest. It seems like you are saying that there may be good reasons for using 5 sockets instead of 1. My intuition was that any scheduling og prioritization issues could be solved by using one socket and just adding metadata to the message, but I don't really have the experience to judge. Thanks for your feedback! Commented Nov 21, 2019 at 11:01
  • I was thinking that maybe the authors of the code intended that some sort of QoS should be used, maybe assigning different priorities to the ports. I'm not even sure if this is possible though. Commented Nov 21, 2019 at 11:03
  • Are the original authors available somehow? Or have they left design documentation including measurements to back up their design decision? They might be better prepared to answer for example whether a single-socket solution would have inherent problems that you and I fail to see at the moment. Commented Nov 21, 2019 at 14:14

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.