[openbeosnetteam] Re: A possible redesign

> > > Doesn't this reference eat up more memory than the entry itself? 
> > > I
> > > think
> > > this is too slow.
> >
> > It might well be slow. But with integer handles and references into 
> > the
> > stream, it might not be much slower than now, especially when many
> > packets get parsed multiple times.
> 
> 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.

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

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

> If a company (AOL?) wants to write a translator they can use these
> structures if we make them _complete_. If every feature of IP and 
> Ethernet
> (and other protocols) is supported we do not have to bother about it.
> I do not say this is easy, but it can be done.

Right.

> > > With user-level I mean the normal application level (not kernel-
> > > level). It
> > > is for the programmer who needs access to those attributes. The 
> > > user
> > > should
> > > not be interested in it, but are these attributes usable only by
> > > kernel
> > > modules or by application, too?
> >
> > Right, and by "user" I meant the calling application. Since TCP is 
> > a
> > stream-oriented interface, packet attributes make little sense to
> > transmit. They might make more sense with UDP (conceptually), but I
> > can't think of any real benefit of knowing them either. Perhaps we
> > could have an optional interface to retrieve them.
> 
> It is not really needed, but why should we implement attributes then? 
> (See
> above)

It makes things easier, cleaner, and slightly more efficient. Other 
than that, no particular reason.

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

Other related posts: