与 1 个套接字的双向通信 - 如何处理冲突？
我有一个应用程序。由“经理”和“工人”组成。目前，工作人员总是发起连接，向经理说些什么，然后经理将发送响应。
由于经理和工作人员之间有很多通信，我正在考虑在两者之间打开一个套接字并进行通信。我还希望发起双方的互动——让经理可以随时对员工说些什么。
然而，我对如何处理“冲突”有点困惑。比如说，经理决定对工人说些什么，同时工人也决定对经理说些什么。会发生什么？遇到这样的情况应该如何处理呢？
PS 我计划使用 Netty 进行实际实现。
I have one app. that consists of "Manager" and "Worker". Currently, the worker always initiates the connection, says something to the manager, and the manager will send the response.
Since there is a LOT of communication between the Manager and the Worker, I'm considering to have a socket open between the two and do the communication. I'm also hoping to initiate the interaction from both sides - enabling the manager to say something to the worker whenever it wants.
However, I'm a little confused as to how to deal with "collisions". Say, the manager decides to say something to the worker, and at the same time the worker decides to say something to the manager. What will happen? How should such situation be handled?
P.S. I plan to use Netty for the actual implementation.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
“我还希望发起双方的互动——让经理可以随时对员工说些什么。”
简单的回答。不。
学习现有协议：拥有客户端和服务器。事情会顺利进行的。 Worker可以是服务器，Manager可以是客户端。经理可以提出许多要求。工作人员在请求到达时对其做出响应。
点对点可能很复杂，但复杂性没有真正的价值。
"I'm also hoping to initiate the interaction from both sides - enabling the manager to say something to the worker whenever it wants."
Simple answer. Don't.
Learn from existing protocols: Have a client and a server. Things will work out nicely. Worker can be the server and the Manager can be a client. Manager can make numerous requests. Worker responds to the requests as they arrive.
Peer-to-peer can be complex with no real value for complexity.
我会在服务器和客户端之间建立持久的双向通道。
如果您只有一个服务器和一个客户端，那么就不存在冲突问题...如果服务器接受连接，它就知道它是客户端，反之亦然。两者都可以在同一个套接字上读取和写入。
现在，如果您有多个客户端，并且您的服务器需要专门向客户端 X 发送请求，那么您需要握手！
当客户端启动时，它会连接到服务器。一旦建立该连接，客户端就将自己标识为客户端 X（握手消息）。服务器现在知道它有一个向客户端 X 打开的套接字，并且每次需要向客户端 X 发送消息时，它都会重用该套接字。
幸运的是，我刚刚编写了关于这个精确问题的教程（包括示例项目）。使用 Netty！ :)
这是链接： http://bruno.linker45 .eu/2010/07/15/handshaking-tutorial-with-netty/
请注意，在此解决方案中，服务器不会尝试连接到客户端。连接到服务器的始终是客户端。
如果您考虑每次要发送消息时打开套接字，则应该重新考虑持久连接，因为它们避免了连接建立的开销，从而将数据传输速率加快了 N 倍。
I'd go for a persistent bi-directional channel between server and client.
If all you'll have is one server and one client, then there's no collision issue... If the server accepts a connection, it knows it's the client and vice versa. Both can read and write on the same socket.
Now, if you have multiple clients and your server needs to send a request specifically to client X, then you need handshaking!
When a client boots, it connects to the server. Once this connection is established, the client identifies itself as being client X (the handshake message). The server now knows it has a socket open to client X and every time it needs to send a message to client X, it reuses that socket.
Lucky you, I've just written a tutorial (sample project included) on this precise problem. Using Netty! :)
Here's the link: http://bruno.linker45.eu/2010/07/15/handshaking-tutorial-with-netty/
Notice that in this solution, the server does not attempt to connect to the client. It's always the client who connects to the server.
If you were thinking about opening a socket every time you wanted to send a message, you should reconsider persistent connections as they avoid the overhead of connection establishment, consequently speeding up the data transfer rate N-fold.
我认为你需要阅读套接字......
你并没有真正遇到这些问题......除了如何响应地处理接收和发送之外，通常这是通过线程化你的通信来完成......取决于在应用程序上，您可以采取多种方法来实现此目的。
I think you need to read up on sockets....
You don't really get these kinds of problems....Other than how to responsively handle both receiving and sending, generally this is done through threading your communications... depending on the app you can take a number of approaches to this.
brunodecarvalho 的回复中提到的 Handshake/Netty 教程的正确链接是 http://bruno.factor45.org/blag/2010/07/15/handshaking-tutorial-with-netty/
我会将其添加为对他的问题的评论，但我没有这样做所需的最低声誉。
The correct link to the Handshake/Netty tutorial mentioned in brunodecarvalho's response is http://bruno.factor45.org/blag/2010/07/15/handshaking-tutorial-with-netty/
I would add this as a comment to his question but I don't have the minimum required reputation to do so.
如果您想重新发明轮子并且不想使用中间件...
设计您的协议，以便其他对等方对您请求的答复始终能够轻松地区分来自其他对等方的请求。然后，仔细选择您的网络 I/O 策略。无论什么代码负责从套接字读取数据，都必须首先确定传入的数据是否是对已发送数据的响应，或者是否是来自对等方的新请求（查看数据的标头，以及您是否已发出请求）最近）。此外，您需要保持适当的排队，以便当您发送对对等方请求的响应时，它可以与您发出的新请求正确分开。
If you feel like reinventing the wheel and don't want to use middleware...
Design your protocol so that the other peer's answers to your requests are always easily distinguishable from requests from the other peer. Then, choose your network I/O strategy carefully. Whatever code is responsible for reading from the socket must first determine if the incoming data is a response to data that was sent out, or if it's a new request from the peer (looking at the data's header, and whether you've issued a request recently). Also, you need to maintain proper queueing so that when you send responses to the peer's requests it is properly separated from new requests you issue.