[Ns-developers] [ns3] byte-level tags

[Mathieu Lacage]

hi,

Bug 166 outlined recently a that one of our "features" was going to be a
problem for stream-based sockets. Namely, tags, which are currently
attached to packets do not work very well when you start slicing the
packets and re-aggregating them (which is bound to happen when you use a
stream-based protocol). A followup discussion on irc with joe and raj
showed that a possible solution would be to make Packet::AddTag tag
bytes within a packet, rather than the packet itself. The hard part, is,
of course, tracking which bytes are tagged by which tag in a packet as
it is sliced and reassembled. What is _really_ hard is doing all of this
in an efficient way which does not require large amounts of memory.

To make progress on this issue for the june release, I have implemented
a pretty inefficient version of that in
http://code.nsnam.org/mathieu/ns-3-tags

the code is located in src/common/tag.h, src/common/tag-list.h,
src/common/tag-buffer.h, and, src/common-packet.h.

We now have Packet::AddTag which has the same signature it always had.
Packet::FindFirstMatchingTag replaces Packet::PeekTag (with the same
signature). There is also a very-fancy Packet::GetTagIterator method
which should allow a user to iterate through every tag attached to every
byte of a packet. This implementation has a couple of loose ends but it
seems to work on the relatively simple set of testcases I have thrown at
it in src/common/packet.cc (see bottom of file). What is missing:

  - Packet::RemoveTag. I am not sure how this method should be
translated. Maybe "void Packet::RemoveFirstMatchingTag (const Tag &tag)"
would be enough.

  - Packet::PrintTags is not implemented but this is really trivial to
do.

  - the implementation needs to be aligned with the COW semantics we use
for the Buffer and PacketMetadata classes. The code I just wrote does a
very simple Copy whenever it is needed. It needs to be a bit smarter.


I will tackle all 3 issues when I come back on may the 4th. In the
meantime, feel free to reply to this email with API comments or to use
this tree if you find it useful: I won't reply for the next 10 days
though.

best regards,
Mathieu