[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ns] Re: a packet inside a packet inside a packet



I have no clue as what's causing your segfaults, but instead of
storing the entire packet as data in another one, you could use pairs
of Encapsulator/Decapsulator agents.

  -Yuri

Sjoerd Janssen <[email protected]> writes:

> Hi there,
> 
> I'm really stuck and could use any input available.
> 
> I'll illustrate my problem with the following topology:
> 
> node1 ------ node2--------node3-------node4---------node5
> 
> Say there is a Tcp sender at node5 transmitting a Packet A.. Upon
> entering node4, Packet A is packed into the data field of a newly
> created Packet B. Packet B on its turn is also packed into the data
> field of another newly created Packet C. (don't ask me the reasons for
> this..). Packet C is transmitted to node3. There, Packet B is taken out
> and passed to node2 towards node1. At node1, Packet A is taken out (and
> delivered to the Tcp sink)..
> 
> My problem is that this used to work  but not anymore. Each Packet
> contains some of my own headers and as long as I used 'simple' types for
> my header fields, e.g:  int seqno_;  everything works fine. When I start
> using more complex types for my header fields  , e.g: A seqno_;  where A
> is a class, things go wrong...
> 
> If I transmit only one Packet from node5 to node1 there's no problem, a
> few more will also work. When I start transmitting many more Packets,
> e.g. > 5, things get screwed up (segfaults) and it seems that the data
> fields of the Packets get corrupted. My guess was that it had something
> to do with the way new Packets are allocated (i.e. using the free
> store)  but I can't seem to find a problem in there.
> 
> Does anybody know whether this can be caused by the fact that I've
> included complex types in my header fields, or is my 'packing' approach
> wrong in the sense that I have just been lucky that it didn't srew up
> before?
> 
> I need to use ns-2.1b5 (although I've seen ns-2.1b6 handles data
> somewhat differntly... would that be a solution...?)
> 
> Regards, Sjoerd.