On 8 Jun 2009, at 12:15, Iljitsch van Beijnum wrote:
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.
use of PUT gets around the initial request and response for long-delay
links.
('Delay-tolerant' is really an umbrella term to mean 'delay and
disruption tolerant' these days, widening the scope from the original
deep-space scenarios you discuss to include everything that is not the
terrestrial internet. The term itself has become something of a
misnomer for the majority of scenarios, but it's still on the banner
being waved by academic research.)
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.
again, PUT allows that. The responses (if any - I can see a case for
blind unidirectional PUTs) get daisy-chained into the persistent
pipeline going the other way. The long propagation delay due to the
speed of light is unavoidable, but handshaking in initial request/
response setup can be prevented, leading to a one-RTT exchange time.
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.
Having a high-level e2e check is useful. I don't see how checking data
reliability is an invitation to play fast and loose with the transport
underneath. When dealing with disrupted networks, links that change
quality or drop unexpectedly, etc., Content-Length: and Content-MD5:
become useful in evaluating whether what has been received is
worthwhile or should be discarded. Content-MD5: becomes particularly
useful for checking reassembly of partial transfers. And, of course,
in this dtn approach the data is copied multiple times across multiple
transfers across multiple separate concatenated reliable transports.
Always useful to be able to verify that what comes out of the end of
that process is what went in before giving it to the app.
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.
If the application is entirely unaware of whether the http library
opens a new tcp stream, or reuses an existing one, I'd argue that it
thinks that a session is being maintained...
Using the same OSI model argument, the transport layer is above the
network layer, which means that you can maintain a transport across
network instances. Ergo, TCP, which traditionally sucks at multihoming
and having addresses change on it, is not a(n OSI) transport layer[*].
But we knew that. The 'session' label still fits, even if the OSI
dogma does not.
[*] While SCTP is, which somehow figures since it was designed to
support ITU-T SS7 telephone networks...
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.
DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
<http://info.surrey.ac.uk/Personal/L.Wood/><[email protected]>
