TCPRecv idling the CPU, or is it just slow?

[Kealper]

Hello, I've done some testing and I've noticed that TCPRecv is slow, but it's almost exactly 1ms each time it's called if the socket is a valid socket and not a dead socket...So this got me thinking about the line in the help file about TCPRecv idling the CPU, presumably to allow people to call it continuously inside an extremely tight loop without running the CPU usage up too bad. I've been making a chat client/server (which I won't bother posting since it seems just about everyone has made those, it would just be another fish in the sea) and I always wondered why in my stress-testing, it would conk out after around 300-350 separate clients and then the interpreter itself would lock up and fail to respond.

I think I've found out why it does this after some investigation into TCPRecv, what happens when too much data is buffered without flushing it with another call to TCPRecv (interpreter locking up), and ultimately why said chat server is limited to a few hundred clients...after some more testing, that delay gets to be pretty high the more clients the server caters to. If the server has 50 people on it, it's doing around 50ms of sleeps each time it loops through to check the clients just from the calls to TCPRecv..so once it gets around 300-350 clients on at once, it's waiting 300-350ms total each time it does a loop. This ends up delaying all clients connected by basically 1ms per client connected plus their actual latency to the server, which is not that good...

I know some people may think "If you want to have a server cater to that many connections in a timely fashion, you should use a different language..." but I'm really only doing this for the experience, I have no intentions of actually letting this stuff roam free in the wild

Anywho, I figured I would test out trying to reinvent the wheel, to call the recv function in Ws2_32.dll and basically make my own version of TCPRecv that would work without the delay in it (assuming that 1ms time was an artificial delay put there by the AutoIt devs to idle the CPU) and see if that could do the job any faster...But that is when I started running in to the issue I am having right now, and where my lack of C/C++ knowledge is really starting to bite me in the behind.

Below is the function I tried making to emulate TCPRecv but failed at doing so...DllCall is setting @error to 1, which according to the help file says it was unable to access the dll, but I know from previous experience that AutoIt has no problem using Ws2_32.dll (the function _SocketToIP that has been floating around here for ages is one semi-well known one that calls this dll) so I'm guessing it's an issue with my lack of experience in the dark side of AutoIt so to speak...

Func _TCPRecv($iSock, $iLen)
Local $structBuffer = DllStructCreate("char[" & $iLen & "]")
Local $aRet = DllCall("Ws2_32.dll", "int", "recv", "int", $iSock, "char", DllStructGetPtr($structBuffer), "int", $iLen, "int", 0)
If @error Then SetError(1, 0, "")
Return SetError(0, $aRet[0], DllStructGetData($structBuffer, 1))
EndFunc

Any insight about TCPRecv's delay or my failed attempt at reinventing the wheel would be greatly apriciated!

[SmOke_N]

"char" should be "ptr"

Might use byte struct instead of a char one.

Edited September 19, 2011 by SmOke_N

[Kealper]

Thanks a ton, I've only just started learning C so I'm still not 100% sure about using these different sorts of things...I guess I'm too used to AutoIt's generic variants