[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. :(
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.
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.
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.

> > > > You mean that IP does not have to know anything about Ethernet
> > > > broadcasting
> > > > because the translator knows it?
> > >
> > > Right. In fact, the IP addon wouldn't need to know anything about
> > > ethernet at all, because the translator handles that.
> >
> > I like this concept, really. The next netstack should implement this.
>
> Thanks.

You are welcome. :))

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

> > > > How do you want to implement this exactly? An HTML presentation
> > > > would
> > > > be
> > > > useful. ;)
> > >
> > > That might actually involve work :P. What questions would have in
> > > regards to the implementation?
> >
> > You do not have to do it, but it would be nice. Just start from the
> > beginning. ;)
> > What are you currently working on? Maybe this should be done when R1
> > has
> > been released because we need a basis before doing something else.
>
> I'm currently working on school, and have been fiddling with the kernel
> to try to get it running on PowerPC, which because it involves
> installing Linux (to get a gcc that outputs ELF) has been
> extraordinarily difficult with very little reward. But yeah, I could
> try setting up a tiny reference implementation of this kind of stack.

Cool, but do not forget school. ;)
I must read two books, so I cannot code too much. The weekends are the best
time to code one or two hours.
I am still at the stage of designing everything. I want to use C++ and for
this I need a NetPacket implementation that is general enough to support
future net_data implementations. Then I would like to use something like
NetProtocol and derive PPPProtocol and PPPoEProtocol from it.
PPPProtocol uses NetData objects (that PPPLCPPacket derives from, for
example) to describe the data. PPPLCPPacket uses PPPLCPData (that
PPPConfigureRequest could derive from) to send a conf-req.
This may be too blown-up, so it needs some work. I did not really think
about it.
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.... ;)

Waldemar

Other related posts: