INFO: Avoid Data Peeking in Winsock
Winsock applications that use one of the peek methods, with eitherrecv/WSARecv(..., MSG_PEEK) or ioctlsocket(FIONREAD, ...), to obtain theamount of data in the receive buffer is highly inefficient because thesystem must lock the data and count it. As the system does this, it islikely that the real-time network will still attempt to fill the bufferwith more data. Peeking also does not remove the data, which would allowthe buffer to reach its storage limit. As a result, this closes down thenetwork data-flow rate and makes the entire process of data transmissioninefficient.
Polling on a stream socket until a certain number of bytes or a "message"arrives is bad code. A stream socket, such as TCP, does not preservemessage boundaries because it provides a data stream. As such, the largestmessage size an application can ever depend upon is one-byte in length.Code that uses peeking to wait until a complete "message" arrives mightnever succeed on stream-based protocols in Winsock where the data straddlesmultiple system buffer boundaries, due to design decisions. The peekoperation will report the number of bytes up until the first bufferboundary. The bytes remaining in the other boundaries might never bereported, resulting in an incorrect count of data for code algorithms thatdepend upon the peek values to be accurate. Subsequent peek attempts willnot reveal the "hidden" data, which can still be received from the buffers.
The best stream-based protocol socket implementation is to drain dataimmediately upon arrival into application-allocated buffer space. Thisallows the socket buffers to remain open to a steady network data-flow rateas the application parses the data, resulting in much better networkperformance.
For additional information, please see the following article in theMicrosoft Knowledge Base:
Article ID: 192599 - Last Review: 06/22/2014 19:15:00 - Revision: 3.0
- kbapi kbinfo kbnetwork kbwinsock KB192599