Joe Gregorio wrote: > Why can't you keep that socket open, that is the default > behavior for HTTP 1.1. In some applications, HTTP 1.1 will work just fine. However, HTTP doesn't add much to the high volume case. It also costs a great deal. For instance, every POST requires a response. This means that you're moving from a pure streaming case to an endless sequence of application level ACK/NAKs that are simply replicating what TCP/IP already does for you. Also, the HTTP headers that would be required simply don't contribute anything useful. The bandwidth overhead of the additional headers as well as the bandwidth, processing and timing problems related to generating responses begins to look pretty nasty when you're moving at hundreds of items per minute or second... One really good reason for using HTTP would be to exploit the existing HTTP infrastructure including proxies, caches, application-level firewalls, etc. However, I'm aware of no such infrastructure components that are designed to handle well permanently open high-bandwidth connections. The HTTP infrastructure is optimized around the normal uses of HTTP. This isn't "normal." One of the really irritating things about the current HTTP infrastructure is that it is very "fragile." This is a problem that has caused unlimited headaches for the folk trying to do "notification over HTTP" (mod-pubsub, KnowNow, various HTTP-based IM/chat systems, etc.). The problem is that HTTP connections, given the current infrastructure and standard components, are very hard to keep open "permanently" or for a very long period of time. One is often considered lucky if you can keep an HTTP connection open for 5 minutes without having to re-initialize... Of course, during the period between when your connection breaks and when you get it re-established, you're losing packets. That means that you have to have a much more robust mechanism for recovering lost messages and that means increased complexity, network traffic, etc. The added complexity and trouble can be justified in some cases; however, not in all cases. HTTP is great in some cases but not all. That's why the IETF has defined BEEP, XMPP, SIP, SIMPLE, etc. in addition to HTTP. One protocol model simply can't suit all needs at all times and in all contexts. Whatever... The point here is that Atom already has defined all that appears to be needed in order to address the "Fat Ping" requirement whether you prefer individual HTTP POSTs, POSTs over HTTP 1.1 connections, XMPP, or raw open TCP/IP sockets. That is a good thing.
bob wyman