TCP Socket What is the "flow of events" when two nodes talk

Question

Relating to my previous question here, Previous Question, let me try to ask my question in laymen's terms (As I understand things in order to ask my question).

I am building a TCP client <--> server app.

Help me to understand what the correct protocol of events (should be) for my client and server to have a conversation.

What I expect to be able to do:

1. Server listens.
2. Client connects to server.
3. Client sends a string to server.
4. Server Receives data

5. Server replies back (I manually send an "<ok>" string)

6. Here now, I expect my client to chill, hang out and do nothing until I fire it's send method to send new data to the server.

7. I then expect the server to receive said data, and repeat step 5 (Reply).

In my example, I am using code for the asynchronous sockets example provided by Microsoft. I can send the string and my server can reply back.

I then intentionally don't send anything back to the server, until I need to (think chat application). When I eventually decide to send data to the server, my client socket sends the data, but the server never receives this new incoming data. (Receive never fires)

I am assuming the server is still waiting for the callback from the client after it send the "<ok>" string in the previous data exchange. I never did send anything back after the "<ok>", as I was done doing whatever work I wanted to do. (Like send a "hello" string).

In the example the client and server are wired with a callback after sending data, to receive data back from the other side. Is this a must for sockets? Or is this something to do with Asynchronous sockets?

If so, do I need to reply back immediately after receiving any data, which is not always my intention? Do I have to ping <--> pong back and forth untill I eventually have work for the socket connection to do?

I hope my question makes sense. I am looking for a better understanding as to what is "expected" to happen when two nodes talk...

Answer 1

On a socket, the send and receive pipes are completely disconnected and independent; as long as the code is written correctly, you can process both completely independently, and there is no specific dependency between sends and receives - you can be send only, receive only, or you can send and receive separately without any expectation that you always do one then the other. In very simple scenarios, clients tend to send then receive, and servers tend to receive then send, but this is merely because that's the request/response pattern (when client-initiated), not because of anything intrinsic to sockets.

So: if what you want to do isn't working, the problem is somewhere in your code (or whatever library you are using to abstract over the socket). What you describe can be done just fine.