Copyright reserved, referencing is required for use of any purpose
Download my implementation
tarball You can obtain its original implementation through
GPSR official link which is just for old version of ns2.

Notes:

Since this implementation is original based on ns2 version 2.26,
you need to be careful to deal with it when you use a later
vesion. Especially the ns-packet.tcl file, you need to do the
change by yourself. The one in my tarball may not be suitable
for you to use.

This implementation consists of 2 parts exactly the same as
proposed by the
original GPSR paper, and is a little bit different from the orginial
ns2 implementation (see through the link above).

This implementation is a pure Stateless implementation,
where the routing decision of each packet on any node is
made purely only on the local information (one-hop
neighborhood)

Both GG and RNG planarization methods are
provided by this implementation.

Before your re-make the ns2 after you put all my files in the correct directory, DO NOT forget to touch the packet.cc in ns2/common directory. (It is just a common NS2 using problem, not about my code.

If you have any question for this code, please
Do NOT email me. I graduated. You are on your own.

The shortest path routing in sensor networks is nearly the same as
DYMO routing proposed recently (around 2000) by IEEE as a new routing
standards (for MANET or meshNet). Although we use hop-count here, it
is easily to adapt other features of link quality as the path choosing
factor.

It may be error of ns2 (although, this thing is specified in the NS2
manual as on purpose behavior, but I think it is an error), since
if a packet initializes an ARP, it would be held in the Arp Table
before the destination address is resolved by ARP
but if another packet arrives and initializes another ARP for the same
destination, the previous packet would be dropped which must be a
mistake apparently.
See ns/mac/arp.cc in function ARPTable::arpresolve();
If you face some problems like packet dropped due to ARP, you may fix it

Usually, for one protocol
implementation, we need several timers. According to NS2's
implementation, for each timer calling different firing function, one
more class need to be declared and defined, which is boring and
bothering.
In fact, we can use the pointer to function to same time
and coding (How to do in with C++ template, I am not sure.). As
below:

Suppose you have one agent as TestAgent, and many firing
functions, you can define a pointer to any firing function as

typedef void(TestAgent::*firefunction)(void);

Then, you can create a general (generic) Timer class for all
timers, as

Ususally, when we create a timer, we need to define the
expire function to call specific firing function. Now we just
need it to call the Generic firing funtion pointer, as

void TestTimer::expire(Event *){
(a_->*firing_)();
}

Finally, when we need a specific timer calling a specific firing
funtion, other than what we ususally do as in NS2, we now just need to
declare a new timer as an instance of the Generic Timer, and
initialize it in TestAgent's constructor, as

The implementation of the Packet data structure of NS2 does not math
the realities. The packet in ns2 simulation keeps all packet headers
for any protocols implemented in NS2. For example, a DSR routing packet
may keep DSDV, AODV, or even a PING application header. For this
reason, till today, a packet used in ns2 simulation, would have a
header size around 40~64KB. And
NO packet would be deleted
to release the memory it holds until the end of the simulation.
So for a typical simulation with 100 nodes in ns2 around 1M packets exchanged
(of course, you may reuse the packets already being freed
through Packet::free(Packet*). To learn
the implementation of it, please check file common/packet{.h,.cc}
), you may hold 10% of it, 100K packets, and you may use a memory
at least 100K*64KB -> 6.4GB, which definitely
would crash your computer (even it is a super server).
So How you can do it? And how you can run a simulation like 500 nodes there?
You have 2 ways to do:

Suggested by ns2 manual, putting the below codes in your tcl script

remove-all-packet-headers
add-packet-header DSR ARP LL MAC CBR IP

to simulation a CBR application on UDP with DSR as routing protocol in a
wireless ad hoc network (OOPS!, UDP is not a header.
This method is effective, but it requires you to understand most packets header you need.

Another way is my way, changing the tcl library for the packet headers.
You may find the tcl library file for packet headers in
ns2/tcl/lib/ns-packet.tcl, you may find a procedure starting as
foreach prot {. You can comment out all the
headers you don't recognize, like all the Routing protocols
you dont know, all Routers, all Multicast,
all Transport Protocols except you need,
all application layer protocols,
some of the Wireless, some of the
Mobility, Ad-Hoc Networks, Sensor Nets
and all the Other.
Finally, you may just have all the below left

If you are creating your own packet header, put them here.
Typically, after this way, you may just have a packet size as 256B. So
even you have 500 nodes, and 10M packets need to be exchanged during the
simulation. You just need 256MB (if 10% packets held) for it, which is lower
than any common configuration of current PCs.

in the same way, as
The routing agent on node 9 received a GPSR broadcast (mac address 0xff, and ip address is -1, either of them means broadcast) routing packet
whose ID is 1 and size is 19 bytes, at time 0.010176954 second, from node 8 (both mac and ip addresses are 8), port 255 (routing agent).

There has been an endless debate of which is the REAL Editor -- vi, or emacs. In case you have any doubt, here is correct answer: Neither. (I have been using Emacs for several years, and still using it. My wife is using vi for a long time. So I understand this debate VERY well.)
If you want to speed up your programming, and you do not want to waste your time to remember Classes/APIs/Functions, do not want to waste time to open/close/reopen files, switch files backforth, And the most important thing: if you want to understand the code architecture better and quicker, you SHOULD use some good IDE.
In windows, there is NO doubt, the best IDE is Visual Studio (most of us do not really like Microsoft, but we have to admit, MS is the best software company on earth).
However, for ns2, the best IDE should be Eclipse -- both Windows and Linux

Installation Eclipse with CDT package.

Build ns2 through (Windows, you need cygwin. And either for Windows/Linux, don't forget to install the tcl library first).

Use the ns2 root path as the workspace path of your Eclipse to launch it.

"Project" --> "Build All". Now you should be able to use Eclipse the Code/Compile/Debug ns2.

The most important feature you would get there is the "intellisense". Although Vi/Emacs both provide "Code completion", they are No-comparable -- "intellisense" has much more good features than "Code completion".