[jdev] Two questions regarding JEP-0124 HTTP Binding

Jack Moffitt jack at xiph.org
Mon Nov 14 14:05:05 CST 2005


The following comments are based on my interpretation of the spec, which
is reflected in the implementation of Punjab.

> Is there something wrong with having a larger value for 'inactivity' 
> (allowable inactivity period for a client) than 'wait' (longest time 
> that server will wait before responding to any request during the 
> session)? Somehow, having 'inactivity' > 'wait' seems wrong, but I'm 
> unable to pinpoint a logical flaw.

The 'wait' period is not really one of inactivity.  The server has a
request pending for the client, it's just choosing not to respond as
thre is not enough data yet to warrant one.  In punjab, as soon as any
data arrives, a pending request will get a response immediately.  If the
'wait' timeout expires, a blank response is sent.

'inactivity' is when there has been no request at all.  For instance, if
a user left the page and the code stopped polling, the server will
eventually time out.  I believe in punjab we now set this to a few
minutes.  I think the default 'wait' is 60 seconds.

> The 'polling' attribute specifies the minimal amount of time a client 
> should wait between two polling (empty) requests. Does 'between' specify 
> the time between the starttime of both requests, or the time between 
> receiving a reply of the first request and the start of the second request?

Between start times makes the most sense.  When you poll, the server
will wait if there is no data.  If you poll every 60 seconds, say, and
the server waits for 60 seconds, you are doing one round trip per
minute, during idle, but you have as little network latency as is
possible via a proxy.  Otherwise, if you polled 60 seconds after you got
a response, some messages will experience high latency if they arrive in
the dead time.

A good client and server implementation should provide you with about
the same latency as a directly connected TCP client (minus the proxy
latency of course).  It's a cleverly designed protocol.

jack.



More information about the JDev mailing list