Rob Heittman a écrit :
Meant to post this last night, but am on travel with intermittent
connectivity. Jerome's reply makes it a bit ad hoc ...
My love of REST and the Web doesn't quite extend to the use case of a large
N of concurrent clients monitoring a single source of near-realtime events.
To me, this is the kind of application that cries out for UDP, multicast
and other low level techniques for extreme scalability with responsiveness.
And a heavy client that can use these techniques.
I concur to that but my mandatory business case force me to have a least
an open
light ajax/web client.
By the way when you look at the network level where you see all phones
/pbx conversation
to handle Busy Lamp Field signaling for ringing, iddle and so on events,
you see the exact same
point (not solved by a multicast, but a standard
publish/subscribe/notify pattern like e.g SIP like)
But I've been in the spot of needing something like this to work over
unaided HTTP in a browser for whole-product reasons. So here is a pattern
I've used in practice, for a law enforcement application; it works okay and
customers like it, but the design still feels forced to me -- the whole use
case is not a great fit for a pure browser-based application.
[....]
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.
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 ?
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.
Thanks again for your nice description.
