Saw some confusing things on the source engine 2007 code and was wondering if anyone knows why these are in here.

https://github.com/VSES/SourceEngine2007/blob/master/se2007/engine/cl_rcon.cpp#L559-L563

Why are they verifying that the read length is at least 4 bytes?

If a packet was sent with a length of 20 bytes and only the first 18 bytes were transmitted on the first send() attempt, then wouldn't the recv function for this class not attempt to recv those last 2 bytes until the next packet with at least 2 bytes (because 2+2=4) gets sent?

https://github.com/VSES/SourceEngine2007/blob/master/se2007/engine/cl_rcon.cpp#L568-L572

Why are they allocating a min recv buffer of 1024 instead of just the read length on the stream and attempting to read a minimum of 1024 bytes instead of readLen?

Look down the file a bit, you'll see after successfully reading data they call ParseReceivedData().  

Inside the parsing code you can see every packet starts with an int for the size of the packet, followed by a series of details beginning with a request ID int, command ID int, and then details of the command.

Without looking deeper in the code about how they do the buffer, that suggests that if they don't have enough data to actually be a packet they don't bother processing it. Processing it requires memory allocations and releases and hardware access, which are time consuming.

It is possibly an issue if their buffering system or their commands happen to move less than 4 items and then stall for a time, but in most games there is a constant flow of data so that isn't a problem.  Data will continue to flow continuously, so it would likely reach the four-byte threshold before the next update is run.  If the buffering were configured that way then it might be better to process any amount of data that has been received in case they were mid-data before, but that's a bigger question about the game's performance cost for waiting for data and the time between updates.

As for the minimum buffer size of 1024 bytes, that is probably because time passes and because network hardware runs separate from the program.  They query how much data is ready at one moment, but that is at least six lines and potentially many loops later, which includes a memory allocation and the loop of processing data buffers. Many things may have happened, including the OS using that time to swap to different processes so potentially a significant amount of time has passed between the time.  

Rather than only reading the values that had arrived during the earlier "is there any data?" query, they have a buffer that allows for at least 1024 bytes as a minimum. Thus even if there were only 32 bytes available during the initial query, if there were more bytes available at the time recv() is called it would pull up to 1024 bytes that are available, rather than reading only part of the data and keeping it queued until the next update to run.  They may have benefited from a second test inside the loop to update how many bytes are available to read, but again, that's a bigger design question of the damage done by waiting for data as well as understanding the time between updates.

Yes, servers generaly drop packets, or sessions, or clients, who do not send a complete contained initiation header successfully to be red.That happens on TCP protocol only with false client software.

But there are heavy duty http servers that do not bother if initiation read data does not contain enough header information to establish request and sends response code 400 Bad Request. Those cannot afford any other way, for they would be prone to floodings and more easily exposed to low-scale DDoS, if they tried to buffer unknown requests /connections data yet stacking them up.

In other words, it always depends, right?

1 hour ago, hplus0603 said:

and because network transmission is what it is, those multiple calls may be separated by some amount of time.

Which gets its way back to the original code question.  There is some amount of time between the query for the amount of data received versus the request to fill up the buffer with data.

The buffer is extra large to accommodate any data that may have been received during that time window.  Because on a modern computer, you have no idea if the time between lines of code is best measured in nanoseconds or milliseconds, or in the case of power management, potentially even years between two adjacent instructions... 

Ultimately you have little or no say on what the hardware will do between here and there. There is a gap, and things happen in gaps. You don't know when data will arrive, or how much will arrive and be available at any given time.  So grab everything that is available, process everything you've received that you're able, and hold the rest for the next update.