Socket producer consumer design
I have a chat server that responds to requests such as messages, files uploaded from the remote host and so on. This is a TCP server.
Design is 1 producer 1 consumer.
The producer is a worker thread, the consumer is the GUI thread.
Remote host when sending data, say a file, it keeps sending it in chunks continuously, ie, not waiting for an app level ACK back from the server to send another chunk.
Currently I use PostMessage to the GUI thread to consume the data received by the worker thread. Now, because of the way this is designed, (No app level ACK back from the server before another send from remote host), I must not issue another socket read until the data is consumed by the GUI thread. The GUI thread then resumes the socket read after it processes the data. This is all done in a single receiving buffer. That is, not a buffer per message type.
I have some questions:
Is this the correct design or should I use SendMessage from the worker thread to the GUI thread so that the worker thread blocks until data is processed then issue another socket read immediately after SendMessage?
I also thought about continue using the PostMessage mechanism but add an app level ACK to request for another chunk of the file (So that I can issue another socket read without waiting for data consumption since I now have the control of when the next chunk should be sent from the remote host)
Are there any better suggestions about this design?
Design is 1 producer 1 consumer.
The producer is a worker thread, the consumer is the GUI thread.
Remote host when sending data, say a file, it keeps sending it in chunks continuously, ie, not waiting for an app level ACK back from the server to send another chunk.
Currently I use PostMessage to the GUI thread to consume the data received by the worker thread. Now, because of the way this is designed, (No app level ACK back from the server before another send from remote host), I must not issue another socket read until the data is consumed by the GUI thread. The GUI thread then resumes the socket read after it processes the data. This is all done in a single receiving buffer. That is, not a buffer per message type.
I have some questions:
Is this the correct design or should I use SendMessage from the worker thread to the GUI thread so that the worker thread blocks until data is processed then issue another socket read immediately after SendMessage?
I also thought about continue using the PostMessage mechanism but add an app level ACK to request for another chunk of the file (So that I can issue another socket read without waiting for data consumption since I now have the control of when the next chunk should be sent from the remote host)
Are there any better suggestions about this design?
The non blocking is preferable.
Normally it suffice to confirm a successful transmission at the end so that the sender knows that it was successful.
It is usually safer to rerun the whole transmission on fail instead of parts of it.
What you need to do is making sure that the chunk comes from the original sender and identify at least the position.
There is no guarantee about the data you receive from the internet...
Normally it suffice to confirm a successful transmission at the end so that the sender knows that it was successful.
It is usually safer to rerun the whole transmission on fail instead of parts of it.
What you need to do is making sure that the chunk comes from the original sender and identify at least the position.
There is no guarantee about the data you receive from the internet...
| The non blocking is preferable. |
I forgot to mention that the socket is operating in non-blocking mode as well.
I hoped to use a blocking notification mechanism like SendMessage to the GUI thread as this is easier to manage than using a PostMessage then pause the read of socket while the data is being processed.
| Normally it suffice to confirm a successful transmission at the end so that the sender knows that it was successful. |
I have seen some open source softwares use an app level ACK for each chunk. Doesn't that create an unnecessary overhead?
| What you need to do is making sure that the chunk comes from the original sender and identify at least the position. There is no guarantee about the data you receive from the internet... |
Good point. I have some kind of authentication of the remote side so there is a verification of the data before processing it.
Last edited on
Sorry for the late reply...
Normally Post is better since you are faster when it comes to receiving data. It depends of course on your implementation.
Sending the data in chunks is usually for low performance speed/memory devices. It mainly slows down the communication.
| I hoped to use a blocking notification mechanism like SendMessage to the GUI thread as this is easier to manage than using a PostMessage then pause the read of socket while the data is being processed. |
| I have seen some open source softwares use an app level ACK for each chunk. Doesn't that create an unnecessary overhead? |
Registered users can post here. Sign in or register to post.