TCPRecv() Limit? Can it Overflow?

[TurionAltec]

I'm creating a TCP application acting as a Telnet server, where after the users log in, all users get the same data periodically sent to their session, and there's no requirement for them to type anything.

Just to ensure some level of robustness, if I don't issue a TCPRecv() on a connection, and they send a lot of data to the Server, is this going to fill up an internal buffer on the server and potentially crash?

Right now I have a For-Next loop going through an array for each connection, and after sending any new data to the client, it issues a "TCPRecv" purely because I thought there might be a buffer backing up, however this causes a 100ms delay per connection due to the TCPTimeout option. This isn't a problem with only a couple clients connected, but drastically reduces responsiveness as the number of clients go up.

I have tested with 660 active clients, and If I don't do a TCPRecv, AutoIT can handle sending data to them no problem (close enough to instantly)*.

 

*AutoIT didn't have any problems with it, but Windows didn't like having that many Putty sessions open on one computer.

To give credit, I built up my server by starting with the array idea in this thread:

Where an Array is used to track the connections, only I made it a 2D array. One dimension for a connection number, and then the other dimension tracking data about the connection:

-socket number

-whether it had authenticated

-Timer for how long the connection has been active (to disconnect users that don't successfully log in after a minute).

[Bert]

This one is outside my wheelhouse. Let me post this in the MVP lounge and see if any of our experts can chime in and help.

[Mat]

Msdn recv (the actual function AutoIt uses could be one of a few within winsock, assuming they use winsock, but recv is the simplest and they'd hopefully all behave the same here):

Quote

If the datagram or message is larger than the buffer specified, the buffer is filled with the first part of the datagram, and recv generates the error WSAEMSGSIZE. For unreliable protocols (for example, UDP) the excess data is lost; for reliable protocols, the data is retained by the service provider until it is successfully read by calling recv with a large enough buffer.

In short, MSDN says the data is saved by the service provider, and there is no limit to the buffer in the function AutoIt (is probably) calling.

The default service provider is mswsock.dll, and that's as far as I've got. I can't seem to find any reference to the buffer size for mswsock.dll. React OS (a free os designed to be able to execute windows executables) possibly uses 512 bytes according to a patch. 

I haven't seen any indication that the buffer expands dynamically, but it could do. Just keep sending data and see if your memory usage grows I guess. Test sending loads of data and see if any is lost.