[jdev] Re: Two questions regarding JEP-0124 HTTP Binding

[Guus der Kinderen]

Alright, thanks, that was helpful. One last question: 'polling' only 
limits the time between sending two polling ('empty') requests, right? 
Other requests can be send more frequently?

Jack Moffitt wrote:
> 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.
>