On 8 jun 2009, at 9:46, Lloyd Wood wrote:
Other benefits in this particular case are outlined in draft-wood-
dtnrg-http-dtn-delivery.)
http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery-03
I haven't followed delay tolerant networking, but using HTTP here
seems rather curious to me unless the delay toleration isn't very
ambitious, as HTTP is a request/response protocol. This means that if
you want to use it towards the Cassini orbiting Saturn, you're wasting
half an RTT (about 1.3 hours) of usable communication time waiting for
the HTTP request to get there. If each side can autonomously send
messages without a request/response cycle that's much more efficient.
Also, the MD5 business is extremely curious, this is just an
invitation to implementers to play fast and loose with the underlying
reliable transport that HTTP requires.
HTTP/1.1's persistence, pipelining and chunked transfer encoding
give it a level of control that can be argued to be session
management.
In the OSI reference model, the session layer is above the transport
layer, which means that you can maintain a session across transport
instances. This is a very weak point in HTTP (which pipelining etc
don't address), although of course many people have implemented hacks
to do exactly this.
After a dozen or so messages it's still profoundly unclear to me
what the work would be that we're talking about. But everything
that's mentioned is something relevant to applications, not the
internals of transport protocols.
I look forward to going to the apps area to be told that defining
HTTP-over-Transport-X is a transport problem.
Well, IP over ethernet is an internet standard, not an IEEE standard.
I would be surprised if the app people sent you back here.
DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
<http://info.surrey.ac.uk/Personal/L.Wood/><[email protected]>
