Re: [ns] Problems with multicast (BST/etc.)

[Abdullah M Jibaly <amj0589@gamma2.uta.edu>]

Sure, I'd be interested in your howto.

Thanks,
Abdullah Jibaly

On Tue, 8 May 2001, Aaron D Striegel wrote:

> Sorry to triple send but I fixed the problem.  The actual data header was 
> not in ns-packet.tcl so hence a write of the header field blew away what 
> was in the ip header.  So, problem solved at least for now.
> 
> On a related note, would anyone be interested in me posting a howto page on 
> the info that I found regarding adding a header field and working with 
> multicast.  As it stands now, I've basically ripped out most of the tcl 
> functionality and put it back into C++ with an almost entirely C++ based 
> replication scheme for encapsulation-based multicast.  If you are 
> interested, please let me know.
> 
> At 07:51 PM 5/8/2001 -0500, you wrote:
> >I managed to fix the classifier problem (removed a bit of unnecessary code 
> >making the dest address = the node, hence explaining the classifier 
> >error).  However, I am now experiencing a new, much more difficult error 
> >as the copy mechanism for the packet does not appear to work.
> >
> >if(pOutgoingLink != NULL)
> >{
> >   pOutgoingLink->recv(pPacket->copy());
> >}
> >
> >However, although my packet makes it to the next node appropriately, it 
> >has lost all semblance of a destination address or source address (always 
> >-1).  Plus, the original pPacket object appears to get corrupted as well 
> >due to this code.  This is the exact same code that I have for the control 
> >tree replication which works 100% correct.  In fact, I just cut and paste 
> >the code over to remove any changes that I made.  Anyone have any 
> >experience working with the copy() function of the Packet object?  This 
> >should work for all practical purposes as I've used this before and it 
> >uses roughly the same principle as the replicator objects for multicast.
> >
> >If anyone could contact me that has done similar work or actually wrote 
> >the multicast code for ns, that would be great.  Thanks
> >
> >Aaron
> >
> >At 05:57 PM 5/8/2001 -0500, you wrote:
> >>I'm having several difficulties with the multicast portion of the ns 
> >>code.  I am attempting to port the replication process over to C++ (which 
> >>I have done crudely once for a different protocol) such that the 
> >>replication process is based off of a header included in the C++ file 
> >>such that I can avoid stateful information in the node.
> >>
> >>I have this all working successfully for control packets so I know my 
> >>technique does work.  However, when I am trying to do this for the data 
> >>packets, I get an no-slot handler message.  This occurs only when the 
> >>packets are actually arrive at a node (i.e. it works for packets that are 
> >>produced at a given node).  This behavior is extremely weird as I would 
> >>expect the initial arrival at the node to cause a problem with a no-slot 
> >>classifier.
> >>
> >>So here are my questions and perhaps someone can enlighten me:
> >>
> >>- How does a packet actually make it to the multicast classifier, 
> >>specifically the control classifier and the data classifier?  I can get 
> >>the packet to the control classifier (no problem) and to the data 
> >>classifier (source node only) so what do I need to do to get it to my 
> >>custom multicast classifier object?  It does arrive at my classifier 
> >>object as a source so it appears to be some sort of linkage problem upon 
> >>arriving at an incoming interface.
> >>
> >>- Do I need to install another agent or put on a replicator that responds 
> >>to that group?  If so, how can I do that if I can't see the data packet 
> >>in the first place to do anything.  Any suggestions on how to debug 
> >>what/where things are going bad?
> >>
> >>- Finally, is there any way that someone who is working on the multicast 
> >>internals could contact me?  I fear this question is a bit more technical 
> >>than your average sort of questions for the users group.  Of course, I 
> >>would like to be proven wrong on this point but if someone could e-mail 
> >>me so I could go into more detail on this subject/help debug my problem, 
> >>that would be great.
> >>
> >>--------------------------------------------
> >>Aaron Striegel
> >>Ph.D. Candidate, Computer Engineering
> >>Iowa State University
> >>http://www.public.iastate.edu/~magico
> >
> 
> 
>