recv() function

[MasterDucky]

When does the recv() function stop recieving?

For me its a very important question and i have the impression that nobody really knows it everybody is just giving all kind of hazy answers.

Why am i asking it?

When you send data and you send first the size of the file and then the
data itself sometimes it gets mixed up and the first recieve function gets it both.
(I am talking about two send and two recv functions.)

Now how could this be possible?
Why didnt the first recv function stop recieving after getting the first data sent (which was the size of the file) ?

Because if it didnt stop, it should never stop and it should just hang there forever.

Ok i could managed to fix this with adding Sleep() between the two
send function but its still not normal.

Im just thinking that those writing these functions are not really on top of their games...

[mgrey]

Talking about TCP

1-send() function does not actually send the data. It copies the data into the buffer of the TCP/IP stack. This latter decides what to do with data. User data of multiple send()s might be combined into a single stream, or a single user stream might be divided into multiple streams. It is up to the user to check the return value of send() to see how many bytes have been copied into the TCP/IP buffer.

2-recv() function receives available bytes from TCP/IP stack, limited with the size of user buffer passed to recv(). Once again the user is responsible with checking the return value of recv() function to see how many bytes have been received, or if an error has occured.

Here are two examples :
PC 1 calls send() function 4 times with buffer size 20 each, PC 2 receives 80 bytes in one recv(),
or
PC 1 calls send() once with buffer size 2, PC 2 receives 1 bytes on each recv() call.

If you want further "packetezing" over TCP, you must implement your own protocol on top of it. Please note that TCP is the transport layer, it is up to you to implement the application layer.

[MasterDucky]

Ok, thank you mgrey thats very informative.

But if your two examples are true then TCP/IP looks like a big mess.

So the TCP/IP stack does as it pleases. So how am i suppose to separate data when i dont know
neither the size (gets calculated by the program) nor the data (binary, big garbage)?

Lets say i send the size first, for the recieving side to know the number of chars of the size, i
have to send first the number of chars of the size but for it to know the number of chars of the number of chars... and so on... you get the picture?

Now if you want me to send a delimiter character after every send() what character would that be?

In a binary file every kind of chars are possible.

[Richard.J]

well, this is how TCP works. It guarantees the stream of bytes, i. e. you get the packets in the same order they were sent. It can not guarantee that one call to send() always leads to one call to recv() because packets may be broken by routers on the way (because they are only able to handle a limited size of a packet), packets may be lost in which case they have to be re-sent by the remote site and then there is the Nagle algorithm which should allow for combining packets to reduce the overhead of the packets ...

If you use TCP, you must implement a higher level of the protocol to be able to determine the size of a complete message. A very common approach is to send the size of the message in the first 2 or 4 bytes. If you already received these bytes, you can tell when to stop receiving: that is when you received at least the number of bytes indicated. Please note that you might have received more bytes which means you already received (part of) the next message.
Please don't call this a big mess only because you don't understand it ;-)

HTH,
Richard

[MasterDucky]

Ok Richard thank you!

I was just thinking maybe they could have come up with a more simple solution like
one send = one recv, sounds pretty simple to me :).

>>A very common approach is to send the size of the message in the first 2 or 4 bytes.

That sounds like a good idea, i will try to implement it, thanks. :)