C socket: does send wait for recv to end?

Question

I use blocking C sockets on Windows. I use them to send updates of a data from the server to the client and vice versa. I send updates at a high frequency (every 100ms). Does the send() function will wait for the recipient recv() to receive the data before ending ?

I assume not if I understand well the man page:

"Successful completion of send() does not guarantee delivery of the message."

So what will happen if one is running 10 send() occurences while the other has only complete 1 recv() ?

Do I need to use so some sort of acknowledgement system ?

Solution 1

Lets assume you are using TCP. When you call send, the data that you are sending is immediately placed on the outgoing queue and send then completes successfully. If however, send is unable to place the data on the outgoing queue, send will return with an error.

Since Tcp is a guaranteed delivery protocol, the data on the outgoing queue can only be removed once acknowledgement has been received by the remote end. This is because the data may need to be resent if no ack has been received in time.

If the remote end is sluggish, the outgoing queue will fill up with data and send will then block until there is space to place the new data on the outgoing queue.

The connection can however fail is such a way that there is no way any further data can be sent. Although once a TCP connection has been closed, any further sends will result in an error, the user has no way of knowing how much data did actually make it to the other side. (I know of no way of retrieving TCP bookkeeping from a socket to the user application). Therefore, if confirmation of receipt of data is required, you should probably implement this on application level.

For UDP, I think it goes without saying that some way of reporting what has or has not been received is a must.

Solution 2

If you're sending by TCP, you get guaranteed delivery¹ and the other end will receive the data in the order sent. That might, however, be coalesced together so what you sent as 10 separate updates could be received as a single large packet (or vice versa -- a single update could be broken up across an arbitrary number of packets). This means, among other things, that any ACK of any data implicitly acknowledges receipt of all previous data.

If you're using UDP, none of that is true -- data can arrive out of order, or be dropped and never delivered at all. If you care about all the data being received, you just about need to build some sort of acknowledgement system of your own on top of UDP itself.

¹ Of course, there's a limit on the guarantee -- if a network cable gets cut (or whatever) packets won't be delivered, but you'll at least get an error message telling you that the connection was lost.

Comments

[nos]

You get acks on the TCP layer, but that does not help you if you need acks on the application layer, i.e. if you need to know that a message has been received, you need to implement acks in whatever application protocol you're using.