Winsock End-of-Message Response :: Winsock

Hi.

What is the best solution to knowing when a server or client has sent the final piece of data across a socket?

For example, let say a client sends 100k of data to a server running OVERLAPPED I/O. The I/O model updates the server and tells it there is 50k data ready for to be received. The server calls WSARecv(). Meanwhile the server has not idea the true size of the data. It just knows there is 50k worth of the data. Now OVERLAPPED I/O updates the server the second time with 50k data, which is the last piece of data.

Based on the example scenario, how does the server know when to stop calling WSARecv() because it has processed all data? This is a general question and does not pertain to data. Is it true that web servers sends the final piece of data with something ike this at the end?

-----

0
-----

Thanks,
Kuphryn

There are three main ways:

Attaching a special character or sequence of characters to the end of the data as in your message. This method may tax the server a little more because it must scan received data on every read for the delimiter, and it must be chosen well as not to conflict with actual data.

In the second method, the server knows the total size of the message because it's part of a strict protocol that the client and server use to communicate with one another.

Finally, in many protocols that require variable-sized messages, the client tells the server the length of the data before it is sent or within the message itself. Something like an instant messenger program would send the total length of the string and the actual string all in the same message. This appears to be what you need, as character delimited messages would probably steal some of the speed you uncover from using IOCP, and it looks like all your messages have variables sizes.

One advantage to using the third method is that it's extremely easy to do error checking (since you know what the size should be), and it's easy to determine when to process the data (there are no additional bytes to receive).

Okay. Thanks.

Kuphryn