RE: HTTP Asynchronous Client Notifications (draft paper)

Thanks to all who emailed me feedback. I have provided an updated version of
the paper at http://www.clipcode.com/peer. Updates are listed below.

Eamon O'Tuathail
Clipcode.com

----------------------
Updates:

Added as an additional technique the use of UDP as backroute from server to
client (after a normal HTTP client-server connect)

Changed the name of "never-ending-request" to "never-ending-response", as it
is the response that never ends.

More importantly, emphasised that an HTTP proxy may (and often will) shut
done long-lived connections, and events in transit from server to client
might get lost. There are work-arounds (such as the client, upon reconnect,
requesting from the server all events since the last one that arrived at the
client). However, all this gets somewhat messy.

For large numbers of subscribers, mentioned the use of  multicast (though
not based on HTTP).

To cover the concern about the whole idea of using HTTP for something other
than HTML/visual content, added this quote from RFC 2616 (HTTP), which
states that HTTP "can be used for many tasks beyond its use for hypertext"

To cover the valid concern about whether HTTP is the correct application
protocol at all for event notification delivery, I noted that there are
others, and where possible (a.k.a. OK with the firewall admin) then strongly
recommended these should be considered - but I noted "often your choice is
not whether to use HTTP or a different application protocol, but rather
whether to use HTTP or, not to access the network beyond the firewall. "

Received on Tuesday, 8 May 2001 15:35:28 UTC