[EMAIL PROTECTED] wrote:
> For people that want to build on top of OpenSolaris, there is
> no way to attach private "meta-data" to a packet as it enters
> the system on one interface and be able to retrieve it as it
> exists the system on another. We need the means to do this.
FWIW, I think this question periodically came up over
the last (10+) years... Maybe it is time for us to
solve it at last?
> There are some options here, but not a lot of them:
>
> 1) We actually extend the mblk to have another field that is
> a pointer to a chain of meta data and we further define how
> that meta data is treated as various things happen to the
> packet as it moves through the system.
As expected, this was proposed before. Besides the
semantics questions of how to deal with this pointer
when, say dupb(), copyb(), ..., we just cannot change
the size of mblk_t unless we don't care if any third
party software will break :-(
> 2) We invent a new data structure to pass around that contains
> a pointer to the mblk_t rather than the mblk_t itself and we
> define it in such a way as to allow it to carry private data.
> There isn't a chain of these data structures, just one -
> a packet head structure if you like.
I remembered that this was proposed before. One
big problem is that "every" piece of networking code
expects a mblk_t. While we may put in the huge effort
to change all of our code to use that, the third party
software issue is still there :-(
> 3) ??? maybe define a new mblk type ???
This was also proposed before after (2) was rejected.
And one such attempt is already in the gate, multidata_t.
Although the name may suggest that it is only for more
than one message, there is no restriction that a
multidata_t mblk must carry more than one message. There
is the pattrinfo_t packet attribute to store whatever
private data the caller wants.
--
K. Poon.
[EMAIL PROTECTED]
_______________________________________________
networking-discuss mailing list
[email protected]