Multiplex many independent full duplex streams in the same TCP socket

Question

This is probably the strangest question that everyone asks here. I will try to explain this as best as possible.

I need to quickly develop a network application in Java, integrating many old network applications (I already have code for them) and everything works together. Each old application will become a subfunction of the new; the new one is basically a wrapper.

Obviously, each of these applications (which were developed by different people at different times) work differently, with different protocols, with radically different syntax for messages (i.e., some protocols use binary messages, some use HTTP messages, another use XML) and various message order strategies (pipelining, stopping and waiting, etc.).

Fortunately, they are all TCP.

The shell application should work by opening something like 6-7 different sockets on different ports, and this is not good for our network administrators. They only need one connector on one port. Thus, all protocols must crush the same channel.

Is there a clean Java-ready version for multiplexing and demultiplexing many independent full-duplex streams in the same TCP socket , transparent and without problems?

Or is there a simpler solution that I forget about?

EDIT: sub-flows are independent, i.e. there is no possibility of deadlock caused by one subflow waiting for some material to appear from another.

Answer 1

You cannot do this transparently through TCP.

Consider, for example, what happens if your application sends a request through one of the “channels”, which depends on the data that it needs to receive on the other “channel”. If network conditions reduce the number of packets of one of the “channels” in order to cause your TCP connection to stop (due to the TCP window) while waiting for a response, you will actually stop all other “channels” in the same TCP connection, since they share same window and you can get stuck

This would not happen with every channel in the same window.

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