java网络编程消息传递的协调

Question

我有 2 个进程运行在不同的机器上，它们通过 TCP 套接字进行通信。
这两个进程都有既充当服务器又充当客户端的代码。
即 ProcessA 打开了一个绑定在 portX 的服务器套接字，ProcessB 打开了一个绑定在 portY 的服务器套接字。
ProcessA 打开客户端套接字以与 ProcessB 连接并开始作为客户端发送消息 并接收响应（当然是通过相同的 TCP 连接）。
ProcessB 一旦接收到消息并对其进行处理，它就会发送响应，但也可以通过第二个 tcp 连接发送消息，即 ProcessB 已打开到 ProcessA 的 portX 的客户端套接字。
因此消息流通过 2 个不同的 TCP 连接进行。
我的问题如下：理所当然地认为这种“架构”不能改变并且必须保持原样：
我遇到的问题是，消息间歇性地通过 ProcessB 打开客户端套接字的 tcp 连接从 ProcessB 发送到 ProcessA，在消息通过 ProcessA 作为客户端连接的 tcp 连接作为响应从 ProcessB 发送到 ProcessA 之前到达 processA套接字。
即两个流程都发生

(1)  
ProcessA ---->(msg)----> ProcessB(PortY)  (TCP1)
ProcessB does processing   
ProcessB(portY)--->(response)----->ProcessA (TCP1)  
ProcessB--->(msg)----->ProcessA(portX)  (TCP2)

(2)  
ProcessA ---->(msg)----> ProcessB(PortY)  (TCP1)
ProcessB does processing   
ProcessB--->(msg)----->ProcessA(portX)  (TCP2)
ProcessB(portY)--->(response)----->ProcessA  (TCP1)

编辑（在 ejp 请求之后） 在从 ProcessB 的服务器 portY 作为回复发送的消息到达 processA 之前，如何强制/确保 ProcessB 不会通过 ProcessB 有一个向 ProcessA 的服务器 portX 打开的客户端套接字的连接发送消息？即只有上述流程（1）。
请注意，processB 是多线程的，并且处理过程并不简单。

更新： 可能这是我的误解，但是当进程通过套接字发送数据并将控制权返回给应用程序时，这并不意味着接收方已收到数据。 那么，如果一个进程通过 2 个套接字发送数据，操作系统是否存在竞争条件？

更新2
我从维杰·马修那里得到答复后：
如果我按照建议进行锁定，是否可以保证操作系统（即IP层）将按顺序发送数据？即完成一次传输，然后发送下一次？或者我会将它们复用并遇到相同的问题？

谢谢

Answer 1

显而易见的解决方案是：

LockObject lock;

ProcessA ---->(msg)----> ProcessB(PortY)

// Processing the request and sending its response 
// makes a single transaction.
synchronized (lock) {
    ProcessB does processing   
    ProcessB(portY)--->(response)----->ProcessA (TCP1)
}

// While the processing code holds the lock, B is not
// allowed to send a request to A.
synchronized (lock) {
    ProcessB--->(msg)----->ProcessA(portX)  (TCP2)
}

Answer 2

同步问题可能不在于 TCP 协议，而在于线程处理程序选择消息到达时唤醒哪个线程。我从你的问题的性质了解到，PortX“（消息）”在 PortY“（响应）”之后很快发送。这意味着线程处理程序有时可以选择要唤醒两个侦听线程中的哪一个。

解决该问题的一种简单但丑陋且不完整的方法是在响应和下一条消息之间插入短暂的睡眠。睡眠时间必须足够长，才能确信其他进程在收到下一条消息之前已经醒来并收到响应。这种方式是不完整的，因为尽管您正在增加正确同步处理的更改，但操作系统负载和网络拥塞等问题总是会共同将您的消息推回到您的响应之后。然后你又回到了起点。另一件丑陋的事情是，睡眠会浪费时间，并且会降低你的最大吞吐量。只是频率比较低而已。所以...

为了彻底解决这个问题，您需要某种方式让每个套接字侦听器知道它刚刚收到的消息是否是下一个要处理的消息，或者是否可能有必须先处理的较早消息。为此，请按顺序对每个进程发送的所有消息进行编号。然后接收进程就知道是否缺少任何东西。

您必须想出一种方法，让每个套接字上的侦听器在它们之间进行协商，以确保收到的消息按传输顺序进行处理。有许多实用的解决方案，但它们在抽象、概念层面上都是同一件事。

线程 1：
A) ProcessA(PortX) 线程收到消息并唤醒。
B) 如果序列号表明有消息丢失，则
B1) 在 ProcessA(PortY) 上同步并 wait()。
B2) 醒来后，回到B)
C) {没有消息丢失} 处理消息。
D) 回到 A)

线程 2：
A) ProcessA(PortY) 收到响应并唤醒。
B) 处理响应。
C)notifyAll()。
D) 回到 A)

最通用的实际解决方案可能涉及单个套接字侦听器实例，将所有新消息添加到 PriorityQueue，以便最早发送的消息始终到达队列的头部。然后，线程 1 和线程 2 都可以等待该实例，直到它们可以处理的消息到达。

一个更简单但可扩展性较差的解决方案是让每个线程自己进行侦听和等待，并在处理后通知（响应）处理程序。

祝你好运，尽管经过这么长时间，它可能已经解决了。

Answer 3

显而易见的问题是你为什么关心？如果您有需要在任一端同步的操作，请执行此操作。不要指望 TCP 会为你做这件事，这不是它的用途。