Thanks Johannes, this seems to work.
One extra optimization I have a question about:
I added an entry to the metabundle that gets updated based on the list that is maintained in the extension block of the bundle. This way I only have to access the storage when a change is actually necessary.
My concern is regarding the call "setKnown(meta)" in BaseRouter.cpp. I assume that I have to update the list of metabundles, but I wasn't sure if calling this again was okay, since the bundleId would be the same as before.
I traced that call down to: "MemoryBundleSet::add" and the "bundle.addTo(_bf)" call seems like it was cause duplication.
Should I not be worried about this, or is there a better way to update the list of metabundles at the base router?
Thanks again, Tomasz
On Thu, May 8, 2014 at 4:12 AM, Johannes Morgenroth < morgenroth@ibr.cs.tu-bs.de> wrote:
Am 08.05.2014 10:47, schrieb Tomasz Kalbarczyk:
This process will likely not happen very frequently, so I'm hoping it won't be too inefficient to periodically pull specific bundles from storage and update them.
Would the high level flow be:
getStorage.get() // modify bundle // delete bundle from storage getStorage.store()
That is correct. More detailed it looks like this:
BundleID id = ...; Bundle b = getStorage().get(id);
// modify the bundle ...
// remove old and store new bundle getStorage().remove(b); getStorage().store(b);
Be aware that there is a lot of parallelism in IBR-DTN and it might happen the another component will access the bundle your modifying between your remove and store calls. For that case, it would be a good way to add the ability to update() bundles to all storages. Pull-requests are welcome.
Should I be raising a "dtn::core::BundleGeneratedEvent" ?
As long as you do not modify the BundleID, this is not necessary as long the race-condition explained before does not happen.
Kind regards, Johannes Morgenroth