On Friday 2008.10.10, at 03:35 , Vincent Nonnenmacher wrote:
Rob Heittman a écrit :
[...]
Given that HTTP/1.1 is typically used and the total size of an
exchange is
thrifty, many, many concurrently polling clients can be supported,
especially with an NIO-based server. In my app, the poll interval is
self-throttling and not deterministic; a client begins a new poll
after the
last poll completes, plus any configured delay.
That a VERY enlightening example, thanks a lot it gave me several
ideas.
I'm wondering how you make your self-throttling adaptation and if
the server couldn't help here
but as you said it is perhaps not needed if no payload is involved
when not absolutely necessary.
The clients are just doing "best effort" to update e.g., their own UI
as fast as they can then they have a fixed-length delay then they poll
again. So, slow clients take longer to update themselves while fast
clients end up waiting for the configured delay period. The server
doesn't do anything.
The server can inform all of the clients to slow down by e.g., adding
a server status code to the headers in each response. Of course, that
requires well-behaved clients to take that information and do
something helpful like e.g., increase the delay period between requests.
As John said, instant
updates may not be needed; a second or three may be an acceptable
delay
between UI updates. This design ensures that eventually every
client will
see every event, but there is no realtime or near-realtime
guarantee. The
faster/better the client computer, the closer to realtime its
performance.
that's right up to the point the user as an other way to see the
event happening by an other mean.
In the phone example, the user could hear the ring much before the
1-2 seconde delay
and feel the solution is slugish because of that false sense of non
reactivity.
I guess if I imagine your solution, this is the same a someone seen
activity on a camera
just before you visually trigger its attention ?
I'm still confused by your descriptions of what your "dashboard" is
doing. If it's truly just an information dashboard then it's
irrelevant that the user will hear (and pick up) the phone before the
dashboard gets updated.
Also, if you examine any number of phones systems out there today, you
can notice that there can be discrepancies between things like when
the phone lights up and when the ringer rings, much longer delays as
to when the Caller ID is updated, etc. I.e., there are delays in the
phones themselves and the fact is that the vast majority of humans
(will) never notice and to whatever small degree do notice only a
vanishingly small number care at all. Depending on the phones and
which phone system they are tied to there are already 1-2 second delays.
Anyway, not sure any of that is relevant to what you want to do ...
if you
forge ahead on the Comet path please let us know how things come out.
I'm trying to use the comet implementation available inside Grizzly
web server (tring not to require
usage for a web container (jetty using continuation, or JSR Servlet
ASR implementation).
There both Dojo and a jQuery projects that implement the bayeux
protocol with a clean pub/sub to
a 'chanel' concept that in my opinion could be opted in in a REST
world in the future and then
if that work, perhaps the solution is to limit the number of DOM
elements that absolutly need
to be aysnchronously pushed to the web UI and use clever techniques
like the one you describe
for higher acceptable latencies in other part of the DOM.
I'm all for increasing the speed and reliability of e.g., the HTTP
based world. But... I've still never heard any valid argument for
these sorts of "realtime" capabilities in HTTP. Any place where
anyone really *needs* any sort of realtime guarantee in latency,
throughput, or jitter or any sort of reliability guarantees cannot
live all of the vagaries inherent in how HTTP works. Trying to
shoehorn the (ab)use of HTTP for these other needs (a) does *NOT* work
and (b) just confuses people into false beliefs that it might work.
Take care,
John
