[Ns-developers] TCP and UDP layer refactoring

[craigdo@ee.washington.edu]

> > Having said that, there seem to be cases in our code where 
> tags are used to
> > avoid having to plumb parameters through the code (I won't 
> use the word lazy
> > :-).  For example in the sockets code, an address tag is 
> used to attach a
> > packet address to a packet that is pushed on a packet queue 
> and is gotten on
> > the way out of the queue.  This strikes me as an abuse of tags.
> 
> Maybe. I see this case as being similar to "anciallary data", 
> that is, a
> way to pass across an API a set of per-packet information.

The particular case I am thinking of is not across an API, it's used to
avoid having to make a place to stash the address information internal to a
socket module.  I think maybe the socket address tag was used a while ago to
attach source addressing information to a packet gotten through recv; but
now that we have a recvfrom, its only purpose seems to be to provide an easy
way to avoid having to store the address internally to the socket module.

> > Tags seem to me to be a mechanism to attach useful 
> information to a packet
> > that flows across boundaries where you would normally not 
> want or be able to
> > plumb in parameters (i.e., across channels, cross-layer 
> info, flow info).
> 
> yes.

I would like to put this to bed, at least provisionally.  I still think the
solution to the echoed packet address weirdness is fixed in the wrong place;
and that the csma net device parameter situation would have been a good
prospect for a tag.

I'll volunteer to make a FindLastMatchingTag and to add documentation to
Packet and Tag to try and make it at least a little clear what to expect
when using these puppies.

This deserves a HOWTO as well.

-- C