Jump to content

Search the Community

Showing results for tags 'tcptimeout'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • General
    • Announcements and Site News
    • Administration
  • AutoIt v3
    • AutoIt Help and Support
    • AutoIt Technical Discussion
    • AutoIt Example Scripts
  • Scripting and Development
    • Developer General Discussion
    • Language Specific Discussion
  • IT Administration
    • Operating System Deployment
    • Windows Client
    • Windows Server
    • Office


  • AutoIt Team
    • Beta
    • MVP
  • AutoIt
    • Automation
    • Databases and web connections
    • Data compression
    • Encryption and hash
    • Games
    • GUI Additions
    • Hardware
    • Information gathering
    • Internet protocol suite
    • Maths
    • Media
    • PDF
    • Security
    • Social Media and other Website API
    • Windows
  • Scripting and Development
  • IT Administration
    • Operating System Deployment
    • Windows Client
    • Windows Server
    • Office

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start






Found 3 results

  1. ---------- edit: this is probably in the wrong place, can a moderator move it to wherever it belongs? ---------- is there any way to completely disable TCPTimeout and make TCPRecv() wait indefinitely? maybe setting it to 0 or -1 or something? the docs doesn't seem to mention any way to disable it - the underlying C code would set SO_RCVTIMEO to 0 , aka DWORD timeout=0; setsockopt(s, SOL_SOCKET, SO_RCVTIMEO, &timeout, sizeof(timeout));
  2. Hi. I'm working on a script to "round robin" through a list of Terminal Servers. the PC's host names are like "PC1", "PC2", "PC3", ... at each site, so I just use the "number suffix" to determine, which TS server shall be tried for *THIS* PC first, 2nd, 3rd (done, no problem). The issue is showing up, when a TS-Server is *NOT* available. Setting opt("tcptimeout",50) doesn't speed up the process, but I don't think, this is autoit related: it always takes quite a number of seconds to get the result, also with several other tools I've tried, that make use of the Win network APIs. So I suspect, that it's the Windows TCP/IP stack, that's the constraint (WinXP SP3 and Win7, x86 and x64). Question: Is there some "CMDline single EXE tool" / "some other approach", to get the up / open / closed status for an IP:TCPport pair instantly? nmap.exe is dependant on several files coming with it's installation (so fileinstall() would have to install quite a bunch of files), and it also doesn't return valuable exit codes representing it's results, otherwise fileinstall() and this line would be my friend: nmap -PS -p 3389 There are quite a lot of very fast GUI IP scanning tools, but I couldn't find one for command line (ab-)use so far. Any suggestions appreciated, as I don't want to re-invent the wheel ;-) Regards, Rudi. Func CheckConnect($_IP, $_Port) Local $Err TCPStartup() ; Set Some reusable info ;-------------------------- Local $ConnectedSocket, $szData Opt("TCPTimeout", 50) ; Initialize a variable to represent a connection ;================================================== $ConnectedSocket = -1 ;Attempt to connect to SERVER at its IP and PORT specified ;=========================================================== $Socket = TCPConnect($_IP, $_Port) $Err = @error TCPShutdown() If $Err Then Switch $Err Case 1 SetError($Err) Return ("IP-Address invalid: " & $_IP & ":" & $_Port) Case 2 SetError($Err) Return ("Port-Addresse invalid: " & $_IP & ":" & $_Port) Case Else $Ping = Ping($_IP) If $Ping Then SetError($Err) Return ("PING time = " & $Ping & " - unknown error occured: " & $_IP & ":" & $_Port) Else SetError($Err) Return ("host not PINGable! ") EndIf EndSwitch Else Return True EndIf EndFunc ;==>CheckConnect
  3. 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("", 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
  • Create New...