[EMAIL PROTECTED] wrote:
> One of the more interesting problems we have with OpenSolaris'
> networking is that the structure and contents of the mblk seem
> to be fixed (for all time.)
>
> This is somewhat at odds with evolving networking in OpenSolaris
> as there's an invariant here that is limiting us. At least two
> projects have contested for the right to use part of the few
> remaining bits in the flag field and without doubt there will
> be more.
>
> Why do people want to use flag bits? Because it's the only way
> to store a single bit of "private" data on the mblk and have it
> be carried forward...
>
> Which brings is to the problem.
>
> 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.
I don't think the above description is sufficient to figure out what
approach might make sense. There can be many different meanings of
"carried forward" above. A few possibilities are:
- Some part of TCP/IP wants to set something that another part of
TCP/IP wants to look at, i.e., it is local to TCP/IP.
- The thing should be carried forward from a receive packet to a
transmitted packet as part of forwarding.
- Carry it to TCP/SCTP and they will use it for sending subsequent
packets.
- Carry it to the application so that it can potentially use it for
other communication.
- Some plugin mechanism in the stack should allow for 3rd parties to
write "modules" that can both set meta-data and check it i.e., the 3rd
party provides different modules that plug into different parts of the
stack. (Note that we don't really have such a plugin mechanism today -
apart from STREAMS modules.)
The first case is fairly well understood, and can be handled by defining
some attribute data structure which is passed as procedure call
arguments instead of as something tied to the mblk/message/packet. (And
IP Datapath Refactoring is planning to do exactly that to get rid of
prolific M_CTL usage, ip6i_t, etc.)
For the last case, if we define a plugin mechanism, for the meta data to
be useful we would also need to carefully specify where that meta data
is carried transparently and where it is not.
For instance, would or would not udp_rput be required to pass up the
meta data so that a "module" above could inspect it?
Would a kernel socket API have to pass it up?
Should TCP use it for response traffic or not?
What about forwarding.
So to me this sounds like an ill-defined problem. Looking at the real
underlying problems that we want to solve is probably needed so we can
have a better problem definition.
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
