UDPRecv ignores TCPTimeout option

[Kealper]

I've seen this for a while now but I never really got around to doing anything... It seems UDPRecv has a 100ms delay if nothing is recieved (which is to be expected), but it totally ignores the value set in the TCPTimeout option. I'm not sure if that is intended or if it is a bug so I figured I'd ask here before throwing it up on the trac so I knew what to file it as.

I know "TCPTimeout" implies that it's only for TCP, but other things seem to use TCP and UDP interchangably in their names (TCPStartup/UDPStartup, etc) so I figured it could have just been accidentally left un-implemented in the UDPRecv code when that option was added, and that no one ever really brought it to everyone's attention. It just seems odd that you'd be able to control the delay for something like TCPAccept but not for UDPRecv, since there are things where having a 100ms wait after almost every UDPRecv call is not desirable...

EDIT: I guess I should have formatted my question better when originally writing this, what I meant to ask was:

Is there a reason why UDPRecv ignores the TCPTimeout option? Or is that a bug that should be filed in the trac?

Below is code to show what I'm talking about with the delay, it waits about 100ms after each call to UDPRecv.

UDPStartup()

;Make things like TCPAccept return instantly instead of blocking for the default
;100ms after no activity. Doing this is useful if your program does more than
;just wait for data on a specific socket.
Opt("TCPTimeout", 0)

;Bind a random port, what port doesn't matter, it only needs to be a valid socket
Global $Sock = UDPBind("0.0.0.0", Random(1, 65535))

While 1
    $iTimer = TimerInit()
    $sRecv = UDPRecv($Sock, 512) ;Time how many milliseconds it takes to call UDPRecv and write time to stdout
    ConsoleWrite(TimerDiff($iTimer) & @CRLF)
WEnd

Edited April 21, 2012 by Kealper

[qsek]

Been there, done that.

If you want to bypass the blocking you have to set up a permanent stream of data from and to the endpoints. And since with UDP you have to do all the packet checking, verifying and the "only one packet per UDPRecv" thing, this can get very frustrating.

But with TCP you have the same 100ms timeout problem. But there you can establish a constant In/Out Stream easier and dont have to worry about buffer loss/overflow.

The above statements are only my personal expierience with this problem, so it may not be right after all

Oh and As i remember TCPTimeout is only a timeout for inital connecting with TCP/UDPConnect, not for recieving data.

Edited April 21, 2012 by qsek

[Kealper]

That's actually why I was asking... I've got a potential buffer overflow problem that is partly being caused by each call to UDPRecv blocking for 100ms... A server I made for a chat can be taken down if a client is sending too much data to another client and it can some times lock up its instance of the interpreter (autoit3.exe actually completely stops responding until the offending client stops blasting it with data or gets disconnected)... This seems to only happen when the server is unable to empty TCPRecv's temporary buffer into a more permanent buffer variable fast enough. Any delays with TCP functions like the 1ms delay in every call to TCPRecv, or the 100ms delay with every call to TCPAccept can be removed just by setting that TCPTimeout option to 0... But the problem comes in when that server is also listening for UDP packets as well (as a type of echo for checking if the server is online), and that 100ms per call ends up being enough to drive it over the edge if multiple clients are transferring files or something else that requires heavy data usage a few times now.

I'll admit I don't actually know if the 100ms delay in UDPRecv is completely needed... But if it is not, then it would be most helpful to either tie that delay in to the TCPTimeout option, or make a UDPTimeout option with a similar function.

Meh, I guess I'm just rambling by now...