[
Lists Home |
Date Index |
Thread Index
]
"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
|
