NFD

makes location information available to other parts of the system

What's the use case of having location information in the forwarder?
Why does it belong in the forwarder, rather than an application?

Why not run the gpsd client in a separate program?
To influence forwarding decisions, that program can update RIB/FIB in the forwarder.

Junxiao Shi wrote in #note-1:

makes location information available to other parts of the system

What's the use case of having location information in the forwarder?
Why does it belong in the forwarder, rather than an application?

Why not run the gpsd client in a separate program?
To influence forwarding decisions, that program can update RIB/FIB in the forwarder.

The CCLF implementation can be found here: CLF_NFD(https://github.com/alvyC/CLF_NFD), specifically in the forwarding strategy clf-vanet-strategy.hpp(https://github.com/alvyC/CLF_NFD/blob/master/daemon/fw/clf-vanet-strategy.hpp). According to the original design, I need to update its LinkService to attach GPS information to the NDNLPv2 header of Interest and Data packets.

Please expand the issue description (or create an overall encompassing issue and make this a sub-task), to explain the entirety of the design.

GPSManager works as a gpsd client and obtains latitude, longitude, altitude, and optionally horizontal movement direction, speed, and vertical speed from local gpsd. It has two main classes: GPSReader, which reads raw GPS data from local gpsd, and GPSManager, which manages the GPSReader and makes location information available to other parts of the system.

The code achieves its purpose through a multi-threaded approach. The GPSReader runs in a separate thread that continuously polls gpsd for new data. When valid GPS data is received, it updates the current location information. The GPSManager class uses the Singleton pattern (getInstance()) to ensure only one instance manages the GPS functionality throughout the system.

GPSManager is designed to integrate CCLF[1] into the latest NFD, as CCLF needs to update its LinkService to attach GPS information to the NDNLPv2 header of Interest and Data packets. The CCLF implementation can be found here: CLF_NFD(https://github.com/alvyC/CLF_NFD), specifically in the forwarding strategy clf-vanet-strategy.hpp(https://github.com/alvyC/CLF_NFD/blob/master/daemon/fw/clf-vanet-strategy.hpp). The security issues will be addressed in future versions.

GPSManager and related files will only be compiled when ./waf configure --with-gps is specified.

[1] Chowdhury, Muktadir, Junaid Ahmed Khan, and Lan Wang. "Leveraging content connectivity and location awareness for adaptive forwarding in NDN-based mobile ad hoc networks." Proceedings of the 7th ACM Conference on Information-Centric Networking. 2020.

If your goal is CCLF, create an encompassing issue about CCLF, and then explain each of its dependencies: LP protocol update, location information acquisition, strategy, measurements table, etc.

The security issues will be addressed in future versions

NDN's focus in recent years is on security.
You should not rush on the implementation and instead complete the design work regarding security/privacy.

Junxiao Shi wrote in #note-5:

If your goal is CCLF, create an encompassing issue about CCLF, and then explain each of its dependencies: LP protocol update, location information acquisition, strategy, measurements table, etc.

The security issues will be addressed in future versions

NDN's focus in recent years is on security.
You should not rush on the implementation and instead complete the design work regarding security/privacy.

Yes, that's true. But our drone project needs CCLF for MANET forwarding and Dr.Lan wants to to implement CCLF first and then make some improvements later.

Mainline has to be good quality code, not half baked designs.
You can continue working on your fork, and submit to mainline when it's ready.

Junxiao Shi wrote in #note-7:

Mainline has to be good quality code, not half baked designs.
You can continue working on your fork, and submit to mainline when it's ready.

Got it! But I think GPSManager can be merged before CCLF.

Tianxing Ma wrote in #note-8:

Got it! But I think GPSManager can be merged before CCLF.

Not gonna happen until you have a mostly complete design.

Last time I tried similar, it's rejected, even for designs that are already approved.
https://redmine.named-data.net/issues/5277#note-3