Search the Community

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