From: Lucas Gonze (lucas@worldos.com)
Date: Fri Aug 18 2000 - 18:06:23 PDT
I am not sure if we're talking about the same thing, Henrik. My point is
that using HTTP as a substrate for protocols that need reliable message
sequences leads to a situation where you have to redo all the stuff that TCP
adds to IP. (EG message numbering and retransmission). This is because
proxies in the data stream do a flaky job with ongoing connections. ...it's
as if connections on either side of a SOCKS proxy had to be ready to restore
the connection at any time. You wouldn't do it, because the better approach
would be to fix SOCKS.
One of the big attractions of HTTP as a substrate is the existing base of
implementations. But the installed base pretty much never includes code to
handle lost messages, so it is only useful for browser-style interactions.
> Wait - I can't see - I have FUD in my eyes.
;). The stuff about proxy interaction in the SOAP spec doesn't address lost
messages, I believe.
My point isn't that HTTP is bad, it's that having return data disappear in
transit makes it unreliable for two way messaging.
- Lucas
----- Original Message -----
From: Henrik Frystyk Nielsen <frystyk@microsoft.com>
To: Lucas Gonze <lucas@worldos.com>; Adam Rifkin -4K
<adam@xent.ics.uci.edu>; <FoRK@XeNT.CoM>
Sent: Friday, August 18, 2000 10:32 AM
Subject: RE: [HTTPfutures] Dan Connolly on HTTP goofs and musings / Two Way
Web
> > Proxies unilaterally disconnect long lived streams at a
> > timeout, usually
> > 5-15 mins. Without acks it is impossible for a sender to know which
> > messages were sent but not received. So an http based
> > protocol like SOAP
> > has to support retransmission by numbering packets, caching
> > them, setting up
> > some kind of ack, and manually doing reassembly. In other words, the
> > browser assumptions of the infrastructure force us to
> > reinvent TCP on top of
> > HTTP as if HTTP were IP, and that leads to a situation where
> > we get TCP,
> > except slow and buggy. bleh. bleh. bleh.
>
> There is nothing new in the fact that TCP reliability breaks down in
> connection reset phase - it can't really be done any other way. Reset is
> by definition messy. There is nothing specific to proxy servers here - you
> can't pipeline POST requests and proxies don't buffer responses up.
>
> There is also nothing new in that you might have hooks for realibilty and
> acknowledgements at several layers. This doesn't mean that you have to
> reinvent TCP.
>
> Of course SOAP isn't particularly designed to be an HTTP based protocol.
>
> Henrik
>
>
This archive was generated by hypermail 2b29 : Fri Aug 18 2000 - 15:15:55 PDT