apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Kenneth Casson Leighton <l...@samba-tng.org>
Subject Re: [RFC] Network Abstraction Layer
Date Fri, 02 Mar 2001 10:16:27 GMT
On Fri, 2 Mar 2001, Greg Stein wrote:

> Getting long here. Watch out! :-)

other-thread.
 
>   BRIGADE = { FILE, EOS }    # FILE bucket and EOS (End Of Stream) bucket
> 
> becomes
> 
>   BRIGADE = { "packet header bytes", FILE, EOS }
> 
> We inserted a header without touching the file. The output filter generates
> a sendfile which contains an iovec for those header bytes. Blam! Out the
> network it goes... :-)

EXCELLENT.  this is exactly the kind of thing that we'll need to do / use.

i started on something like this - memory-based only.  it involved
chaining of bits of memory together, and you didn't have to worry about
how long they each were.

like it a lot.

so, one bucket can deal with the NetBIOS header.

one with the SMB header.

one with the IPC$ layer.

one with the SMBtrans layer.

one with the DCE/RPC pipe layer.

one with the DCE/RPC header layer.

one with the DCE/RPC data.


that's the sort of depth we're going into, here!  and for simplicity, i've
left out all the authentication and encryption stages!

so...

... we still need an apr_bucket_NAL which can "bounce" in-and-out of
buckets, _even though it may actually be implemented as buckets itself,
underneath!_ and handle the possibility that on one particular OS - e.g.
NT - is in fact a call to a kernel-level function, e.g. CreateNamedPipe().

or even, later on, let's say that someone decides to provide a linux
kernel-level SMB layer or even a NetBIOS kernel API.


as you can see, seven levels of buckets like that - all of which a
programmer will need to be "aware" of - is exactly what makes me very,
very wary of introducing "newbie" programmers - no matter _how_ skilled or
advanced or experienced they are - into this kind of environment.

if we can split things out so that an individual programmer only has to
deal with *at most* two layers - the one they're coming from and the one
they're going to - i'll be well-happy.

and to do _that_, in TNG, i decided to split at the SMBtrans / DCE/RPC
pipe layer with a unix-domain-socket.  and on NT, that is going to be
CreateNamedPipe() that will do that for us, bypassing the
SMBtrans-and-below layers altogether.

and still get good code reuse / abstraction.

what you think?

luke

 ----- Luke Kenneth Casson Leighton <lkcl@samba-tng.org> -----

"i want a world of dreams, run by near-sighted visionaries"
"good.  that's them sorted out.  now, on _this_ world..."


Mime
View raw message