[openbeosnetteam] Re: A possible redesign

> > > Yes, if we use int32s and specify (like in BMessage:what) which 
> > > id
> > > belongs
> > > to which attribute it could be quite fast.
> > > This might lead to collisions. How is this prevented? By 
> > > specifying
> > > the
> > > module when asking for attributes?
> >
> > Luck? :P We could demand prefixes, for example, like ethernet
> > attributes have ids beginning with 'EN'. BMessage what attributes 
> > don't
> > often suffer name collisions, as you mentioned. You could also have
> > only the attributes from the last network layer attached, thus
> > eliminating the chance of collisions entirely. Also, as much header
> > information in many protocols (like PPPoE) is set up as a key/value
> > structure with integer keys, you could just place that data 
> > straight
> > into attributes.
> 
> Are attributes references to positions in the packet or copies of the 
> data?

It could be both or either.

> Do you specify their length?

Probably.

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

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

> > > Are the attributes exported to user-level? Does the BSD-
> > > compatibility
> > > layer
> > > translate our attributes into structures?
> >
> > I don't see why they would be. The user really has no reason to 
> > care,
> > and for things like TCP, packet-based attributes don't make much 
> > sense,
> > since the system isn't packet-based.
> 
> 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.
 
> > > 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.
-Nathan


--
Fortune Cookie Says:

Go placidly amid the noise and waste, and remember what value there may
be in owning a piece thereof.
                -- National Lampoon, "Deteriorata"

Other related posts: