Nicolas Williams wrote:
On Thu, Jan 04, 2007 at 03:05:05PM -0500, Brian Utterback wrote:
It seems backwards to me because:
1. The purpose of fused connections was to reduce the TCP baggage,
not introduce more.
This seems wrong to me. Fused connections are needed to realize the
better performance that one would expect from being all-local. No ACKs
are needed, for example, because there are no packet drops. And both
nodes know exactly how much buffer space their peer has.
I think we are saying the same thing in different ways.
There is still a need for flow control though. IMO that flow control
needs to be about free buffer space in the receiver, but if we have
STREAMS in the way and it can consume additional resources (from a
finite pool) then the flow control needs to flow down the STREAMS as
well.
I find this 8 message thing as lame as you do. But I don't understand
STREAMS well enough, much less TCP fusion to offer alternatives.
2. As far as I know, no other IPC method imposes this kind of flow
control. Why single out TCP?
Pipes certainly impose flow control!
The important point was "this kind". Of course you need flow-control.
(we do get a lot of customer calls because pipes have a fixed buffer
size on Solaris though. Has this been fixed?)
Most other IPC are not stream-oriented, but there's still some flow
control (e.g., door_call() can block if the server's threads are all
busy and no new ones can be created). Either you have flow-control on
unreliable IPC: resources are finite.
Nico
--
blu
"The genius of you Americans is that you never make clear-cut stupid
moves, only complicated stupid moves which make us wonder at the
possibility that there may be something to them which we are missing."
- Gamal Abdel Nasser
----------------------------------------------------------------------
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
_______________________________________________
networking-discuss mailing list
[email protected]
