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