[openbeosnetteam] Re: A possible redesign

> > > 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.

This isn't necessary. We can easily provide them (for long bits of 
data, for short ones it isn't efficient) as pointers into the packet or 
as mbufs, similar to the way it would be done if parsed by hand.

> And do you think we should lock
> the attributes to be thread-safe? This would be too much overhead.

I don't see any reason why a packet would be in use by multiple 
threads. A packet's trip through the netstack is thoroughly linear.

> And to have optimized code we need int32 values instead of strings. I 
> hope
> that collisions will never happen...

Yes, of course. And so long as we flush old attributes, this shouldn't 
be an issue. We could also provide attribute groups, I suppose.

> > > 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.

Sounds better, or at least faster.

> Hopefully we will get a C++ API one day...

Yeah. OO in C can get pretty hairy.
-Nathan

Other related posts: