Thanks for the reply Johannes.

I think I was a bit unclear during my previous explanation.

It is possible that the bundle will be stored at the host for an extended period of time. As the location changes, I'd like to periodically grab the bundle from storage, modify the block, and then place it back in storage.

Is there any mechanism to do this from within the routingextension (or elsewhere) ?

I suppose I could maintain a separate data structure that records all of the entries that I need to remove, and then remove them all at once when the bundle is forwarded (during serialization), but I was hoping to avoid having to maintain this data structure since it seems inefficient and error prone.

On Sat, Apr 26, 2014 at 2:33 AM, Johannes Morgenroth < morgenroth@ibr.cs.tu-bs.de> wrote:

Hello Thomasz,

did you mentioned that you bundle will get forwarded several times? Do you want to modified it on every forward?

If not and you want only to skip the last entry of the block, you can modify its serialization as I told before to Brenton. https://mail.ibr.cs.tu-bs.de/pipermail/ibr-dtn/2014-April/000771.html

Another approach would be to modify the bundle right before it is serialized in every convergence layer. At the moment the centralized method for that is missing, but I see the need for that.

Kind regards, Johannes

Am 25.04.2014 21:24, schrieb Tomasz Kalbarczyk:

...

I have the following:

• A bundle that has an extension block, which includes a list of entries.

I need to process the bundle as follows:

• Peek at the end of the list, and based on the value of a variable

maintained in my RoutingExtension, pop off the end of the list, before forwarding the bundle.

My question is, where is the appropriate place to modify this bundle (i.e., pop the end of the list) ?

I currently peek at the list when a meta bundle is generated from the bundle.

However, I'm unclear what the appropriate place is to modify the bundle, so that is only changed once prior to forwarding.

-- Johannes Morgenroth Institut fuer Betriebssysteme und Rechnerverbund Tel.: +49-531-391-3249 Muehlenpfordtstrasse 23 Fax.: +49-531-391-5936 TU Braunschweig D-38106 Braunschweig -- !! This message is brought to you via the `ibr-dtn' mailing list. !! Please do not reply to this message to unsubscribe. To unsubscribe or adjust !! your settings, send a mail message to ibr-dtn-request@ibr.cs.tu-bs.de !! or look at https://mail.ibr.cs.tu-bs.de/listinfo/ibr-dtn.

By extended period of time, I just meant that the bundle might need to get updated a few times (as location changes) before it is forwarded.

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()

Should I be raising a "dtn::core::BundleGeneratedEvent" ?

Thanks, Tomasz

On Thu, May 8, 2014 at 2:25 AM, Johannes Morgenroth < morgenroth@ibr.cs.tu-bs.de> wrote:

Am 01.05.2014 01:01, schrieb Tomasz Kalbarczyk:

...

Thanks for the reply Johannes.

I think I was a bit unclear during my previous explanation.

It is possible that the bundle will be stored at the host for an extended period of time. As the location changes, I'd like to periodically grab the bundle from storage, modify the block, and then place it back in storage.

What do you mean by an extended period of time? The lifetime of the bundle?

...

Is there any mechanism to do this from within the routingextension (or elsewhere) ?

At any time and any place you can load a bundle from the storage, delete it and store the modified one again. Accessing the storage is possible through the singleton instance of BundleCore. But doing that with all bundles would not be efficient.

...

I suppose I could maintain a separate data structure that records all of the entries that I need to remove, and then remove them all at once when the bundle is forwarded (during serialization), but I was hoping to avoid having to maintain this data structure since it seems inefficient and error prone.

-- Johannes

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