apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elrond <elr...@samba-tng.org>
Subject Re: [RFC] Network Abstraction Layer
Date Thu, 01 Mar 2001 19:17:10 GMT


On Wed, Feb 28, 2001 at 07:40:21AM -0800, Greg Stein wrote:
> >...
> > Below is a simple draft of the NAL. The goal is to be able to
> > add transports easily, even when not present in the kernel.
> > Also this allows an easy way of protocol/transport stacking.
> > A 'transport' can also do buffering, authentication, filtering.
> It might be interesting to examine the filters that we have in Apache right
> now. They provide for the protocol-stacking, buffering, and (hey!)
> filtering.

The filters are currently in Apache itself?
That might explain, why I didn't find anything relating to
filter in apr-util.

If filters actualy are, what we're looking for, it would be
nice, if the base of the filters (not the filters
themselves) be moved into apr-util.
This might be a good idea anyway.

> Apache handles authentication outside of the filter stacks. (two: one stack
> for input, one for output)
> That said: what you outlined is reasonably close to a concept we had a while
> back called IOLs. (Input/Output Layers)  They were tossed about six months
> back in favor of the filter stacks.
> Filters are actually very little code. The heavy lifting is all in the
> buckets and the brigades (see APRUTIL's "buckets" directory). For the most
> part, implementing a filter stack is mostly design policy rather than code.
> What I'm trying to say :-), is that almost everything is already there. If
> there *is* something missing, then we can shove it down from Apache.

I've read the complete apr_buckets.h.
>From a _very_ high point of view, bucket brigades are a
list of buckets, and buckets are simply referring to static
read-only data, which was (or will be) created.

So this is a nice way of moving around data basicaly.

> The essence is that you create a brigade of some data. Then you pass that
> brigade through N functions which each manipulate the brigade in interesting
> ways. Let's take a simple case of generating a file request over an
> encrypted pipe:
> *) Samba creates a brigade containing two buckets: a FILE bucket for the
>    request pipe, and an EOS bucket to signify "end of stream"
> *) the brigade is sent into the "output stack" associated with the current
>    request
> *) the output stack happens to have two filters in it: an encryption filter,
>    and a network filter (the latter places the brigade contents onto the
>    network).
> *) the encryption filter sequences through the brigade, rewriting the
>    contents for the requested encryption. it periodically flushes chunks of
>    work to the next filter in the stack.
> *) the network filter places the content of any brigades passed to right
>    onto the network.
> So... that is the design we happen to be using in Apache, and is emboded in
> the various APR and APRUTIL bits. It might be interesting to determine
> whether a similar design would work for Samba's needs.

Some of our protocol layers might be actualy doable as
filters. (SMB itself quiet likely, at least for the
fileserving part, SMB does more than fileserving, but it
probably resembles http in some ways)

The part, where Sander's NAL comes in, is the one filter
that writes stuff to the network:

In Apache this is most likely a simple unix tcp socket,
into which you write data.
NAL tries to abstract sockets.

The issue here is, that the protocols, that are below SMB,
are more like sockets. From a clean point of view, they
should be implemented in the kernel, but none of us is
willing to write kerneldrivers for each OS out there.

If you look through Sander's proposal, nearly all typical
Unix socket operations are represened as function pointers,
and actualy nearly each of them needs to be implemented,
and most of them will actualy do something complex.

I see one correlation point to filters:

Maybe there should be an optional
"append_output_filters_to_filterstack" and
"prepend_input_filters_to_filterstack". That way, if the
socket can be represented as filters, and the socket-writer
has the energy to write those filters, that can be
optimized. Functions are needed, because the actual used
filters can be quiet dynamic and could depend on the remote
system, that we connect to, or if someone actualy
implemented those sockets in the kernel.

The fallback is more or less clear:
append_output_filters_to_filterstack defaults to a simple
filter, that takes the whole brigade and write()s it into
the socket.

prepend_input_filters_to_filterstack defaults to the
Maybe we also might have a apr_bucket_NAL, which is a
bucket, that reads its data from a NAL socket.

I'm not too sure, which of the last ones is actualy the
right thing to do.

The next interesting point is, that NALs might have their
own idea, of how select()/poll() should be handled for

I hope, that explains somewhat the intention behind NAL.

Here are some examples of NALs, that are either interesting
to us, or just fictitious:

- unix domain sockets (with authentication)
- NT named Pipes (those are like Unix domain sockets and
  include authentication already, while the unix side needs
  to add that)
- The former two can be wrapped in a single "IPC"-Facility.

Now some fictitious ones:
- IPX using raw sockets
- NetBEUI using raw sockets

> > Ignore name clashes with current APR code please.
> > Also, I haven't looked into the apr_pool package to understand
> > how it works quite yet. I want it to be _possible_ to tie transports
> > to memory management (so we can dump all memory that we used for:
> > a session, a request, a reply, etc).
[... explanation about pools ...]

I haven't looked at pools right now, so if you don't feel
like answering, simple "RTFM" is okay.

BTW: Do the things in the pool have reference counts? I
mean, is the pool itself offering refcounting?

And I've also seen, that the included objects are included
with a destroy-function, so one can have pools in pools,

> > I'll post a memory management draft aswell in a few days. It will
> > be similar to this when it comes abstraction.
> Look forward to it :-)
> Cheers,
> -g


> -- 
> Greg Stein, http://www.lyra.org/

View raw message