Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.Hawaii.Edu!news.caldera.com!enews.sgi.com!ix.netcom.com!worldnet.att.net!howland.erols.net!news.mathworks.com!uunet!in1.uu.net!206.117.26.202!news.leonardo.net!news.vbc.net!vbcnet-west!news.mira.net.au!news.netspace.net.au!news.mel.connect.com.au!news.syd.connect.com.au!news.bri.connect.com.au!fjholden.OntheNet.com.au!not-for-mail
From: Tony Griffiths <tonyg@OntheNet.com.au>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Sys V Streams Vs. BSD Sockets
Date: Thu, 03 Apr 1997 18:06:44 +1000
Organization: On the Net (ISP on the Gold Coast, Australia)
Lines: 49
Message-ID: <33436514.6DD0@OntheNet.com.au>
References: <5h4rte$92a@news.interlog.com> <3337E127.7BEA@xnet.com> <87913ay08y.fsf@plm.xs4all.nl> <E7x8rM.4rE@sep.hamburg.com>
Reply-To: tonyg@OntheNet.com.au
NNTP-Posting-Host: swanee.nt.com.au
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.0 (WinNT; I)
To: Helge Oldach <hmo@sep.hamburg.com>
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:38331
Helge Oldach wrote:
>
> In <87913ay08y.fsf@plm.xs4all.nl> Peter Mutsaers <plm@xs4all.nl> writes:
> | Streams is cleaner, it is a general message passing mechanism to
> | implement drivers. But it is also much slower, amongst others because
> | of extra copying.
>
> Er, basically no. Streams does in fact avoid copying buffers as much as
> possible, just like BSD sockets. The trick is to move pointers up and
> down the module chain, and chopping or adding headers and trailers from
> the pre-allocated space.
BSD does the "move buffer pointer" stuff as well with it's mbuf's! What
is different is that sockets/protoswitches (the BSD approach) doesn't
carry
around the baggage of the M_PROTO buffer which contains the marshelled
arguments that BSD simply passes as 'normal' function arguments. Eg.
(*pr->pr_output)(mbuf_p, type, ...) /* Call lower module's output
rtn */
while Streams would have to move the arguments into the M_PROTO buffer
and then enqueue this buffer onto the lower modules input queue and then
possibly schedule this module to run, etc. On a uni-processor, this is
an awful amount of work for no REAL gain in the TCP/IP or OSI networking
world because the protocol stack is relatively (absolutely in the case
of
TCP/IP) statically defined so the linkages are known a priori.
On a multi-processor, the fact that each module could run in a separate
thread concurrently 'might' provide some performance benefit, but I have
my doubts having been part of a group that studied the possibility of
changing from BSD sockets/protoswitches to Streams.
>
> The reason why it's slower is indeed the more general approach of
> pushing task-specific modules onto the stack, so you can design your
> mission-specific protocol stack at run-time. One might consider this
> overkill, given that most protocol functionality will remain unchanged
> over time.
This is definitely true for TCP/IP and we found it to be the case also
for OSI with only a very limited set of option of what module could
logically sit above you and what could go below!
For something like a terminal data handler, the Streams approach makes
more sense in that each module in the stream path is it's own "filter".
Tony