>Hi!
>
>>There are 3 timeouts that can be set: CONNECT, SEND and READ. I think you'd want the read timeout since you're waiting on the result.
>
>I'm aready using your wwHTTP code which sets all 3 timeouts for both connection handles. Timeouts more than 5 seconds work OK.
>If timeouts are set to less than 5 seconds ( 1 seconds or even 100 ms), HTTPGetEx still waits 5 seconds.
>Comments in wwHTTP code describe that that it makes 3 retries, maybe this casues this. I uncommented code and set retry count to 1 but it still waits 5 seconds.


These timeouts aren't precise especially not the connection timeout (ie. if you connect to a valid IP, but there's no server). The reason for this is that the TCP/IP connection has a minimum (and blocking) connection timeout on it and I suspect WinInet internally polls the connections to process timeouts.

On my machine if I run the following code:

DO wwhttp
loHttp = CREATEOBJECT("wwHttp")
loHttp.nConnectTimeout = 1

lnSeconds = SECONDS()

*** DNS is valid, but no server listening
? loHttp.Get("http://localhost:5202/test.html")

? "Done " + TRANSFORM(lnSeconds - SECONDS())
RETURN

This results in 2.03 seconds. When I bump the timeout to 3 I get 4.1, anything longer then ends up somewhere between 4-5 seconds (apparently my local TCP/IP connection timeout). So it looks to me the overhead is somewhere around 1 seconds on the low values and then whatever the TCP/IP (plus some small overhead) timeout is.

For an online URL that gets slower and it looks like the difference is 2 secs instead of 1 for the lower values. With connect timeout set to 10 it takes ~12 seconds to abort the connection. After 1-2 repeated failures it looks like WinInet caches the connection stat and starts failing more quickly even with the 10 second timeout (in ~4 secs). The extra time is likely due to the connection latency.

This is a notorious Windows Sockets issue and this is not unique to WInInet. In fact I ran into this years ago with wwIpstuff, which used native WinSockets code for various protocols (like SMTP). Similar connection issues existed there with a completely different code path to the connection.

I have also similar issues in .NET (which doesn't use the Windows HTTP infrastructure but has a separate dedicated HTTP stack) and there too timeout and initial buffer retrievals can't be tightly controlled. I struggled with this in West Wind Web Surge where it's critical that requests fail fast when they do. Even so if there are timeout issues there's a minimum hang of a couple of seconds. At one point I even started down the path of creating my own TCP/IP based connection management, but even at the low TCP/IP level the timeouts (and initial TCP/IP buffer retrieval) couldn't be controlled.

If tight timeouts are an issue one way you can potentially deal with this is to run asynchronous code where you fire off the requests and then have the main thread wait for a response for the allotted timeout. If the request times out it still takes as long as before but it's on an external thread that won't affect your mainline code that can continue after the actual timeout. OTOH, the overhead of the async call in FoxPro is likely going to add overhead that might negate the whole 1-2 secs you might save in the process. Maybe push the routine off into .NET - make an Async call there and wait for the specified timeout (.Wait(timeout) ) then return.

Wish I had better news. if you run into anything to get around this I would love to hear about it because this is something I've run into many times and a problem I've tried to solve on more than a few occasions myself.

+++ Rick ---




+++ Rick ---

>>But... if you're really doing long polling, by killing the connection you're killing the long polling connection. Assuming this is really long polling on the server that's waiting for a response this would break the whole concept of LongPolling.
>
>Customer display shows output properly, it takes 1.5 seconds as reported by curl.
>Customer dispaly seems designed in such way that it waits for next command in same POST request without terminating connecton. This is called long polling. It also supports WebSockets interface. I havent found any VFP code which allows to use Websockets.
>
>If long polling is not terminated, VFP application freezes for 5 seconds since HTTPGetEx does not return. It is not possible to run PCU output in separate thread since VFP is single threaded.
>
>Andrus