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@xxxxxxxx> http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf