On Mon, 27 Mar 2000 [EMAIL PROTECTED] wrote:
> Hi all,
> I recently put some scripts together which allow me to support persistent
> HTTP connections. Roughly, they look like the scripts that follow this
> message (Flamethrower users will notice that I obviously ported a
> Flamethrower project to Metacard). All that it really involves is sending a
> "Connection: Keep-Alive" line in my HTTP reply. Then I simply use the line
> "read from socket s for 1 line with message 'serverread'", which when the
> client issues another request will take that request.
> My question is, what is the overhead incurred by immediately issuing a read
> command on a socket after my reply? Is it costing me just as much time as I
> am saving by keeping the connection alive?
The overhead is certainly far less than what would be required to open
a new connection. On Windows and UNIX there is about 0 cost for this
other than the command-execution overhead. On MacOS it's a little
worse because leaving a connection open requires that the engine go
into a tighter polling loop than it normally uses, but even that
shouldn't be noticible because it's usually only done at idle time.
> Also, I'd like to use a different socketTimeoutInterval for new connections
> as opposed to connections simply being kept alive. Is this at all possible?
> Does changing the socketTimeoutInterval apply to sockets which have already
> had a read command issued on them? What is the rule for this?
The current socketTimeoutInterval is applied at each operation on a
socket. So you could open the socket, do a write, set the
socketTimeoutInterval to a different value and then do a read, and the
read will only send the socketTimeout message after that different
(longer?) interval.
Regards,
Scott
> Thanks,
> Brian
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
Archives: http://www.mail-archive.com/metacard%40lists.best.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.
