[openbeosnetteam] Re: A possible redesign

> > The decoding process will eat up too much time, IMHO. It is not worth
> > the
> > effort. Routing attribute access to each protocol involves a switch
> > to
> > kernel level, so that is not acceptable, too. :(
>
> How is this? I'm not talking about fs attributes.

Oops, I forgot that packet attributes are not exported to user-land. :)

> > I have a question: who benefits from this concept? I mean, the IP
> > module
> > either exports its attributes or a structure. The translator module
> > has to
> > interpret this, but IMHO it does not really matter which one it must
> > understand. It must know the type anyway.
>
> As far as I'm concerned, a structure is a kind of attribute. I am just
> suggesting the inclusion of meta-data with packets in some standard
> format.

I now see the benefit, too. The ifnet and ifaddr structures are too static.
It would be better if we changed the whole API. :)

> > Why don't we just use attributes for saving information that is
> > specific to
> > interfaces and protocols, but not for packets?
> > What did you intend to make better with attributes? As applications
> > do not
> > handle net attributes it is not useful for them. Protocol translators
> > could
> > be more independent because they are not bound to a specific
> > structure. On
> > the other side we are the ones who implement the translators and
> > protocols,
> > so we can change it.
>
> It just makes things easier. Right now, for instance, TCP, UDP, and
> ICMP all need to parse every IP packet. Every base protocol needs to
> parse every IP packet (at least a little). Why duplicate all that code?
> And if the parsing needs to be done (and it always does, at some
> point), why not just do it once, and include the results, instead of
> redoing it multiple times (one parse, at the very least, which is just
> as efficient as this, since it's the same thing).

But we duplicate the data inside the headers. If this is still faster than
decoding it every time I would give you my okay for it, but I think that
copying and inserting the header attributes makes it so slow that we could
better implement the code for each module. And do you think we should lock
the attributes to be thread-safe? This would be too much overhead.
And to have optimized code we need int32 values instead of strings. I hope
that collisions will never happen...
If we can solve these problems it would be a better system than compared to
what we have now.

> > Maybe PPPLCPPacket should derive from PPPData (that derives from
> > NetData)
> > because each protocol must know its type. This way it could be easy
> > to
> > support sub-add-ons that add functionality like authenitcation
> > protocols or
> > software compression. I will present the final decision here before
> > starting
> > to code because you (and others) have more experience with PPP than I
> > have.
> > So, if you want to help me.... ;)
>
> I'd reccomend looking at my PPPoE code... I did something very similar
> to this, with subclassed packet types.

I already dropped this idea. Instead of PPPData mbufs will be used.
Hopefully we will get a C++ API one day...

Waldemar

Other related posts: