Packet Generator

Are you coding the whole simulation environment yourself or are you also using simulation tools like Simulink or VisSim ?

this bit i am doing it myself. maybe i will be aggregating it more and more and more in the time to come. but i am using OPNET to simulate the actual model.

we all thought, IPv6 was created after careful analysis of what went wrong with IPv4. Its true, i do agree to a great extent. But one look through RFC 2460, and i came across something which did not conform to what was dished out in the definition of IPv6 itself. In a section in RFC 2460, it says, if a node finds a packet received is too large to be forwarded to a outgoing link, it will be discarded with an ICMPv6 message being generated and sent to the source.
Careful reading of section 5 of RFC 2460 will reveal that only source gets to fragment packets after careful consideration of PMTU of the entire path between source and destination. So no packet can be discarded in the middle of a routing path, as all of them have already met the size criteria. Unless we are talking about a packet which has the routing extension header enabled with some intermediate node. In such a case, the destination keeps on changing, and hence PMTU consideration might not be met at all. What happens then? What is the effective PMTU, is it calculated between the source and the final destination of the routed path, or is it between the source and the first node in the address list maintained in the routing extension header? It should be as a rule, the final destination, but its still inconclusive in the explanation provided in the RFC.
Its worth a thought!!!

this is an excerpt from my notes on the simulation:
As the simulation has to show four different hosts randomly generating packets for random destinations, along with a switch in the middle which is constantly routing data, there is possibility of a deadlock situation.

Let us see how the simulation is supposed to work. The first cycle of the simulation lets the hosts write packets for other destinations, into their outgoing buffers. Once all the hosts have written into their respective outgoing buffers, they all go into a wait state.

Now the switch thread comes to life and checks each and every outgoing buffer for every host. After reading a particular buffer e.g. outgoing buffer for host 1, it reads the destination address of the packet and writes the packet to the incoming buffer of the destination host.

This is repeated for all hosts. Then the switch thread goes into a wait state. This cycle is repeated ‘n’ number of times till the end of the simulation. Now the situation of deadlock can arise as there are 8 buffers in question, and each host thread needs to wait for an entry in each of these buffers.

As one hosts reads or writes into its buffers, it sets the values of lock variable (the variable which governs the ownership of a buffer at that specific time).

Once action on a buffer is finished, the host or the switch releases the lock, and all other waiting threads (it can be another switch thread or any of the other three host threads) tries to gain control of that buffer. By design, unique access rights on any incoming buffer or outgoing buffer is only between the switch and that particular thread.

Other hosts do not have rights over buffers that don’t belong to them. If a host does not see any new packet in its incoming buffer it goes into a wait state. It does not try to write anything into its outgoing buffer. So this particular thread will only continue operation if something is written into its incoming buffer by the switch. Problem lies in the fact that destination addresses are chosen on a random basis.

It might be that this particular host might not come up as a destination for quite some time. So it does not write anything into its outgoing buffer and goes into a wait state. With one host perpetually in wait state, it might so happen that one more thread enters into a similar wait state, and other host threads may follow suite. This means that all hosts are waiting for an incoming packet, and none are sending.

The switch now itself goes into a wait state as it tries to read the outgoing buffer of any host. So the situation achieves a deadlock as all nodes are waiting for a response, and none are generating any. There are as of now two ways of avoiding this problem. One of them is to put all the read write threads of all the 4 hosts into a single thread, and another thread being used solely for the switch.

The switch thread seeks out every outgoing buffer for each host, and writes the packets into the incoming buffers of the destination hosts accordingly. This cycle carries on till the simulation ends. But here in this case, the sequence defeats the purpose of making the simulation based on real – life situation. In real life, the switch does not wait for any hosts, the hosts does not wait for the switch either. Buffer management is the basis of concurrent processing on both host and switch end. But this arrangement avoids the deadlock.

Another arrangement that can be done is to divide the read and write processes into separate threads for each hosts. So each individual read or write thread can wait for its respective incoming or outgoing buffers respectively, for a response.

ladies and gentlemen, it gives me considerable amount of pleasure to declare the fact that.........OH CUT THE CRAP!!! MY GOD IT WORKS......IT WORKS...ITS ALIVE.....ITSS...AAA.LLLL..IIIIVVVEEE!!!
months of pain into designing the stuff, and now finally i have managed to simulate a router which works on the new IP that i have designed. like i said earlier, i was working on the principle of developing threads to simulate the different functions of the router, and various hosts, connected to the router. the network structure i worked on was four different hosts, which were all connected to a single NEW IP (designed by me!!!) router, and they were all communicating with each other. the job of the host were to generate random packets of the specific structure which conformed with the NEW IP standard, and pass them on to the router. the router was to parse the packet, check it for errors, check the destination address, check for other factors like priority, fragmentation, etc, and then pass it on to the corresponding host using the correct outgoing channel. the host then receives the packet and passes it on to the upper layer. obviously i have not simulated the passing onto the upper layer scenario, all i have done it once it receives a packet from the router, it checks the destination address, and the source address, and increments a certain value against packets received from each individual host. this way i can keep count of the number of packets generated from a host going for another particular host. the router either way keeps counts of all packets incoming and outgoing. so i can monitor traffic as well!!!
well gentlemen, i know my project supervisor will be ecstatic hearing this, i have just make a phone call to my university, and i have a demonstration on monday i.e. 13/03/2006.
till then.i will play around with it for a while,
and by the way, the router is working at a decent pace of 19 packets per seconds, which i think is not bad at all!!!

Congratulations Arani. Hope the demo goes OK.