.net - TCP Socket 两个节点通话时 "flow of events"是什么

Question

关于我之前的问题，Previous Question ，让我试着用通俗易懂的方式来问我的问题(因为我理解的东西是为了问我的问题)。

我正在构建一个 TCP 客户端 <--> 服务器应用程序。

帮助我了解让我的客户端和服务器进行对话的正确事件协议(protocol)(应该是什么)。

我希望能够做什么:

1. 服务器监听。
2. 客户端连接到服务器。
3. 客户端向服务器发送一个字符串。
4. 服务器接收数据

5. 服务器回复(我手动发送 "<ok>" string )

6. 现在，我希望我的客户冷静下来，闲逛，什么都不做，直到我解雇它 send method向服务器发送新数据。

7. 然后我希望服务器接收到所述数据，并重复步骤 5(回复)。

在我的示例中，我使用了 Microsoft 提供的异步套接字示例的代码。我可以发送字符串，我的服务器可以回复。

然后我故意不向服务器发送任何内容，直到我需要(想想聊天应用程序)。当我最终决定向服务器发送数据时，我的客户端套接字发送了数据，但服务器从未收到这个新的传入数据。 (接收从不触发)

我假设服务器在发送 "<ok>" 后仍在等待来自客户端的回调先前数据交换中的字符串。在 "<ok>" 之后我再也没有寄回任何东西，因为我已经完成了我想做的任何工作。 (比如发送“hello”字符串)。

在示例中，客户端和服务器在发送数据后通过回调进行连接，以接收从另一端返回的数据。这是套接字必须的吗？或者这与异步套接字有关？

如果是这样，我是否需要在收到任何数据后立即回复，这并不总是我的本意？我是否必须来回 ping <--> pong 直到我最终完成套接字连接的工作？

我希望我的问题是有道理的。我正在寻求更好地理解当两个节点交谈时“预期”会发生什么......

Answer 1

在一个socket上，发送管道和接收管道是完全断开的，独立的；只要代码编写正确，您就可以完全独立地处理这两者，并且发送和接收之间没有特定的依赖关系 - 您可以只发送，只接收，或者您可以单独发送和接收，而不期望您总是这样做一个然后另一个。在非常简单的场景中，客户端倾向于发送然后接收，而服务器倾向于接收然后发送，但这仅仅是因为这就是请求/响应模式(当客户端发起), 不是因为套接字固有的任何东西。

因此:如果您想做的事情不起作用，则问题出在您的代码中(或您用于通过套接字进行抽象的任何库)。您所描述的可以很好地完成。