[openbeosnetteam] Re: A possible redesign
- From: "Waldemar Kornewald" <Waldemar.Kornewald@xxxxxx>
- To: <openbeosnetteam@xxxxxxxxxxxxx>
- Date: Thu, 17 Apr 2003 10:46:25 +0200
> > 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?
> > Do I understand you correctly that you want to use translator modules
> > for
> > each protocol combination?
>
> Yes, although it needn't be a separate add-on, and could be very, very
> light.
I like this idea very much. Please implement it. :)
> > IP is a module that exports some attributes and Ethernet, too. There
> > are no
> > hard-coded types in both protocols. To connect IP with Ethernet we
> > need a
> > translator module that knows the attributes of IP and Ethernet.
> > Additionally, this module combines all attributes into standard
> > attributes
> > so that they can be used by applications?
> > Why do we need a standard set of attributes? IPv6 uses other IP
> > addresses
> > than IPv4. Shouldn't applications be aware of this? I mean, there are
> > many
> > protocol-specific attributes that are useful to the app-layer. How do
> > you
> > want to translate the concept of ports? I think I did not understand
> > what
> > you mean with "standard 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?
Are the attributes exported to user-level? Does the BSD-compatibility layer
translate our attributes into structures?
How do you want to implement this exactly? An HTML presentation would be
useful. ;)
Waldemar
Other related posts:
