On Fri, 14 Sep 2007, Keith Moore wrote:
I actually don't think that having multiple concurrent TCP connections
between two peers is a bad thing. sure we could have a transport
protocol that provided multiple streams, but why bother when concurrent
TCP connections works pretty well?
I agree, except that "pretty well" is a bit crappy when every connection
has to re-establish authentication and encryption - which is what drives
some protocols to implement their own multiplexing.
mumble. I don't have a problem with multiple TCP connections, but OTOH
I think that using TCP close for framing is bad application design. so
I don't view persistent connections in HTTP as a workaround, I view it
as fixing a design flaw in HTTP/1.0.
I agree, especially because some software has problems telling the
difference between clean and dirty closes. However there's a latency /
efficiency trade-off, and TCP pushes you towards pipelining multiple
transactions down a few connections even when a more natural design
might have greater concurrency. mumble.
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR
MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf