Winsock recv() and buffering
Author
Hello,
I just had a quick question regarding the recv() function call when using Winsock and how it handles buffering data. I noticed while reading through the Quake II source, that each server frame they make a call to ReadClientMessages() which in turns makes a call as follows:
while( recv( blah, blah, blah ) )
{
get the data
process the data
}
My question is, does the recv() function handle buffering automatically, like say in a particular server frame two clients each sent a "command" packet and they were both received while my application was calculating the new positions of all items in the game world, will Winsock automatically buffer both of them, and come time to read them I can simply pick eash one off the "queue" and process them, or will I lose one of the packets only receiving the latest one?
Thanks in advance,
Permafried-
Winsock has a buffer into which received data goes until you call recv() to get it out. So I think the answer to your question is yes, winsock automatically buffers for you. It is possible for this buffer to become full, in which case the sending end will block/fail on calls to send() until the receiving end has buffer space available again. Non-stream connections will just discard the extra data. You can set the desired buffer space with:
int sendBufSize = 65536;
setsockopt(socketHandle, SOL_SOCKET, SO_SNDBUF, (char*) &sendBufSize, sizeof(sendBufSize));
int recvBufSize = 131072;
setsockopt(socketHandle, SOL_SOCKET, SO_RCVBUF, (char*) &recvBufSize, sizeof(recvBufSize));
int sendBufSize = 65536;
setsockopt(socketHandle, SOL_SOCKET, SO_SNDBUF, (char*) &sendBufSize, sizeof(sendBufSize));
int recvBufSize = 131072;
setsockopt(socketHandle, SOL_SOCKET, SO_RCVBUF, (char*) &recvBufSize, sizeof(recvBufSize));
Author
Zppz,
Thanks for the quick reply and this was exactly what I was looking for. This will make things a little easier for me since I won't have to worry quite SO much about multithreading my application since my server is currently running at a rather high "frame rate" (calculations, etc. not rendering) and there should never be a large amount of packets backed up. Since I will be using UDP as my transport protocol and my server is operating at a high rate of speed, I may not have to worry about the size of the buffers, though I will implement them anyways just to ensure I dont run into problems such as high packet loss and retransmissions.
Thanks again,
Permafried-
[edited by - Permafried- on June 2, 2004 2:21:46 PM]
[edited by - Permafried- on June 2, 2004 2:23:05 PM]
Thanks for the quick reply and this was exactly what I was looking for. This will make things a little easier for me since I won't have to worry quite SO much about multithreading my application since my server is currently running at a rather high "frame rate" (calculations, etc. not rendering) and there should never be a large amount of packets backed up. Since I will be using UDP as my transport protocol and my server is operating at a high rate of speed, I may not have to worry about the size of the buffers, though I will implement them anyways just to ensure I dont run into problems such as high packet loss and retransmissions.
Thanks again,
Permafried-
[edited by - Permafried- on June 2, 2004 2:21:46 PM]
[edited by - Permafried- on June 2, 2004 2:23:05 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
