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.