I have a client/server application that I made using sockets.
The thing is, when I send a command requesting some information and wait for a reply I block untill that reply comes. This makes it harder to implement bidirecional requesting/responde.
Let me explain using one example:
The client can list files in a directory of the server, so I do someting like that in code:
Client code:
1- Send request command: LS /
2- Blocks waiting for the LS responde.
3- Get the file list.
The reason why I did that is that the Client may have to transfer a file, so I do:
1- Send request for transfering a file.
2- Blocks on read() waiting to see if the server accepts
3- Only if it does, send the file.
So it was fine untill I had to add the server the ability to request anything.
In my code, the client can request anything and get blocked waiting for a response.
The server might then send any request command that will make no sense for the responde the client is waiting for. This would screw the conversation.
One resolution I tought is to never block for a response.
I would send a request command, and then come back to wait for ANY request or response from the server, if a response arrives then I would send the file.
So the thing is will I have to add like an ID in each request/response pair to know which response is for which request?
PS: Im pretty lost in how to design a network conversation between hosts and have never read a book about desing patterns for network applications.
PS2: sry my bad english 😉
The thing you are looking for is an application-level
protocolbetween the server and the clients.For your particular case the simplest way is for the server to say upfront what it is going to send next. Say, put a message type byte in front of the message. Say
0means request,1means response, etc. Stick that into aswitchstatement and you are done.It’s a good idea to include message length in that header too, so the receiving code knows how many bytes to fetch from the network to get a complete message.