On 7 Jun 2009, at 10:32, Iljitsch van Beijnum wrote:
On 5 jun 2009, at 14:04, Lloyd Wood wrote:
I.e., what is the benefit of the extra protocols in the middle?
Abstraction. If you write an application that uses network
communications, why would you write low-level socket code in this
day and age? You'd write to a higher level of abstraction and avoid
reinventing the wheel.
Reusing code always seems like a good idea until you actually try to
make it work.
Regardless, a piece of reusable code doesn't automatically make for
a protocol.
When that piece of reusable code communicates over the network in
standardised ways, it does.
(Other benefits in this particular case are outlined in draft-wood-
dtnrg-http-dtn-delivery.)
(*cough* session layer *cough*)
Sessions with HTTP? Ha.
HTTP/1.1's persistence, pipelining and chunked transfer encoding give
it a level of control that can be argued to be session management.
It's a lot more than 'open TCP connection/send one thing/close TCP
connection' these days.
Can you explain a bit more? HTTP runs over a "real" transport
protocol. I assume this won't change. Do the internals of HTTP
change? Or its interface to upper layers?
Do the internals of TCP change when it's running over IPv4 vs IPv6?
Does the interface to upper layers change?
Is answering a question with a question useful?
It deliberately set up discussion of an analogy in later emails in the
thread, which you may not have read.
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.
DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
<http://info.surrey.ac.uk/Personal/L.Wood/><[email protected]>
