[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: HTTPAPI



Hi Scott
Thanks for the quick reply

We are using the post procedure http_url_post_raw
In looking at the code in there it is using the timeout for both the call to
http_persist_open and to http_persist_post

I think I asked the question wrong here
We are not having an issue with the connect timeout but with the post not
waiting for a process to complete.
Since the same timeout is used in both places I can see now where we may not
want it to be too large for the connection
But we still need the process to wait until the post is completed.

Also I noticed in looking thru the code that the timeout variable type is
defined as an Integer 10i 0 in http_url_post_raw and http_persist_open
Then in the comm_connect prototype it is defined as 10P 3

Is that correct?

Thanks again for your help


-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Tuesday, September 11, 2007 6:27 PM
To: HTTPAPI and FTPAPI Projects
Subject: Re: HTTPAPI

Hi Ron,

> I have a question about the p_CommConnect Procedure call.

p_CommConnect isn't the name of a procedure, it's the name of a pointer 
that points to a procedure.  If you pass a URL to HTTPAPI that starts 
with 'http', then HTTPAPI will call the CommTCP_new() routine, which, in 
turn, will set p_CommConnect to point to the CommTCP_Connect() 
procedure.  If you start you URL with 'https', then HTTPAPI will set the 
p_CommConnect to point to the CommSSL_Connect() procedure.  The idea is 
that it calls the appropriate communication driver for the type of 
connection you're making.

At some point in the future, I might want to add additional 
communication drivers.  If so, I simply have it point to the correct 
one, and the rest of the HTTPAPI code can remain untouched.

So when HTTPAPI calls Comm_Connect(), it either calls CommTCP_Connect() 
or CommSSL_Connect(), depending on the URL.


> Is there a value like -1 that you can send to make the timeout unlimited
> I have tried 0 and -1.

No, but you can set it to a very high value.  For example, you could set 
it to 86400, and it'd wait for an entire day before timing out.

Though, I'm really curious as to why you'd want to do this.

I've been writing TCP/IP software for about 15 years. (Longer than most 
people!)  In that time, I've found the following:

a) Normally, a connect attempt takes less than 1 second.

b) If the machine is under very high load, it can be higher, usually 
about 5 seconds.

c) Under extreme load, I've seen it up to 30 seconds.

d) In the old days (this is no longer common) you could have routers (or 
computers running software like WinGate) that would establish a dial-up 
connection when a connection attempt was made.  So they'd get the 
connection attempt, dial the phone, wait for carrier, connect the modem, 
negotiate TCP/IP settings (via PPP), and finally connect to the 
Internet.  Then, the connection attempt could be made, and that might 
take some additional time.   For these, the connection attempt was often 
in excess of 45 seconds.  Usually less than 60 seconds, though.

e) Occasionally the preceding situation would cause a connection in 
excess of 60 seconds.  That's why you can change the timeout from the 
default value of 60 to a higher value -- just in case.

f) I've never seen a connection attempt take longer than 300 seconds (5 
minutes) unless something has failed, and the connection is never going 
to succeed.

So you can adjust that timeout if you like.  You can even make it as 
high as 86400... a whole day!   But I'd be shocked if it ever succeeded 
after 5 minutes.

And do you really want your software to sit and wait INDEFINITELY, if 
the connection won't ever be established?  Isn't it much nicer to have 
it time out, so you can use the job for other things?


> Also I was looking for more documentation on this procedure 
> Do you have any more docs?

This particular procedure (CommTCP_Connect and CommSSL_Connect) are 
intended to be used internally by HTTPAPI, and it's not expected that 
you'd call them directly.  Therefore, even if I sat down and put a lot 
of effort into documenting HTTPAPI, I wouldn't provide docs for these 
procedures.  They're only used by people who are halping to develop 
HTTPAPI, and I expect those people to read the code in COMMTCPR4 and 
COMMSSLR4 and understand what they do -- or ask me.

If you're trying to change the timeout for http_url_get(), 
http_url_post() or one of the other http_xxx() routines, then they 
should accept a timeout parameter.  Take a look at the parameter 
descriptions in the HTTPAPI_H member, it should describe all of the 
parms you can pass to the APIs, and what they do.

But, my feelings about the timeout are the same as above -- making this 
higher than 300 seconds is basically pointless.  If it hasn't connected 
in 5 minutes, it's not going to.
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------