Cart
[Home] [By Thread] [By Date] [Recent Entries]
"Bullard, Claude L (Len)" wrote: > > Not so, Daniel. Most public safety network > applications also use UDP. They require higher > reliability than HTTP provides. Don't understand. Received wisdom is the opposite: "Use UDP in applications where reliability is not critical" "TCP ensures reliable transmission across networks, delivering data in sequence without errors, loss, or duplication." * http://zone.ni.com/devzone/conceptd.nsf/webmain/BA7F1D7CE009BE7686256A5B004F335D?OpenDocument "TCP uses a retransmission strategy to insure that data will not be lost in transmission" * http://www.dictionary.com/cgi-bin/dict.pl?term=tcp&r=67 HTTP builds on TCP and inherits its reliability features. >... > Some applications require reliable solutions, > not popular ones. It is possible to build reliable applications using HTTP. Reliablility is, of course, bounded by the physical universe. When someone unplugs the power cable neither MQseries nor Mozilla are going to deliver the message. The virtue MQseries has over Mozilla in terms of reliability is in terms of *reliable software engineering techniques* and not in terms of the wire protocol (which is probably undocumented and certainly irrelevant). HTTPR attempts to make it *easier* to build HTTP applications with once-and-only-once delivery characteristics (as opposed to making it possible, which it already is). Unfortunately, it brings in a bunch of message queuing complexity that seems like it would actually make life harder. I can teach a knowledgeable web programmer to make reliable (in the messaging sense) HTTP-based applications in about fifteen minutes. If you actually want message queuing, etc., that's fine. But it isn't a case of one is the basis for reliable apps and the other isn't. Paul Prescod
|
