consider this scenario: client sends packet to server that is 10 bytes long. client immediately sends another 10 byte long server, meanwhile, was doing something and now has decided to recv() stuff from the client (assume both packets make it there) server does this: char buffer[100]; int r = recv(mySocket, buffer, 100, 0); would r be 10 or 20? would buffer have both pakcets in it or only 1?

Did the server check the buffer when the first packet arrived or did it check to see if there were packets in the buffer after both arrived. If it checked the buffer after both packets arrived then both packets are in the buffer. I think my logic is right? I hope? I need to get my head checked.

when using tcp, there is no such thing as packets (well there are but not from the send/recv point of view you get to see while coding). the reality is it depends. if using blocking sockets (i may be wrong on this since i have not looked at them in awhile), the recv() will actually wait till the buffer is completly full before returning. if it just returns when data is avaibible then it will return with whatever the dta avaibible is (3bytes, or 12bytes, or maybe all 20bytes). to further complicate issues when sedning data you will have to create yoru own packet format. bassically a header with len and packet type (you may not need len if the packet size is fixed for the particular packet type) and then the data for the packet. this way you just keep recv() the data (like you are reading a file) and have to parse the packets yourself. be very careful about buffer overflows and malformed packets. so make sure you have a method to resync the data stream (like a packet that contains 4 bytes of 0xFF hex). you should really read the docs on msdn about the send/recv and read everything at http://www.ecst.csuchico.edu/~beej/guide/net/

- groof

yes, server checked after both packets arrived

just for anyone who cares, they are both wrong

the answer to my question would be that buffer would only have 1 packet in it, and the next time u call recv() it would get the other packet

well, solved my own problem, and i didnt want anyone else to get confused

<the> MadProgrammer

Actually, the correct answer is it depends on the protocol being used. If you''re using UDP then send() sends exactly 1 packet and receive() receives exactly one packet. If you''re using TCP, there is no concept of a packet and the protocol doesn''t preserve message boundaries. So one send() can result in multiple receives on the receiving end, or multiple send()s can be received on the receiving end by a single call to receive().

So when using TCP, assuming that send() and receive() are on a one-to-one relationship is incorrect.

oic. i WAS using UDP when i wrote the testing thingy.......

thanks

yeah, you dont use send() with udp you use sendto(), you should better explain yourself next time. i was 100% correct.

sorry, my bad, groof

it turns out you were describing TCP, while i was thinking about UDP

my bad, i should have been more clear