Home/ Questions/Q 6361871
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-24T23:49:59+00:00

This could probably be the strangest question every asked here. I’ll try to explain

  • 0

This could probably be the strangest question every asked here. I’ll try to explain it the best I can.

I need to rapidly develop a network application in Java, integrating a bunch of old network applications (I already have the code for them) and making everything work together. Each old application will become a sub-function of the new one; the new one is fundamentally a “wrapper”.

Obviously, each of these applications (which have been developed by different people in different times) work in different way, with different protocols, with radically different syntax for the messages (i.e. some protocols use binary messages, some other use HTTP like messages, some other use XML) and different message order strategies (pipelining, stop and wait, etc…).

Fortunately, they are all TCP.

The wrapper application should work opening something like 6-7 different sockets at different ports, and this is not good for our network administrators. They only want one socket on one port. So all the protocols have to crush on the same pipe.

Is there any pure Java, out-of-the-box solution to multiplex and demultiplex many independent full-duplex streams on the very same TCP socket, in a transparent and hassle-free manner?

Or is there a simpler solution I’m forgetting about?

EDIT: the sub-streams are independent, i.e. there’s no deadlock possibility caused by one sub-stream waiting for some stuff coming from another.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You can’t do it in a transparent manner over TCP.

    Consider for example what will happen if your application sends a request over one of the “channels” that depends on data it needs to get on another “channel”. If a network conditions drops enough packets of one of the “channels” to cause your TCP connection to stall (due to TCP window) waiting for response you would in effect be stalling all the other “channels” in the same TCP connection since they share the same window and you can get into a deadlock

    This would not have happen before with each channel in the same window.

    This may or may not affect your specific application – but it might, so this technique is not transparent. You can try using SCTP to overcome this, if possible

    • 0