[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?
Do you specify their length?
Doesn't this reference eat up more memory than the entry itself? I think
this is too slow.

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

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

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

Waldemar

Other related posts: