[Ns-bugs] [Bug 231] IP Address Confusion in Echo Applications

[bugzilla-daemon@nsnam-www.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=231


tomh at tomh.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tomh at tomh.org




------- Comment #4 from tomh at tomh.org  2008-06-25 00:50 -------
(In reply to comment #3)
> > The only reasonable option seems to be to call Packet::RemoveAllTags in the
> > server before sending back the packet to the client. Patch attached.
> 
> Hmmm.  This doesn't sound like a very good solution to me.  The root of the
> problem is in the socket code, not the echo server code.  I don't think it's a
> good plan to have the echo server just strip off all of the tags because the
> socket code doesn't deal with the tags it adds properly.
> 
> I would be very surprised to find that some random application just decided to
> delete all the tags I very carefully added in my simulation.
> 
> *The* problem is that (I'll use UDP) ForwardUp creates and attaches a
> SocketAddressTag to a packet and queues the packet.  RecvFrom dequeues the
> packet and does a FindFirstMatchingTag but leaves the tag there.  If the packet
> is forwarded to another socket, the now useless tag is left there and results
> in the next ForwardUp adding a duplicate tag and RecvFrom getting the wrong
> one.
> 
> No, I don't think the UDP echo server application is the right place to fix
> this.  I think that ForwardUp needs to error out if it finds a SocketAddressTag
> in a packet.  I think it needs to add one.  I think RecvFrom needs to find that
> single tag, use it to get the address and then remove it. 

I agree that if the semantics of a particular tag are that it is consumed by
another layer, it should be OK to remove it in that different layer.

However, this may be prone to some error because someone may write a new
application and forget to remove the tag.  Or, maybe someone doesn't use
RecvFrom() but Recv() instead and is unaware of the presence of that tag.  So
maybe ForwardUp should just also remove that tag if it happens to already be
there, rather than error out.

> 
> This means adding the ability to remove a tag to a packet.  It seems to me that
> the simplest thing would be a RemoveFirstMatchingTag call.
> 

I would support this.  In addition, another use case is if people try to use
tags for hop-by-hop stuff, they will need the ability to remove tags in
transit.

However, I think it might also be a good idea to consider RemoveAllTags in the
application, in addition to trying to make the code clean up this particular
tag.  This is perhaps a policy decision we should discuss further (whether
Packets, when consumed by an application, are considered to be logically dead
and if one wants to reuse them to send back down the stack again, the default
behavior may be to flush all tags before doing that).  Because I think it is
debatable which will be more surprising-- that a recycled packet contains tags
from a previous communication or not.


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.