On 5 Jun 2009, at 12:12, Iljitsch van Beijnum wrote:
On 4 jun 2009, at 18:24, Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:
The distinction
between these two layers (transport and application) is quite
blurry when it comes to "applications" that end up being used
as middleware for other applications. Application protocols
stacked on other application protocols 3 or 4 deep is no longer
uncommon,
Why is this a good idea, though? If a packet gets lost doesn't TCP
retransmit? If data doesn't fit in one packet, doesn't TCP segment?
If you prick it, doesn't TCP bleed?
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.
And this higher level of abstraction can run over protocols that are
not TCP.
You want SOAP over SCTP? Well, HTTP over SCTP is needed. Running XML-
RPC in a low-latency cluster where TCP is a bottleneck? Replace TCP
with something higher-performing, without changing or rewriting the
rest of the stack above HTTP.
(*cough* session layer *cough*)
But back to the point on this thread ... considering that the
proposal is to use HTTP to provide an interface for transport
services, and not to extend HTTP as it also exists as a
top-of-the-stack application, it is definitely more applicable
to the TSV area than the APP area.
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?
There's a question as to how much HTTP gets adapted for each local
transport protocol,
or whether HTTP just uses the 'reliable bytestream' paradigm as the
bare minimum.
DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
<http://info.surrey.ac.uk/Personal/L.Wood/><[email protected]>
