在同一个 TCP 套接字上复用许多独立的全双工流
这可能是这里每个人问的最奇怪的问题。我会尽力解释它。
我需要用 Java 快速开发一个网络应用程序，集成一堆旧的网络应用程序（我已经有了它们的代码）并使所有内容协同工作。每个旧应用程序都将成为新应用程序的子功能；新的本质上是一个“包装器”。
显然，这些应用程序中的每一个（由不同的人在不同的时间开发）以不同的方式工作，使用不同的协议，消息的语法完全不同（即一些协议使用二进制消息，一些协议使用类似 HTTP 的消息，一些协议使用类似消息的 HTTP 消息）。其他使用 XML）和不同的消息顺序策略（管道、停止和等待等）。
幸运的是，它们都是TCP。
包装器应用程序应该在不同的端口上打开 6-7 个不同的套接字，这对我们的网络管理员来说并不好。他们只需要一个端口上有一个套接字。所以所有的协议都必须压在同一个管道上。
是否有任何纯 Java 开箱即用的解决方案能够以透明且轻松的方式在同一个 TCP 套接字上多路复用和解复用许多独立的全双工流？
或者有一个我忘记的更简单的解决方案吗？
编辑：子流是独立的，即不存在因一个子流等待来自另一个子流的某些内容而导致死锁的可能性。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您无法通过 TCP 以透明的方式完成此操作。
例如，考虑一下如果您的应用程序通过其中一个“通道”发送请求，而该请求取决于在另一个“通道”上获取所需的数据，将会发生什么情况。如果网络条件丢弃了其中一个“通道”足够多的数据包，导致您的 TCP 连接停止（由于 TCP 窗口）等待响应，那么您实际上会停止同一 TCP 连接中的所有其他“通道”，因为它们共享同一窗口中，您可能会陷入死锁，
这在以前同一窗口中的每个通道不会发生。
这可能会也可能不会影响您的特定应用程序 - 但它可能会影响，所以这种技术不是透明的。如果可能的话，您可以尝试使用 SCTP 来克服这个问题
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