Nicolas Williams writes:
> BTW, is there some key that one can use as a key to an associative array
> to track a single tcp "output" down to the network layer? Some sort of
> packet ID or STREAMS message ID, or something of the sort?
No.
It's a bit of an ugly problem. Messages are transformed in the stack
(allocate new dblk, copy data over with some changes; think IPsec
ESP), split into separate messages (TCP segmentation and IP
fragmentation), joined together (reassembly), and even spawn new
messages (ack-clocked transmission) that are logically related.
When I trace messages in the stack, I usually use an associative array
with either the mblk_t or dblk_t address as a key. It's functional
for some trivial debugging cases, but when things get complicated or
involve long-duration problems or post-mortem analysis, it's lame.
> I really think that threading packet processing is just not a well-
> thought out feature and not necessarily easy to implement with the
> current infrastructure. I don't think the project team should be
> burdened with adding it.
Agreed. More importantly, it's not related to the current proposal.
(It's an data-oriented view rather than a function- or action-oriented
view.)
But I do think that it'd be a useful feature for known customer
problems ("I see packet X on the wire, but Solaris seems to ignore it
... why?"), if someone could pull it off.
--
James Carlson, KISS Network <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]
