[openbeosnetteam] Re: A possible redesign
- From: "Nathan Whitehorn" <nathan.whitehorn@xxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Fri, 18 Apr 2003 10:40:38 -0400
> > > Is this fast enough? I mean, we would have to copy the attributes
> > > or
> > > at
> > > least specify where they are and how much space they use (and
> > > which
> > > type,
> > > like int32+endianness). Alternatively, attribute access could be
> > > routed to
> > > each protocol, so that we do not copy attributes. Where is the
> > > difference to
> > > the current implementations? We ask the IP protocol for the IP
> > > address.
> > > IMHO, this is like asking for an attribute.
> >
> > It could be quite fast. We needn't use strings, for instance, as
> > BMessage does.
>
> 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.
> > I meant for each layer. So there would be some attributes exported
> > by
> > the IP layer (addresses, etc.), some by ethernet, some by ipv6. As
> > an
> > example of translator addons producing attributes, ethernet ip
> > modules
> > are responsible for telling ip about link-level broadcast packets.
> > Thus, you could have a 'broadcast' flag.
> >
> > The major conceptual difference is that these attributes are
> > associated, pre-parsed, with the packet rather than delivered in
> > raw
> > form or attached to the module.
> > -Nathan
>
> 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.
> 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.
> 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?
-Nathan
--
Fortune Cookie Says:
Dessert is probably the most important stage of the meal, since it will
be the last thing your guests remember before they pass out all over
the table.
-- The Anarchist Cookbook
Other related posts:
