pre-review for the implementation of GPSR routing protocol, no tests yet

[Tommaso Pecorella, 2014-01-12 18:09:29]

First round of checks, just trying to build the module.

Beside the comments to the wscripts, the following things are missing:
1) tests in <module>/test
2) documentation in <module>/doc
3) examples should go in ns-3-dev/examples (and have explicative names).

The documentation should be done in ReStructured Text. To have a guideline try
making a new module with src/create-module.py, it will create all the
directories for you with example files as well.

Moreover, a general question (but probably it will be clear to me later on): the
"location-service" module is a generally useful module or specific to GPSR ?
If it's generally useful, then it will require separate documentation, examples,
tests and so on :\
If it's specific to GPSR, then it's better to include it in the GPSR module.

https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript
File src/gpsr/wscript (right):

https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript#newcode10
src/gpsr/wscript:10: module = bld.create_ns3_module('gpsr', ['location-service',
'internet', 'wifi', 'applications', 'mesh', 'point-to-point',
'virtual-net-device'])
Are 'wifi', 'applications', 'mesh', 'point-to-point', 'virtual-net-device' real
dependencies or are they just needed by examples ?

https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript#newcode19
src/gpsr/wscript:19: headers = bld.new_task_gen(features=['ns3header'])
    headers = bld(features='ns3header')

https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript#newcode30
src/gpsr/wscript:30: bld.add_subdirs('examples')
    if bld.env['ENABLE_EXAMPLES']:
        bld.recurse('examples')

https://codereview.appspot.com/5401042/diff/2077/src/location-service/wscript
File src/location-service/wscript (right):

https://codereview.appspot.com/5401042/diff/2077/src/location-service/wscript...
src/location-service/wscript:16: headers =
bld.new_task_gen(features=['ns3header'])
    headers = bld(features='ns3header')

[Konstantinos Katsaros, 2014-01-14 14:54:20]

Dear Tomasso,

A reply to the general comment you asked about the location-service module.
This module is useful for [most] position-based routing protocol. See it 
like ARP.
It will provide you with the answer to the question "where is the 
destination?" so that
you can run your protocol.

As far as I remember this implementation implements only a GOD service, 
which gets the information from the global knowledge of the simulator.
However, there is research on different architectures of location services. 
We had a discussion with Antonio during WNS3-12 where I also presented a 
position-based routing protocol and at that time I was using a GOD service 
but not 
as a distinct module.


On Sunday, January 12, 2014 6:09:30 PM UTC, Tommaso Pecorella wrote:
>
> First round of checks, just trying to build the module. 
>
> Beside the comments to the wscripts, the following things are missing: 
> 1) tests in <module>/test 
> 2) documentation in <module>/doc 
> 3) examples should go in ns-3-dev/examples (and have explicative names). 
>
> The documentation should be done in ReStructured Text. To have a 
> guideline try making a new module with src/create-module.py, it will 
> create all the directories for you with example files as well. 
>
> Moreover, a general question (but probably it will be clear to me later 
> on): the "location-service" module is a generally useful module or 
> specific to GPSR ? 
> If it's generally useful, then it will require separate documentation, 
> examples, tests and so on :\ 
> If it's specific to GPSR, then it's better to include it in the GPSR 
> module. 
>
>
> https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript 
> File src/gpsr/wscript (right): 
>
> https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript#newcode10 
>
>
src/gpsr/wscript:10<https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript#newcode10src/gpsr/wscript:10>:

> module = bld.create_ns3_module('gpsr', 
> ['location-service', 'internet', 'wifi', 'applications', 'mesh', 
> 'point-to-point', 'virtual-net-device']) 
> Are 'wifi', 'applications', 'mesh', 'point-to-point', 
> 'virtual-net-device' real dependencies or are they just needed by 
> examples ? 
>
> https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript#newcode19 
>
>
src/gpsr/wscript:19<https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript#newcode19src/gpsr/wscript:19>:

> headers = bld.new_task_gen(features=['ns3header']) 
>      headers = bld(features='ns3header') 
>
> https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript#newcode30 
>
>
src/gpsr/wscript:30<https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript#newcode30src/gpsr/wscript:30>:

> bld.add_subdirs('examples') 
>      if bld.env['ENABLE_EXAMPLES']: 
>          bld.recurse('examples') 
>
>
> https://codereview.appspot.com/5401042/diff/2077/src/location-service/wscript

> File src/location-service/wscript (right): 
>
>
https://codereview.appspot.com/5401042/diff/2077/src/location-service/wscript...

>
>
src/location-service/wscript:16<https://codereview.appspot.com/5401042/diff/2077/src/location-service/wscript#newcode16src/location-service/wscript:16>:

> headers = 
> bld.new_task_gen(features=['ns3header']) 
>      headers = bld(features='ns3header') 
>
> https://codereview.appspot.com/5401042/ 
>

[Tommaso Pecorella, 2014-01-14 16:23:53]

Hi Kostantinos,

I guessed it, but I wanted to be sure :)

My point is: GPSR needs a location service, and that's ok. However we have two
alternatives:
1) we do it *inside* GPSR and we state that, once a general Location Service
will be added, we will use it, or
2) we do a proper Location Service.

Right now the GPSR module is two modules for real, and this can hinder its
review and merge. And trust me when I say: the problem could be exactly the
location service.

The most streamlined approach would be:
1) define a Location Service goal, requirement and so on (based on existing
experiences like GPSR)
2) design and implement a Location Service
3) merge it
4) go on with GPSR

However the actual LocService module is really a skeleton with the bare minimum
functionalities. So, the *real* question is: shall we reduce it even more or
expand it ?

Cheers,

T.

PS: I'm not an expert of location services, so I don't know how one could do a
"non-God" Location service. Proximity ? GPS ? Central Database (with delayed
updates) ? Distributed ? Centalized ? What protocols are used to find the
target's position ? 
I think those things have to be foreseen in order to devise a general Location
Service interface, especially considering the delay between a request and a
reply (i.e., Q: "where the **** it is this thing" - R: "I guess it's in <x,y,z>
with an error margin of <Dx, Dy, Dz>").

See ? The error margin might be useful, so it's something to think about in the
interface...


Cheers,

T.


On 14/gen/2014, at 15:54, Kostantinos Katsaros <dinos.katsaros@gmail.com>
wrote:

> Dear Tomasso,
> 
> A reply to the general comment you asked about the location-service module.
> This module is useful for [most] position-based routing protocol. See it like
ARP.
> It will provide you with the answer to the question "where is the
destination?" so that
> you can run your protocol.
> 
> As far as I remember this implementation implements only a GOD service, 
> which gets the information from the global knowledge of the simulator.
> However, there is research on different architectures of location services. 
> We had a discussion with Antonio during WNS3-12 where I also presented a 
> position-based routing protocol and at that time I was using a GOD service but
not 
> as a distinct module.
> 
> 
> On Sunday, January 12, 2014 6:09:30 PM UTC, Tommaso Pecorella wrote:
> First round of checks, just trying to build the module. 
> 
> Beside the comments to the wscripts, the following things are missing: 
> 1) tests in <module>/test 
> 2) documentation in <module>/doc 
> 3) examples should go in ns-3-dev/examples (and have explicative names). 
> 
> The documentation should be done in ReStructured Text. To have a 
> guideline try making a new module with src/create-module.py, it will 
> create all the directories for you with example files as well. 
> 
> Moreover, a general question (but probably it will be clear to me later 
> on): the "location-service" module is a generally useful module or 
> specific to GPSR ? 
> If it's generally useful, then it will require separate documentation, 
> examples, tests and so on :\ 
> If it's specific to GPSR, then it's better to include it in the GPSR 
> module. 
> 
> 
> https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript 
> File src/gpsr/wscript (right): 
> 
> https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript#newcode10 
> src/gpsr/wscript:10: module = bld.create_ns3_module('gpsr', 
> ['location-service', 'internet', 'wifi', 'applications', 'mesh', 
> 'point-to-point', 'virtual-net-device']) 
> Are 'wifi', 'applications', 'mesh', 'point-to-point', 
> 'virtual-net-device' real dependencies or are they just needed by 
> examples ? 
> 
> https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript#newcode19 
> src/gpsr/wscript:19: headers = bld.new_task_gen(features=['ns3header']) 
>      headers = bld(features='ns3header') 
> 
> https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript#newcode30 
> src/gpsr/wscript:30: bld.add_subdirs('examples') 
>      if bld.env['ENABLE_EXAMPLES']: 
>          bld.recurse('examples') 
> 
> https://codereview.appspot.com/5401042/diff/2077/src/location-service/wscript

> File src/location-service/wscript (right): 
> 
>
https://codereview.appspot.com/5401042/diff/2077/src/location-service/wscript...

> src/location-service/wscript:16: headers = 
> bld.new_task_gen(features=['ns3header']) 
>      headers = bld(features='ns3header') 
> 
> https://codereview.appspot.com/5401042/ 

--------------------------------------------------------------

The nice thing about standards is that there are so many to choose from.
And if you really don't like all the standards you just have to wait another
year until the one arises you are looking for.
-- A. Tanenbaum, "Introduction to Computer Networks"

--------------------------------------------------------------

Tommaso Pecorella - Ph.D.

Assistant professor
Dpt. Ingegneria dell'Informazione
Università di Firenze

CNIT - Università di Firenze Unit

via di S. Marta 3
50139, Firenze
ITALY

email: tommaso.pecorella@unifi.it
       tommaso.pecorella@cnit.it

phone : +39-055-4796412
mobile: +39-320-4379803
fax   : +39-055-494569

[António Fonseca, 2014-01-14 16:54:17]

Hi,

An Location service prototype inmplementation is also done in:
https://code.google.com/p/ns3-rls/
This was a colleague of mine and me that done some time after GPSR for his
thesis which is one simple reactive protocol (not very efficient). But that
code is currently a bit nasty.

There are already quite some papers with ideas for location services.

About where it stays, the location service is external to GPSR, it's
something that all (or almost all) geographic routing protocols use, so it
should be an external module.

Best Regards


2014/1/14 Tommaso Pecorella <tommypec@gmail.com>

> Hi Kostantinos,
>
> I guessed it, but I wanted to be sure :)
>
> My point is: GPSR needs a location service, and that's ok. However we have
> two alternatives:
> 1) we do it *inside* GPSR and we state that, once a general Location
> Service will be added, we will use it, or
> 2) we do a proper Location Service.
>
> Right now the GPSR module is two modules for real, and this can hinder its
> review and merge. And trust me when I say: the problem could be exactly the
> location service.
>
> The most streamlined approach would be:
> 1) define a Location Service goal, requirement and so on (based on
> existing experiences like GPSR)
> 2) design and implement a Location Service
> 3) merge it
> 4) go on with GPSR
>
> However the actual LocService module is really a skeleton with the bare
> minimum functionalities. So, the *real* question is: shall we reduce it
> even more or expand it ?
>
> Cheers,
>
> T.
>
> PS: I'm not an expert of location services, so I don't know how one could
> do a "non-God" Location service. Proximity ? GPS ? Central Database (with
> delayed updates) ? Distributed ? Centalized ? What protocols are used to
> find the target's position ?
> I think those things have to be foreseen in order to devise a general
> Location Service interface, especially considering the delay between a
> request and a reply (i.e., Q: "where the **** it is this thing" - R: "I
> guess it's in <x,y,z> with an error margin of <Dx, Dy, Dz>").
>
> See ? The error margin might be useful, so it's something to think about
> in the interface...
>
>
> Cheers,
>
> T.
>
>
> On 14/gen/2014, at 15:54, Kostantinos Katsaros <dinos.katsaros@gmail.com>
> wrote:
>
> Dear Tomasso,
>
> A reply to the general comment you asked about the location-service module.
> This module is useful for [most] position-based routing protocol. See it
> like ARP.
> It will provide you with the answer to the question "where is the
> destination?" so that
> you can run your protocol.
>
> As far as I remember this implementation implements only a GOD service,
> which gets the information from the global knowledge of the simulator.
> However, there is research on different architectures of location
> services.
> We had a discussion with Antonio during WNS3-12 where I also presented a
> position-based routing protocol and at that time I was using a GOD service
> but not
> as a distinct module.
>
>
> On Sunday, January 12, 2014 6:09:30 PM UTC, Tommaso Pecorella wrote:
>>
>> First round of checks, just trying to build the module.
>>
>> Beside the comments to the wscripts, the following things are missing:
>> 1) tests in <module>/test
>> 2) documentation in <module>/doc
>> 3) examples should go in ns-3-dev/examples (and have explicative names).
>>
>> The documentation should be done in ReStructured Text. To have a
>> guideline try making a new module with src/create-module.py, it will
>> create all the directories for you with example files as well.
>>
>> Moreover, a general question (but probably it will be clear to me later
>> on): the "location-service" module is a generally useful module or
>> specific to GPSR ?
>> If it's generally useful, then it will require separate documentation,
>> examples, tests and so on :\
>> If it's specific to GPSR, then it's better to include it in the GPSR
>> module.
>>
>>
>> https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript
>> File src/gpsr/wscript (right):
>>
>> https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript#newcode10
>>
>>
src/gpsr/wscript:10<https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript#newcode10src/gpsr/wscript:10>:
>> module = bld.create_ns3_module('gpsr',
>> ['location-service', 'internet', 'wifi', 'applications', 'mesh',
>> 'point-to-point', 'virtual-net-device'])
>> Are 'wifi', 'applications', 'mesh', 'point-to-point',
>> 'virtual-net-device' real dependencies or are they just needed by
>> examples ?
>>
>> https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript#newcode19
>>
>>
src/gpsr/wscript:19<https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript#newcode19src/gpsr/wscript:19>:
>> headers = bld.new_task_gen(features=['ns3header'])
>>      headers = bld(features='ns3header')
>>
>> https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript#newcode30
>>
>>
src/gpsr/wscript:30<https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript#newcode30src/gpsr/wscript:30>:
>> bld.add_subdirs('examples')
>>      if bld.env['ENABLE_EXAMPLES']:
>>          bld.recurse('examples')
>>
>> https://codereview.appspot.com/5401042/diff/2077/src/
>> location-service/wscript
>> File src/location-service/wscript (right):
>>
>> https://codereview.appspot.com/5401042/diff/2077/src/
>> location-service/wscript#newcode16
>>
src/location-service/wscript:16<https://codereview.appspot.com/5401042/diff/2077/src/location-service/wscript#newcode16src/location-service/wscript:16>:
>> headers =
>> bld.new_task_gen(features=['ns3header'])
>>      headers = bld(features='ns3header')
>>
>> https://codereview.appspot.com/5401042/
>>
>
>       --------------------------------------------------------------
>
>
> The nice thing about standards is that there are so many to choose from.
> And if you really don't like all the standards you just have to wait
> another year until the one arises you are looking for.
>
> -- A. Tanenbaum, "Introduction to Computer Networks"
>
>
> --------------------------------------------------------------
>
>
> Tommaso Pecorella - Ph.D.
>
>
> Assistant professor
>
> Dpt. Ingegneria dell'Informazione
>
> Università di Firenze
>
>
> CNIT - Università di Firenze Unit
>
>
> via di S. Marta 3
>
> 50139, Firenze
>
> ITALY
>
>
> email: tommaso.pecorella@unifi.it
>
>        tommaso.pecorella@cnit.it
>
>
> phone : +39-055-4796412
> mobile: +39-320-4379803
> fax   : +39-055-494569
>
>
>
>
>
>
>

[Konstantinos Katsaros, 2014-01-14 16:58:04]

Hi Tomasso,

On Tuesday, January 14, 2014 4:23:49 PM UTC, Tommaso Pecorella wrote:
>
> Hi Kostantinos,
>
> I guessed it, but I wanted to be sure :)
>
> My point is: GPSR needs a location service, and that's ok. However we have 
> two alternatives:
> 1) we do it *inside* GPSR and we state that, once a general Location 
> Service will be added, we will use it, or
> 2) we do a proper Location Service.
>
>
I would go for #2. Have an abstract LocService that would have pure-virtual 
functions such as Update/Request/Reply, like the skeleton class and 
implement different types. 
GOD would always know the position, 100% accuracy because it is the 
simulator. Such LocServices have been used for evaluation of geographic 
routing protocols.

Leave it open for research and implementation of non-GOD LocServices.

I have developed such a non-GOD, centralized LocService, based on the basic 
client/service applications. 
I have a server application that keeps a local database of the position of 
nodes. Clients send Updates to the server, so the DB is updated. Also 
Requests in the form of "where is XXX". And the replies they get are "XXX 
was at x,y,z travelling with velocity x,y,z at [timestamp_of_update]". 
The connection between client/server has been tested in LTE and WiFi 
scenarios [1].


Right now the GPSR module is two modules for real, and this can hinder its 
> review and merge. And trust me when I say: the problem could be exactly the 
> location service.
>  
>
The most streamlined approach would be:
> 1) define a Location Service goal, requirement and so on (based on 
> existing experiences like GPSR)
> 2) design and implement a Location Service
> 3) merge it
> 4) go on with GPSR
>
> However the actual LocService module is really a skeleton with the bare 
> minimum functionalities. So, the *real* question is: shall we reduce it 
> even more or expand it ?
>
>
I would say keep a bare minimum interface with some option fields. For 
example you have the three methods (could be interfaces) of 
Update/Request/Reply and you can build on top of that.

 

> Cheers,
>
> T.
>
> PS: I'm not an expert of location services, so I don't know how one could 
> do a "non-God" Location service. Proximity ? GPS ? Central Database (with 
> delayed updates) ? Distributed ? Centalized ? What protocols are used to 
> find the target's position ? 
> I think those things have to be foreseen in order to devise a general 
> Location Service interface, especially considering the delay between a 
> request and a reply (i.e., Q: "where the **** it is this thing" - R: "I 
> guess it's in <x,y,z> with an error margin of <Dx, Dy, Dz>").
>
> See ? The error margin might be useful, so it's something to think about 
> in the interface...
>
>
I am not an expert also (should have been since I am doing research on 
that!). It depends on what information your routing protocol requires. For 
example GPSR only needs the position (no margin errors). Others, like 
GyTAR, VADD, my own CLWPR will ask for more information like velocity in 
order to make predictions of future position. That's why I mention above 
have the bare minimum of Reply() and the reply would carry a message/struct 
with different information (position, error margins, velocity etc).
 

>
> Cheers,
>
> T.
>
>
[1] http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6649289
 

>
> On 14/gen/2014, at 15:54, Kostantinos Katsaros
<dinos.k...@gmail.com<javascript:>> 
> wrote:
>
> Dear Tomasso,
>
> A reply to the general comment you asked about the location-service module.
> This module is useful for [most] position-based routing protocol. See it 
> like ARP.
> It will provide you with the answer to the question "where is the 
> destination?" so that
> you can run your protocol.
>
> As far as I remember this implementation implements only a GOD service, 
> which gets the information from the global knowledge of the simulator.
> However, there is research on different architectures of location 
> services. 
> We had a discussion with Antonio during WNS3-12 where I also presented a 
> position-based routing protocol and at that time I was using a GOD service 
> but not 
> as a distinct module.
>
>
> On Sunday, January 12, 2014 6:09:30 PM UTC, Tommaso Pecorella wrote:
>>
>> First round of checks, just trying to build the module. 
>>
>> Beside the comments to the wscripts, the following things are missing: 
>> 1) tests in <module>/test 
>> 2) documentation in <module>/doc 
>> 3) examples should go in ns-3-dev/examples (and have explicative names). 
>>
>> The documentation should be done in ReStructured Text. To have a 
>> guideline try making a new module with src/create-module.py, it will 
>> create all the directories for you with example files as well. 
>>
>> Moreover, a general question (but probably it will be clear to me later 
>> on): the "location-service" module is a generally useful module or 
>> specific to GPSR ? 
>> If it's generally useful, then it will require separate documentation, 
>> examples, tests and so on :\ 
>> If it's specific to GPSR, then it's better to include it in the GPSR 
>> module. 
>>
>>
>> https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript 
>> File src/gpsr/wscript (right): 
>>
>> https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript#newcode10 
>>
>>
src/gpsr/wscript:10<https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript#newcode10src/gpsr/wscript:10>:

>> module = bld.create_ns3_module('gpsr', 
>> ['location-service', 'internet', 'wifi', 'applications', 'mesh', 
>> 'point-to-point', 'virtual-net-device']) 
>> Are 'wifi', 'applications', 'mesh', 'point-to-point', 
>> 'virtual-net-device' real dependencies or are they just needed by 
>> examples ? 
>>
>> https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript#newcode19 
>>
>>
src/gpsr/wscript:19<https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript#newcode19src/gpsr/wscript:19>:

>> headers = bld.new_task_gen(features=['ns3header']) 
>>      headers = bld(features='ns3header') 
>>
>> https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript#newcode30 
>>
>>
src/gpsr/wscript:30<https://codereview.appspot.com/5401042/diff/2077/src/gpsr/wscript#newcode30src/gpsr/wscript:30>:

>> bld.add_subdirs('examples') 
>>      if bld.env['ENABLE_EXAMPLES']: 
>>          bld.recurse('examples') 
>>
>>
>> https://codereview.appspot.com/5401042/diff/2077/src/location-service/wscript

>> File src/location-service/wscript (right): 
>>
>>
https://codereview.appspot.com/5401042/diff/2077/src/location-service/wscript...

>>
>>
src/location-service/wscript:16<https://codereview.appspot.com/5401042/diff/2077/src/location-service/wscript#newcode16src/location-service/wscript:16>:

>> headers = 
>> bld.new_task_gen(features=['ns3header']) 
>>      headers = bld(features='ns3header') 
>>
>> https://codereview.appspot.com/5401042/ 
>>
>
> --------------------------------------------------------------
>
>
> The nice thing about standards is that there are so many to choose from.
> And if you really don't like all the standards you just have to wait 
> another year until the one arises you are looking for.
>
> -- A. Tanenbaum, "Introduction to Computer Networks"
>
>
> --------------------------------------------------------------
>
>
> Tommaso Pecorella - Ph.D.
>
>
> Assistant professor
>
> Dpt. Ingegneria dell'Informazione
>
> Università di Firenze
>
>
> CNIT - Università di Firenze Unit
>
>
> via di S. Marta 3
>
> 50139, Firenze
>
> ITALY
>
>
> email: tommaso....@unifi.it <javascript:>
>
>        tommaso....@cnit.it <javascript:>
>
>
> phone : +39-055-4796412
> mobile: +39-320-4379803
> fax   : +39-055-494569
>
>
>
>
>
>  
>

[nou.mail, 2015-01-08 10:17:47]

Hi everyone

I'm using GPSR on nodes having each 2 interfaces
I'm having the following log messages: 

[node 1] Destination: 10.0.0.255
[node 1] Exist route to 10.0.0.255 from interface 10.0.0.2

 which I guess reflects tht gpsr found a route for the packet however no packets
are received and my packet loss ratio is 100% :-O

I noticed  the following block in the file gpsr.cc:
// FIXME: Does not work for multiple interfaces
          route->SetOutputDevice (m_ipv4->GetNetDevice (1));
          route->SetDestination (header.GetDestination ());
          NS_ASSERT (route != 0);
          NS_LOG_DEBUG ("Exist route to " << route->GetDestination () << " from
interface " << route->GetOutputDevice ());

Does it mean that the cause of packet loss is that my nodes have multiple
interfaces ?


Pleaaase Help
Thx

[nou.mail, 2015-01-08 11:48:13]

Hello again

Is there any problem in using GPSR over a wired network? Actually I'm receiving
packets with other routing protocls but no reception with GPSR although he seems
to find the route to the destination


Best regards