Subject: Re: [dtn-users] DTN2 & LTPlib
From: Lloyd Wood <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: "Burleigh, Scott C. \(JPL-313B\)\[Caltech-JPL\]" <[email-masked]>, dtn-users mailing list <[email-masked]>, Lloyd Wood <[email-masked]>
Date: Fri, 20 Nov 2009 13:51:25 +0000
List-Id: dtn-users mailing list <dtn-users.maillists.intel-research.net>

On 20 Nov 2009, at 13:15, Stephen Farrell wrote:
> However, its a bit odd though - it seems to make all the red/green stuff
> in LTP meaningless doesn't it?

To be fair, that was pretty meaningless already.

> I'm also not that sure of the benefits of getting one ack for a set of
> bundles - is that really a huge win?

and what does it do for head-of-line blocking?

L.

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

Date: Fri, 20 Nov 2009 13:15:58 +0000
From: Stephen Farrell <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: dtn-users mailing list <[email-masked]>, "Burleigh, Scott C. \(JPL-313B\)\[Caltech-JPL\]" <[email-masked]>
Subject: Re: [dtn-users] DTN2 & LTPlib

Ivancic, William D. (GRC-RHN0) wrote:
>> Good question.  One of the major advantages of LTP that I've been
>> trumpeting here is that unlike CFDP it gives you a degree of control
>> over the data rate of acknowledgement traffic.  Acknowledgements are at
>> block granularity, so if you aggregate multiple files (for example) into
>> a single LTP block you'll only get a single ack for the whole lot rather
>> than one for each file as with acknowledged CFDP.
> 
> Scott, is this part of the specification or a particular implementation or special case implementation? 
> 
> What I mean is, will this cause interoperability problems with other independent implementations of LTP?  
> 
> If this aggregation is not part of the specification, should it be?

Good question. If we want to use this more broadly then it'd call for
an LTP CL spec to be written that says how to do this. If that's the
plan then we should discuss that on the dtn-interest list rather than
here.

However, its a bit odd though - it seems to make all the red/green stuff
in LTP meaningless doesn't it?

I'm also not that sure of the benefits of getting one ack for a set of
bundles - is that really a huge win?

S.

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "Burleigh, Scott C. (JPL-313B)[Caltech-JPL]" <[email-masked]>,  Stephen Farrell <[email-masked]>, dtn-users mailing list <[email-masked]>
Date: Fri, 20 Nov 2009 07:04:56 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-users] DTN2 & LTPlib

>
>Good question.  One of the major advantages of LTP that I've been
>trumpeting here is that unlike CFDP it gives you a degree of control
>over the data rate of acknowledgement traffic.  Acknowledgements are at
>block granularity, so if you aggregate multiple files (for example) into
>a single LTP block you'll only get a single ack for the whole lot rather
>than one for each file as with acknowledged CFDP.

Scott, is this part of the specification or a particular implementation or special case implementation? 

What I mean is, will this cause interoperability problems with other independent implementations of LTP?  

If this aggregation is not part of the specification, should it be?

--Will

>
>So ION's LTP CL adapter will aggregate an integral number of whole
>bundles into each LTP block, limited by a managed maximum block size.
>The aggregated bundles are simply concatenated together in the service
>data unit, so the CLA needs to be clever enough to figure out the length
>of each block; this unfortunately means doing a bit of pre-parsing of
>the bundle header, which is non-trivial.  Feel free to lift the ION code
>that does this, if you want.
>
>Also, I have somewhat peremptorily grabbed LTP client service ID 1 for
>bundle protocol traffic in ION.  An easy thing to change if we find it
>necessary, but I do think of BP as the primary client service for LTP.
>
>Scott
>

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Stephen Farrell <[email-masked]>, dtn-users mailing list <[email-masked]>
Date: Thu, 19 Nov 2009 10:08:50 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-users] DTN2 & LTPlib

> -----Original Message-----
> From: [email-masked] [mailto:dtn-users-
> [email-masked]] On Behalf Of Stephen Farrell
> Sent: Thursday, November 19, 2009 4:37 AM
> To: dtn-users mailing list
> Subject: [dtn-users] DTN2 & LTPlib
> 
> 
> Hi all,
> 
> We've (i.e. TCD) a bit of work starting to use DTN2 to send
> bundles over an LTP convergence layer. (Finally;-)
> 
> Plan is to start that next week. Darragh O'Keefe will be doing
> the real work. In parallel, Alex is currently working on a DTN2
> 2.7 release while visiting with Kevin in Berkeley. Not sure if
> the LTP CL will make it into the 2.7.0 DTN2 release or not at
> this stage since the timing of both is still somewhat TBD. I
> wouldn't however want to hold up DTN2 2.7.0 for this.
> 
> LTPlib is my implementation of LTP. [1] While the code structure
> is quite naff (I'm not a s/w purist:-), it has interop'd with both
> Mani's Java LTP code and, to some degree, with ION.
> 
> So, two questions:
> 
> 1) Should we move my LTP code into the DTN2 build, or is it better
> to keep LTPlib as a separate build and just link the library?
> 
> If the former, then DTN2 would include everything you need for
> sending bundles over LTP, which I kind of like. So, assuming
> nothing turns up during the actual work, I think I'd favour
> including the LTPlib code as part of DTN2. (We'll re-do the
> license text in that case to match the DTN2 Apache license,
> currently LTPlib is Mozilla public license v1.1.)

That sounds to me like a good approach.

> 2) Is there anything in how ION does bundles over LTP that we
> should watch out for when doing the DTN2 LTP CL?
>
> Our plan is just to start from the UDP CL and replace calls
> to sendto() with ltp_sendto() etc. I know that ION has some
> restrictions on the lengths of fields in LTP, (that LTPlib
> can already work with), but is there anything else at the
> CL-level?

Good question.  One of the major advantages of LTP that I've been trumpeting here is that unlike CFDP it gives you a degree of control over the data rate of acknowledgement traffic.  Acknowledgements are at block granularity, so if you aggregate multiple files (for example) into a single LTP block you'll only get a single ack for the whole lot rather than one for each file as with acknowledged CFDP.

So ION's LTP CL adapter will aggregate an integral number of whole bundles into each LTP block, limited by a managed maximum block size.  The aggregated bundles are simply concatenated together in the service data unit, so the CLA needs to be clever enough to figure out the length of each block; this unfortunately means doing a bit of pre-parsing of the bundle header, which is non-trivial.  Feel free to lift the ION code that does this, if you want.

Also, I have somewhat peremptorily grabbed LTP client service ID 1 for bundle protocol traffic in ION.  An easy thing to change if we find it necessary, but I do think of BP as the primary client service for LTP.

Scott

Date: Thu, 19 Nov 2009 12:36:33 +0000
From: Stephen Farrell <[email-masked]>
To: dtn-users mailing list <[email-masked]>
Subject: [dtn-users] DTN2 & LTPlib

Hi all,

We've (i.e. TCD) a bit of work starting to use DTN2 to send
bundles over an LTP convergence layer. (Finally;-)

Plan is to start that next week. Darragh O'Keefe will be doing
the real work. In parallel, Alex is currently working on a DTN2
2.7 release while visiting with Kevin in Berkeley. Not sure if
the LTP CL will make it into the 2.7.0 DTN2 release or not at
this stage since the timing of both is still somewhat TBD. I
wouldn't however want to hold up DTN2 2.7.0 for this.

LTPlib is my implementation of LTP. [1] While the code structure
is quite naff (I'm not a s/w purist:-), it has interop'd with both
Mani's Java LTP code and, to some degree, with ION.

So, two questions:

1) Should we move my LTP code into the DTN2 build, or is it better
to keep LTPlib as a separate build and just link the library?

If the former, then DTN2 would include everything you need for
sending bundles over LTP, which I kind of like. So, assuming
nothing turns up during the actual work, I think I'd favour
including the LTPlib code as part of DTN2. (We'll re-do the
license text in that case to match the DTN2 Apache license,
currently LTPlib is Mozilla public license v1.1.)

2) Is there anything in how ION does bundles over LTP that we
should watch out for when doing the DTN2 LTP CL?

Our plan is just to start from the UDP CL and replace calls
to sendto() with ltp_sendto() etc. I know that ION has some
restrictions on the lengths of fields in LTP, (that LTPlib
can already work with), but is there anything else at the
CL-level?

Thanks,
Stephen.

[1] http://down.dsg.cs.tcd.ie/ltplib/

Date: Fri, 06 Nov 2009 16:20:32 +0000
From: Elwyn Davies <[email-masked]>
To: [email-masked]
Subject: [dtn-users] [Fwd: Re: [dtn-interest] Help in compiling Python API for DTN]

This is a multi-part message in MIME format.
--------------060802000506050009080403
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Redirecting to more appropriate list...

/Elwyn

--------------060802000506050009080403
Content-Type: message/rfc822;
	name="Re: [dtn-interest] Help in compiling Python API for DTN.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
	filename*0="Re: [dtn-interest] Help in compiling Python API for
	DTN.eml"

Message-ID: <[email-masked]>
Date: Fri, 06 Nov 2009 16:16:29 +0000
From: Elwyn Davies <[email-masked]>
User-Agent: Thunderbird 2.0.0.19 (X11/20081209)
MIME-Version: 1.0
To: Abdullah Azfar <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] Help in compiling Python API for DTN
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi.

This is a piece of 'lore' that ought to be documented!

First of all ensure that your Python installation has the  'distutils' 
installed.

Assuming you have a build of DTN2 on the machine, make the 'applib' 
sub-directory of the DTN build directory your current directory.  Then do
make pythonapi
make pythonapi_install

For native builds this is straightforwards.  For cross compilations 
there are (or maybe) some complications because of the way that the 
Python extension building system works.
 
This process sorts out the requisite definitions of the variables you 
mention automatically.

Regards,
Elwyn

Abdullah Azfar wrote:
> Hi,
> I need to compile the Python API in DTN. I am new in Python and Swig 
> and facing difficulty to compile Python API and test whether it is 
> running by swig. I do not know what to set for the INCDIR, LIBDIR and 
> VERSION environment variables. Please help in this regard. Could 
> anyone please give a pointer for a particular documentation for this 
> setup?
>
> Regards,
>  
> Abdullah Azfar
> NordSecMob Masters Student in Security and Mobile Computing
> Department of Information and Communication Technology
> The Royal Institute of Technology - KTH
> Sweden
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>   

--------------060802000506050009080403--

Sender: Alex McMahon <[email-masked]>
From: Alex McMahon <[email-masked]>
To: Nick Fox <[email-masked]>
Organization: Trinity College Dublin
Date: Mon, 02 Nov 2009 14:53:53 -0800
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-users] bundle expire malfunction??
Reply-To: [email-masked]

--=-kgzuzH0CEPIEn8btbfpN
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Nick,

I recreated your scene and got the same result and this is not the the
intended behaviour - once the bundle has expired it should not appear on
any more lists. Bundle expiration may occur at any point in the
processing of a bundle and when a bundle expires, the bundle protocol
agent must delete the bundle.  In the scene you presented all of the
bundle's retention constraints must be removed but as you have pointed
out are not. There is no way to control which lists a bundle is "queued
on" using the tcl interface.   

I was only able to recreate this bug using routing type flood when the
bundle is defered and expires.  Even though the bundle is expired
(manually or timed) a number of mappings remain on the list which can be
seen from the warning produced by the daemon 'expired bundle bundle id 0
[dtn://sphere.dtn -> dtn://nobody1.dtn 11 byte payload] still has 3
mappings (i.e. not just in ALL_BUNDLES)'

The code which expires the bundle  from 'BundleDaemon.cc' is shown
below. 

2114     if (event->type_ == BUNDLE_EXPIRED) {
2115         bundle = ((BundleExpiredEvent*)event)->bundleref_.object();
2116         size_t num_mappings = bundle->num_mappings();
2117         if (num_mappings != 1) {
2118             log_warn("expired bundle *%p still has %zu mappings (i.e. not just in ALL_BUNDLES)",
2119                      bundle.object(), num_mappings);

)

The reason seems to be that in the implementation of flood routing the
class maintains an internal BundleList 'all_bundles_', a separate list,
in which all bundles are kept until their expiration time. The intention
is to prevent the main daemon logic from opportunistically deleting
bundles when they've been transmitted to ensure bundles aren't deleted
by the system just after they are forwarded. However, this design
appears to be the cause of the bug the bundles are not being expired
from this list by the main daemon logic

Alex

On Mon, 2009-11-02 at 10:29 -0500, Nick Fox wrote:

> Alex: What you are describing is exactly what I expected to happen,
> however that is not what I am seeing happen.  Let me attempt to
> explain again more clearly.
> 
> I have a node N1 configured with flood routing, route discovery, and
> the parameter early bundle deletion = true (this is true by default).
> It contains two links in its routing table: link-0 to N2 and link-1 to
> N3.  The scenario begins with both links closed.  
> 
> With both links closed I send a bundle manually with dtnsend to a node
> that doesn't exist: "dtnsend -s dtn://N1.dtn -d dtn://nobody.dtn -t m
> -p "hello world". (the expiration timer is default so 3600 seconds)
> 
> At this point I run "bundle info 0" and see the bundle is queued on 5
> lists: all_bundles, pending_bundles, FloodBundleRouter::all_bundles,
> link-0:deferred, and link-1:deferred.
> 
> Now I open link-0.  The bundle is flooded to node N2. I close link-0
> again.  At this point both links are again unavailable.
> 
> I again run "bundle info 0".  Now i see the bundle is only queued on 4
> lists: all_bundles, pending_bundles, FloodBundleRouter::all_bundles,
> and link-1:deferred.  (this is what i expect since we just sent it to
> link-0)
> 
> Now the unexpected behavior.  I run "bundle expire 0".  Now when I run
> bundle list I see:
> 
>     All Bundles (1):
>                  0  : dtn://N1.dtn -> dtn://nobody.dtn length 11 (NOT
> PENDING)
> 
> I then run "bundle info 0".  This time I see the bundle is queued on 2
> lists: all_bundles and link-1:deferred.
> 
> The bundle will remain in the bundle list until the bundle is
> transmitted over link-1.  At that point, it will finally disappear
> from the bundle list.
> 
> Again, is the the intended behavior?  If so is there a way to control
> which lists a bundle is "queued on"?  Is anyone else experiencing the
> same situation I am?
> 
> Thanks in advance for your help/suggestions,
> 
> -Nick Fox
> 
> 
> 
> 
> On Fri, Oct 30, 2009 at 5:30 PM, Alex McMahon <[email-masked]>
> wrote:
> 
>         Expiring a bundle would simply remove it from the bundle list
>         immediately and delete the bundle.  I believe what you are
>         seeing is one of three registrations being deleted and not the
>         expiration of the bundle.  If the bundle expires ( you could
>         try manually expiring it with 'bundle expire <id>')before all
>         known nodes have been encountered, I expect the bundle would
>         disappear from the bundle list and is deleted.  
>         
>         
>         Alex
>         
>         1) no bundles / default registrations
>         sphere dtn% bundle list
>         All Bundles (0): 
>         
>         sphere dtn% registration list
>         id 0: active dtn://sphere.dtn (DEFER) [expiration 0]
>         id 2: active dtn://sphere.dtn/ping (DEFER) [expiration 0]
>         
>         sphere dtn% route dump
>         Route table for flood router:
>         
>         destinatio source COS    next hop    fwd    route [custody
>         timeout]
>         endpoint i  eid   BNE    link/eid   action   prio [min   pct
>         max]
>         -----------------------------------------------------------------------------
>         
>         Class of Service (COS) bits:
>         B: Bulk  N: Normal  E: Expedited
>         
>         Links:
>         
>         2) Two bundles sent with expiration time of 10 seconds to EID
>         that does no exist. Bundles 8 & 9 and registrations 14 & 15
>         are visible  
>         
>         $ dtnping -c 1 -e 10 dtn://blahblah2/ping
>         source_eid [dtn://sphere.dtn/ping.1747]
>         dtn_register succeeded, regid 15
>         
>         
>         $ dtnping -c 1 -e 10 dtn://blahblah1/ping
>         source_eid [dtn://sphere.dtn/ping.1745]
>         dtn_register succeeded, regid 14
>         
>         
>         sphere dtn% bundle list
>         All Bundles (2): 
>         8  : dtn://sphere.dtn/ping.1745 -> dtn://blahblah1/ping length
>         20
>         9  : dtn://sphere.dtn/ping.1747 -> dtn://blahblah2/ping length
>         20
>         
>         sphere dtn% registration list
>         id 0: active dtn://sphere.dtn (DEFER) [expiration 0]
>         id 2: active dtn://sphere.dtn/ping (DEFER) [expiration 0]
>         id 14: active dtn://sphere.dtn/ping.1745 (DEFER) [expiration
>         0]
>         id 15: active dtn://sphere.dtn/ping.1747 (DEFER) [expiration
>         0]
>         
>         sphere dtn% route dump
>         Route table for flood router:
>         
>         destinatio source COS    next hop    fwd    route [custody
>         timeout]
>         endpoint i  eid   BNE    link/eid   action   prio [min   pct
>         max]
>         -----------------------------------------------------------------------------
>         
>         Class of Service (COS) bits:
>         B: Bulk  N: Normal  E: Expedited
>         
>         Links:
>         
>         
>         3) After 10 seconds as expected the registration expires and
>         bundle expires. Registrations 14 & 15 and bundles 8 & 9 are
>         gone from lists. A signal is given by the dtnping application
>         for both bundles.  
>         
>         PING [dtn://blahblah1/ping] (expiration 10)...
>         bundle deleted at [dtn://sphere.dtn] (lifetime expired):
>         seqno=0, time=10004 m
>         
>         PING [dtn://blahblah1/ping] (expiration 10)...
>         bundle deleted at [dtn://sphere.dtn] (lifetime expired):
>         seqno=0, time=10002 ms
>         
>         sphere dtn% bundle list
>         All Bundles (0): 
>         
>         sphere dtn% registration list
>         id 0: active dtn://sphere.dtn (DEFER) [expiration 0]
>         id 2: active dtn://sphere.dtn/ping (DEFER) [expiration 0]
>         
>         sphere dtn% route dump
>         Route table for flood router:
>         
>         destinatio source COS    next hop    fwd    route [custody
>         timeout]
>         endpoint i  eid   BNE    link/eid   action   prio [min   pct
>         max]
>         -----------------------------------------------------------------------------
>         
>         Class of Service (COS) bits:
>         B: Bulk  N: Normal  E: Expedited
>         
>         Links:
>         
>         
>         
>         On Wed, 2009-09-30 at 14:44 -0400, Nick Fox wrote:
>         
>         > I am using DTN2-2.6.0 and flooding routing.  I believe I am
>         > experiencing some odd behavior with the bundle expire
>         > command.
>         > 
>         > Here is my test scenario:
>         > 
>         > Nodes N1, N2, N3, and N4 all have entries in each others
>         > link lists.  Say N1 has a dtnsend command run on it while
>         > all links are closed which creates bundle B1.  If a bundle
>         > info command is run on B1, then it is "queued" of the
>         > following lists:all_bundles, pending_bundles,
>         > FloodBundleRouter::all_bundles, link-0:deferred,
>         > link-1:deferred, and link-2:deferred (link-0=N2, link-1=N3,
>         > link-2=N4).  Now if the link opens with N3, the bundle is
>         > flooded to N3 and a bundle expire command is run on the
>         > bundle on N1.  Here is the what I see on N1.  Bundle list
>         > status = NOT PENDING.  Now if bundle info is run on it, it
>         > is "queued" on the following lists:all_bundles,
>         > link-0:deferred, link-2:deferred.  If N1 now opens a link
>         > with N2 and/or N4, the bundle is still flooded to the node
>         > and it is removed from the corresponding link:deferred list.
>         > When all known nodes have been encountered, then the bundle
>         > finally disappears from the bundle list and is deleted.
>         > Note: if N1 were to open a link to a "new" node ex. N6, then
>         > the bundle would be flooded to N6 as well.
>         > 
>         > I am curious, is this the intended behavior of the bundle
>         > expire command? I was under the impression that expiring a
>         > bundle would simply remove it from the bundle list
>         > immediately and delete the bundle.  Also, if this is the
>         > intended behavior for bundle expire, is there a way to
>         > manually alter which lists a bundle is a part of?  
>         > 
>         > Thanks in advance for your comments/suggestions.
>         > 
>         > Nick Fox 
>         > 
>         > _______________________________________________
>         > dtn-users mailing list
>         > [email-masked]
>         > http://maillists.intel-research.net/mailman/listinfo/dtn-users
> 
> 

--=-kgzuzH0CEPIEn8btbfpN
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; CHARSET=3DUTF-8">
  <META NAME=3D"GENERATOR" CONTENT=3D"GtkHTML/3.26.0">
</HEAD>
<BODY>
Nick,<BR>
<BR>
I recreated your scene and got the same result and this is not the the inte=
nded behaviour - once the bundle has expired it should not appear on any mo=
re lists. Bundle expiration may occur at any point in the processing of a b=
undle and when a bundle expires, the bundle protocol agent must delete the =
bundle.&nbsp; In the scene you presented all of the bundle's retention cons=
traints must be removed but as you have pointed out are not. There is no wa=
y to control which lists a bundle is &quot;queued on&quot; using the tcl in=
terface.&nbsp;&nbsp; <BR>
<BR>
I was only able to recreate this bug using routing type flood when the bund=
le is defered and expires.&nbsp; Even though the bundle is expired (manuall=
y or timed) a number of mappings remain on the list which can be seen from =
the warning produced by the daemon 'expired bundle bundle id 0 [dtn://spher=
e.dtn -&gt; dtn://nobody1.dtn 11 byte payload] still has 3 mappings (i.e. n=
ot just in ALL_BUNDLES)'<BR>
<BR>
The code which expires the bundle&nbsp; from 'BundleDaemon.cc' is shown bel=
ow. <BR>
<BR>
<PRE>
<A HREF=3D"http://dtn.hg.sourceforge.net/hgweb/dtn/DTN2/file/75810bc10946/s=
ervlib/bundling/BundleDaemon.cc#l2114">2114</A>     if (event-&gt;type_ =3D=
=3D BUNDLE_EXPIRED) {
</PRE>
<PRE>
<A HREF=3D"http://dtn.hg.sourceforge.net/hgweb/dtn/DTN2/file/75810bc10946/s=
ervlib/bundling/BundleDaemon.cc#l2115">2115</A>         bundle =3D ((Bundle=
ExpiredEvent*)event)-&gt;bundleref_.object();
</PRE>
<PRE>
<A HREF=3D"http://dtn.hg.sourceforge.net/hgweb/dtn/DTN2/file/75810bc10946/s=
ervlib/bundling/BundleDaemon.cc#l2116">2116</A>         size_t num_mappings=
 =3D bundle-&gt;num_mappings();
</PRE>
<PRE>
<A HREF=3D"http://dtn.hg.sourceforge.net/hgweb/dtn/DTN2/file/75810bc10946/s=
ervlib/bundling/BundleDaemon.cc#l2117">2117</A>         if (num_mappings !=
=3D 1) {
</PRE>
<PRE>
<A HREF=3D"http://dtn.hg.sourceforge.net/hgweb/dtn/DTN2/file/75810bc10946/s=
ervlib/bundling/BundleDaemon.cc#l2118">2118</A>             log_warn(&quot;=
expired bundle *%p still has %zu mappings (i.e. not just in ALL_BUNDLES)&qu=
ot;,
</PRE>
<PRE>
<A HREF=3D"http://dtn.hg.sourceforge.net/hgweb/dtn/DTN2/file/75810bc10946/s=
ervlib/bundling/BundleDaemon.cc#l2119">2119</A>                      bundle=
.object(), num_mappings);
</PRE>
<BR>
<BR>
)<BR>
<BR>
The reason seems to be that in the implementation of flood routing the clas=
s maintains an internal BundleList 'all_bundles_', a separate list,&nbsp; i=
n which all bundles are kept until their expiration time. The intention&nbs=
p; is to prevent the main daemon logic from opportunistically deleting bund=
les when they've been transmitted to ensure bundles aren't deleted by the s=
ystem just after they are forwarded. However, this design appears to be the=
 cause of the bug the bundles are not being expired from this list by the m=
ain daemon logic<BR>
<BR>
<BR>
Alex<BR>
<BR>
<BR>
On Mon, 2009-11-02 at 10:29 -0500, Nick Fox wrote:<BR>
<BLOCKQUOTE TYPE=3DCITE>
    Alex: What you are describing is exactly what I expected to happen, how=
ever that is not what I am seeing happen.&nbsp; Let me attempt to explain a=
gain more clearly.<BR>
    <BR>
    I have a node N1 configured with flood routing, route discovery, and th=
e parameter early bundle deletion =3D true (this is true by default).&nbsp;=
 It contains two links in its routing table: link-0 to N2 and link-1 to N3.=
&nbsp; The scenario begins with both links closed.&nbsp; <BR>
    <BR>
    With both links closed I send a bundle manually with dtnsend to a node =
that doesn't exist: &quot;dtnsend -s dtn://N1.dtn -d dtn://nobody.dtn -t m =
-p &quot;hello world&quot;. (the expiration timer is default so 3600 second=
s)<BR>
    <BR>
    At this point I run &quot;bundle info 0&quot; and see the bundle is que=
ued on 5 lists: all_bundles, pending_bundles, FloodBundleRouter::all_bundle=
s, link-0:deferred, and link-1:deferred.<BR>
    <BR>
    Now I open link-0.&nbsp; The bundle is flooded to node N2. I close link=
-0 again.&nbsp; At this point both links are again unavailable.<BR>
    <BR>
    I again run &quot;bundle info 0&quot;.&nbsp; Now i see the bundle is on=
ly queued on 4 lists: all_bundles, pending_bundles, FloodBundleRouter::all_=
bundles, and link-1:deferred.&nbsp; (this is what i expect since we just se=
nt it to link-0)<BR>
    <BR>
    Now the unexpected behavior.&nbsp; I run &quot;bundle expire 0&quot;.&n=
bsp; Now when I run bundle list I see:<BR>
    <BR>
    &nbsp;&nbsp;&nbsp; All Bundles (1):<BR>
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &nbsp;&nbsp;=
 0&nbsp; : dtn://N1.dtn -&gt; dtn://nobody.dtn length 11 (NOT PENDING)<BR>
    <BR>
    I then run &quot;bundle info 0&quot;.&nbsp; This time I see the bundle =
is queued on 2 lists: all_bundles and link-1:deferred.<BR>
    <BR>
    The bundle will remain in the bundle list until the bundle is transmitt=
ed over link-1.&nbsp; At that point, it will finally disappear from the bun=
dle list.<BR>
    <BR>
    Again, is the the intended behavior?&nbsp; If so is there a way to cont=
rol which lists a bundle is &quot;queued on&quot;?&nbsp; Is anyone else exp=
eriencing the same situation I am?<BR>
    <BR>
    Thanks in advance for your help/suggestions,<BR>
    <BR>
    -Nick Fox<BR>
    <BR>
    <BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=3DCITE>
    On Fri, Oct 30, 2009 at 5:30 PM, Alex McMahon &lt;<A HREF=3D"mailto:ale=
[email-masked]">[email-masked]</A>&gt; wrote:
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=3DCITE>
    <BLOCKQUOTE>
        Expiring a bundle would simply remove it from the bundle list immed=
iately and delete the bundle.&nbsp; I believe what you are seeing is one of=
 three registrations being deleted and not the expiration of the bundle.&nb=
sp; If the bundle expires ( you could try manually expiring it with 'bundle=
 expire &lt;id&gt;')before all known nodes have been encountered, I expect =
the bundle would disappear from the bundle list and is deleted.&nbsp; <BR>
        <BR>
        <BR>
        Alex<BR>
        <BR>
        <B>1) no bundles / default registrations</B><BR>
        sphere dtn% bundle list<BR>
        All Bundles (0): <BR>
        <BR>
        sphere dtn% registration list<BR>
        id 0: active dtn://sphere.dtn (DEFER) [expiration 0]<BR>
        id 2: active dtn://sphere.dtn/ping (DEFER) [expiration 0]<BR>
        <BR>
        sphere dtn% route dump<BR>
        Route table for flood router:<BR>
        <BR>
        destinatio source COS&nbsp;&nbsp;&nbsp; next hop&nbsp;&nbsp;&nbsp; =
fwd&nbsp;&nbsp;&nbsp; route [custody timeout]<BR>
        endpoint i&nbsp; eid&nbsp;&nbsp; BNE&nbsp;&nbsp;&nbsp; link/eid&nbs=
p;&nbsp; action&nbsp;&nbsp; prio [min&nbsp;&nbsp; pct&nbsp;&nbsp; max]<BR>
        -------------------------------------------------------------------=
----------<BR>
        <BR>
        Class of Service (COS) bits:<BR>
        B: Bulk&nbsp; N: Normal&nbsp; E: Expedited<BR>
        <BR>
        Links:<BR>
        <BR>
        <B>2) Two bundles sent with expiration time of 10 seconds to EID th=
at does no exist. Bundles 8 &amp; 9 and registrations 14 &amp; 15 are visib=
le&nbsp; </B><BR>
        <BR>
        <B>$ dtnping -c 1 -e 10 dtn://blahblah2/ping</B><BR>
        <B>source_eid [dtn://sphere.dtn/ping.1747]</B><BR>
        <B>dtn_register succeeded, regid 15</B><BR>
        <BR>
        <BR>
        <B>$ dtnping -c 1 -e 10 dtn://blahblah1/ping</B><BR>
        <B>source_eid [dtn://sphere.dtn/ping.1745]</B><BR>
        <B>dtn_register succeeded, regid 14</B><BR>
        <BR>
        <BR>
        sphere dtn% bundle list<BR>
        All Bundles (2): <BR>
        8&nbsp; : dtn://sphere.dtn/ping.1745 -&gt; dtn://blahblah1/ping len=
gth 20<BR>
        9&nbsp; : dtn://sphere.dtn/ping.1747 -&gt; dtn://blahblah2/ping len=
gth 20<BR>
        <BR>
        sphere dtn% registration list<BR>
        id 0: active dtn://sphere.dtn (DEFER) [expiration 0]<BR>
        id 2: active dtn://sphere.dtn/ping (DEFER) [expiration 0]<BR>
        id 14: active dtn://sphere.dtn/ping.1745 (DEFER) [expiration 0]<BR>
        id 15: active dtn://sphere.dtn/ping.1747 (DEFER) [expiration 0]<BR>
        <BR>
        sphere dtn% route dump<BR>
        Route table for flood router:<BR>
        <BR>
        destinatio source COS&nbsp;&nbsp;&nbsp; next hop&nbsp;&nbsp;&nbsp; =
fwd&nbsp;&nbsp;&nbsp; route [custody timeout]<BR>
        endpoint i&nbsp; eid&nbsp;&nbsp; BNE&nbsp;&nbsp;&nbsp; link/eid&nbs=
p;&nbsp; action&nbsp;&nbsp; prio [min&nbsp;&nbsp; pct&nbsp;&nbsp; max]<BR>
        -------------------------------------------------------------------=
----------<BR>
        <BR>
        Class of Service (COS) bits:<BR>
        B: Bulk&nbsp; N: Normal&nbsp; E: Expedited<BR>
        <BR>
        Links:<BR>
        <BR>
        <BR>
        <B>3) After 10 seconds as expected the registration expires and bun=
dle expires. Registrations 14 &amp; 15 and bundles 8 &amp; 9 are gone from =
lists. A signal is given by the dtnping application for both bundles.&nbsp;=
 </B><BR>
        <BR>
        <B>PING [dtn://blahblah1/ping] (expiration 10)...</B><BR>
        <B>bundle deleted at [dtn://sphere.dtn] (lifetime expired): seqno=
=3D0, time=3D10004 m</B><BR>
        <BR>
        <B>PING [dtn://blahblah1/ping] (expiration 10)...</B><BR>
        <B>bundle deleted at [dtn://sphere.dtn] (lifetime expired): seqno=
=3D0, time=3D10002 ms</B><BR>
        <BR>
        sphere dtn% bundle list<BR>
        All Bundles (0): <BR>
        <BR>
        sphere dtn% registration list<BR>
        id 0: active dtn://sphere.dtn (DEFER) [expiration 0]<BR>
        id 2: active dtn://sphere.dtn/ping (DEFER) [expiration 0]<BR>
        <BR>
        sphere dtn% route dump<BR>
        Route table for flood router:<BR>
        <BR>
        destinatio source COS&nbsp;&nbsp;&nbsp; next hop&nbsp;&nbsp;&nbsp; =
fwd&nbsp;&nbsp;&nbsp; route [custody timeout]<BR>
        endpoint i&nbsp; eid&nbsp;&nbsp; BNE&nbsp;&nbsp;&nbsp; link/eid&nbs=
p;&nbsp; action&nbsp;&nbsp; prio [min&nbsp;&nbsp; pct&nbsp;&nbsp; max]<BR>
        -------------------------------------------------------------------=
----------<BR>
        <BR>
        Class of Service (COS) bits:<BR>
        B: Bulk&nbsp; N: Normal&nbsp; E: Expedited<BR>
        <BR>
        Links:<BR>
        <BR>
        <BR>
        <BR>
        On Wed, 2009-09-30 at 14:44 -0400, Nick Fox wrote:<BR>
        <BLOCKQUOTE TYPE=3DCITE>
            I am using DTN2-2.6.0 and flooding routing.&nbsp; I believe I a=
m experiencing some odd behavior with the bundle expire command.<BR>
            <BR>
            Here is my test scenario:<BR>
            <BR>
            Nodes N1, N2, N3, and N4 all have entries in each others link l=
ists.&nbsp; Say N1 has a dtnsend command run on it while all links are clos=
ed which creates bundle B1.&nbsp; If a bundle info command is run on B1, th=
en it is &quot;queued&quot; of the following lists:all_bundles, pending_bun=
dles, FloodBundleRouter::all_bundles, link-0:deferred, link-1:deferred, and=
 link-2:deferred (link-0=3DN2, link-1=3DN3, link-2=3DN4).&nbsp; Now if the =
link opens with N3, the bundle is flooded to N3 and a bundle expire command=
 is run on the bundle on N1.&nbsp; Here is the what I see on N1.&nbsp; Bund=
le list status =3D NOT PENDING.&nbsp; Now if bundle info is run on it, it i=
s &quot;queued&quot; on the following lists:all_bundles, link-0:deferred, l=
ink-2:deferred.&nbsp; If N1 now opens a link with N2 and/or N4, the bundle =
is still flooded to the node and it is removed from the corresponding link:=
deferred list.&nbsp; When all known nodes have been encountered, then the b=
undle finally disappears from the bundle list and is deleted.&nbsp; Note: i=
f N1 were to open a link to a &quot;new&quot; node ex. N6, then the bundle =
would be flooded to N6 as well.<BR>
            <BR>
            I am curious, is this the intended behavior of the bundle expir=
e command? I was under the impression that expiring a bundle would simply r=
emove it from the bundle list immediately and delete the bundle.&nbsp; Also=
, if this is the intended behavior for bundle expire, is there a way to man=
ually alter which lists a bundle is a part of?&nbsp; <BR>
            <BR>
            Thanks in advance for your comments/suggestions.<BR>
            <BR>
            Nick Fox=20
<PRE>
_______________________________________________
dtn-users mailing list
<A HREF=3D"mailto:[email-masked]">dtn-users@maillis=
ts.intel-research.net</A>
<A HREF=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-users">=
http://maillists.intel-research.net/mailman/listinfo/dtn-users</A>
</PRE>
        </BLOCKQUOTE>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=3DCITE>
    <BR>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-kgzuzH0CEPIEn8btbfpN--

Sender: [email-masked]
Date: Mon, 2 Nov 2009 10:29:04 -0500
From: Nick Fox <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-users] bundle expire malfunction??

--00c09ffb4d2fb315a104776509d9
Content-Type: text/plain; charset=ISO-8859-1

Alex: What you are describing is exactly what I expected to happen, however
that is not what I am seeing happen.  Let me attempt to explain again more
clearly.

I have a node N1 configured with flood routing, route discovery, and the
parameter early bundle deletion = true (this is true by default).  It
contains two links in its routing table: link-0 to N2 and link-1 to N3.  The
scenario begins with both links closed.

With both links closed I send a bundle manually with dtnsend to a node that
doesn't exist: "dtnsend -s dtn://N1.dtn -d dtn://nobody.dtn -t m -p "hello
world". (the expiration timer is default so 3600 seconds)

At this point I run "bundle info 0" and see the bundle is queued on 5 lists:
all_bundles, pending_bundles, FloodBundleRouter::all_bundles,
link-0:deferred, and link-1:deferred.

Now I open link-0.  The bundle is flooded to node N2. I close link-0 again.
At this point both links are again unavailable.

I again run "bundle info 0".  Now i see the bundle is only queued on 4
lists: all_bundles, pending_bundles, FloodBundleRouter::all_bundles, and
link-1:deferred.  (this is what i expect since we just sent it to link-0)

Now the unexpected behavior.  I run "bundle expire 0".  Now when I run
bundle list I see:

    All Bundles (1):
                 0  : dtn://N1.dtn -> dtn://nobody.dtn length 11 (NOT
PENDING)

I then run "bundle info 0".  This time I see the bundle is queued on 2
lists: all_bundles and link-1:deferred.

The bundle will remain in the bundle list until the bundle is transmitted
over link-1.  At that point, it will finally disappear from the bundle list.

Again, is the the intended behavior?  If so is there a way to control which
lists a bundle is "queued on"?  Is anyone else experiencing the same
situation I am?

Thanks in advance for your help/suggestions,

-Nick Fox

On Fri, Oct 30, 2009 at 5:30 PM, Alex McMahon <[email-masked]>wrote:

>  Expiring a bundle would simply remove it from the bundle list immediately
> and delete the bundle.  I believe what you are seeing is one of three
> registrations being deleted and not the expiration of the bundle.  If the
> bundle expires ( you could try manually expiring it with 'bundle expire
> <id>')before all known nodes have been encountered, I expect the bundle
> would disappear from the bundle list and is deleted.
>
>
> Alex
>
> *1) no bundles / default registrations*
> sphere dtn% bundle list
> All Bundles (0):
>
> sphere dtn% registration list
> id 0: active dtn://sphere.dtn (DEFER) [expiration 0]
> id 2: active dtn://sphere.dtn/ping (DEFER) [expiration 0]
>
> sphere dtn% route dump
> Route table for flood router:
>
> destinatio source COS    next hop    fwd    route [custody timeout]
> endpoint i  eid   BNE    link/eid   action   prio [min   pct   max]
>
> -----------------------------------------------------------------------------
>
> Class of Service (COS) bits:
> B: Bulk  N: Normal  E: Expedited
>
> Links:
>
> *2) Two bundles sent with expiration time of 10 seconds to EID that does
> no exist. Bundles 8 & 9 and registrations 14 & 15 are visible  *
>
> *$ dtnping -c 1 -e 10 dtn://blahblah2/ping*
> *source_eid [dtn://sphere.dtn/ping.1747]*
> *dtn_register succeeded, regid 15*
>
>
> *$ dtnping -c 1 -e 10 dtn://blahblah1/ping*
> *source_eid [dtn://sphere.dtn/ping.1745]*
> *dtn_register succeeded, regid 14*
>
>
> sphere dtn% bundle list
> All Bundles (2):
> 8  : dtn://sphere.dtn/ping.1745 -> dtn://blahblah1/ping length 20
> 9  : dtn://sphere.dtn/ping.1747 -> dtn://blahblah2/ping length 20
>
> sphere dtn% registration list
> id 0: active dtn://sphere.dtn (DEFER) [expiration 0]
> id 2: active dtn://sphere.dtn/ping (DEFER) [expiration 0]
> id 14: active dtn://sphere.dtn/ping.1745 (DEFER) [expiration 0]
> id 15: active dtn://sphere.dtn/ping.1747 (DEFER) [expiration 0]
>
> sphere dtn% route dump
> Route table for flood router:
>
> destinatio source COS    next hop    fwd    route [custody timeout]
> endpoint i  eid   BNE    link/eid   action   prio [min   pct   max]
>
> -----------------------------------------------------------------------------
>
> Class of Service (COS) bits:
> B: Bulk  N: Normal  E: Expedited
>
> Links:
>
>
> *3) After 10 seconds as expected the registration expires and bundle
> expires. Registrations 14 & 15 and bundles 8 & 9 are gone from lists. A
> signal is given by the dtnping application for both bundles.  *
>
> *PING [dtn://blahblah1/ping] (expiration 10)...*
> *bundle deleted at [dtn://sphere.dtn] (lifetime expired): seqno=0,
> time=10004 m*
>
> *PING [dtn://blahblah1/ping] (expiration 10)...*
> *bundle deleted at [dtn://sphere.dtn] (lifetime expired): seqno=0,
> time=10002 ms*
>
> sphere dtn% bundle list
> All Bundles (0):
>
> sphere dtn% registration list
> id 0: active dtn://sphere.dtn (DEFER) [expiration 0]
> id 2: active dtn://sphere.dtn/ping (DEFER) [expiration 0]
>
> sphere dtn% route dump
> Route table for flood router:
>
> destinatio source COS    next hop    fwd    route [custody timeout]
> endpoint i  eid   BNE    link/eid   action   prio [min   pct   max]
>
> -----------------------------------------------------------------------------
>
> Class of Service (COS) bits:
> B: Bulk  N: Normal  E: Expedited
>
> Links:
>
>
>
> On Wed, 2009-09-30 at 14:44 -0400, Nick Fox wrote:
>
> I am using DTN2-2.6.0 and flooding routing.  I believe I am experiencing
> some odd behavior with the bundle expire command.
>
> Here is my test scenario:
>
> Nodes N1, N2, N3, and N4 all have entries in each others link lists.  Say
> N1 has a dtnsend command run on it while all links are closed which creates
> bundle B1.  If a bundle info command is run on B1, then it is "queued" of
> the following lists:all_bundles, pending_bundles,
> FloodBundleRouter::all_bundles, link-0:deferred, link-1:deferred, and
> link-2:deferred (link-0=N2, link-1=N3, link-2=N4).  Now if the link opens
> with N3, the bundle is flooded to N3 and a bundle expire command is run on
> the bundle on N1.  Here is the what I see on N1.  Bundle list status = NOT
> PENDING.  Now if bundle info is run on it, it is "queued" on the following
> lists:all_bundles, link-0:deferred, link-2:deferred.  If N1 now opens a link
> with N2 and/or N4, the bundle is still flooded to the node and it is removed
> from the corresponding link:deferred list.  When all known nodes have been
> encountered, then the bundle finally disappears from the bundle list and is
> deleted.  Note: if N1 were to open a link to a "new" node ex. N6, then the
> bundle would be flooded to N6 as well.
>
> I am curious, is this the intended behavior of the bundle expire command? I
> was under the impression that expiring a bundle would simply remove it from
> the bundle list immediately and delete the bundle.  Also, if this is the
> intended behavior for bundle expire, is there a way to manually alter which
> lists a bundle is a part of?
>
> Thanks in advance for your comments/suggestions.
>
> Nick Fox
>
> _______________________________________________
> dtn-users mailing [email-masked]://maillists.intel-research.net/mailman/listinfo/dtn-users
>
>

--00c09ffb4d2fb315a104776509d9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Alex: What you are describing is exactly what I expected to happen, however=
 that is not what I am seeing happen.=A0 Let me attempt to explain again mo=
re clearly.<br><br>I have a node N1 configured with flood routing, route di=
scovery, and the parameter early bundle deletion =3D true (this is true by =
default).=A0 It contains two links in its routing table: link-0 to N2 and l=
ink-1 to N3.=A0 The scenario begins with both links closed.=A0 <br>
<br>With both links closed I send a bundle manually with dtnsend to a node =
that doesn&#39;t exist: &quot;dtnsend -s dtn://N1.dtn -d dtn://nobody.dtn -=
t m -p &quot;hello world&quot;. (the expiration timer is default so 3600 se=
conds)<br>
<br>At this point I run &quot;bundle info 0&quot; and see the bundle is que=
ued on 5 lists: all_bundles, pending_bundles, FloodBundleRouter::all_bundle=
s, link-0:deferred, and link-1:deferred.<br><br>Now I open link-0.=A0 The b=
undle is flooded to node N2. I close link-0 again.=A0 At this point both li=
nks are again unavailable.<br>
<br>I again run &quot;bundle info 0&quot;.=A0 Now i see the bundle is only =
queued on 4 lists: all_bundles, pending_bundles, FloodBundleRouter::all_bun=
dles, and link-1:deferred.=A0 (this is what i expect since we just sent it =
to link-0)<br>
<br>Now the unexpected behavior.=A0 I run &quot;bundle expire 0&quot;.=A0 N=
ow when I run bundle list I see:<br><br>=A0=A0=A0 All Bundles (1):<br>=A0=
=A0=A0 =A0=A0 =A0 =A0  =A0=A0  =A0=A0 0=A0 : dtn://N1.dtn -&gt; dtn://nobod=
y.dtn length 11 (NOT PENDING)<br>
<br>I then run &quot;bundle info 0&quot;.=A0 This time I see the bundle is =
queued on 2 lists: all_bundles and link-1:deferred.<br><br>The bundle will =
remain in the bundle list until the bundle is transmitted over link-1.=A0 A=
t that point, it will finally disappear from the bundle list.<br>
<br>Again, is the the intended behavior?=A0 If so is there a way to control=
 which lists a bundle is &quot;queued on&quot;?=A0 Is anyone else experienc=
ing the same situation I am?<br><br>Thanks in advance for your help/suggest=
ions,<br>
<br>-Nick Fox<br><br><br><br><div class=3D"gmail_quote">On Fri, Oct 30, 200=
9 at 5:30 PM, Alex McMahon <span dir=3D"ltr">&lt;<a href=3D"mailto:alex.mcm=
[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</span> wro=
te:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

 =20
 =20

<div>
Expiring a bundle would simply remove it from the bundle list immediately a=
nd delete the bundle.=A0 I believe what you are seeing is one of three regi=
strations being deleted and not the expiration of the bundle.=A0 If the bun=
dle expires ( you could try manually expiring it with &#39;bundle expire &l=
t;id&gt;&#39;)before all known nodes have been encountered, I expect the bu=
ndle would disappear from the bundle list and is deleted.=A0 <br>

<br>
<br>
Alex<br>
<br>
<b>1) no bundles / default registrations</b><br>
sphere dtn% bundle list<br>
All Bundles (0): <br>
<br>
sphere dtn% registration list<br>
id 0: active dtn://sphere.dtn (DEFER) [expiration 0]<br>
id 2: active dtn://sphere.dtn/ping (DEFER) [expiration 0]<br>
<br>
sphere dtn% route dump<br>
Route table for flood router:<br>
<br>
destinatio source COS=A0=A0=A0 next hop=A0=A0=A0 fwd=A0=A0=A0 route [custod=
y timeout]<br>
endpoint i=A0 eid=A0=A0 BNE=A0=A0=A0 link/eid=A0=A0 action=A0=A0 prio [min=
=A0=A0 pct=A0=A0 max]<br>
---------------------------------------------------------------------------=
--<br>
<br>
Class of Service (COS) bits:<br>
	B: Bulk=A0 N: Normal=A0 E: Expedited<br>
<br>
Links:<br>
<br>
<b>2) Two bundles sent with expiration time of 10 seconds to EID that does =
no exist. Bundles 8 &amp; 9 and registrations 14 &amp; 15 are visible=A0 </=
b><br>
<br>
<b>$ dtnping -c 1 -e 10 dtn://blahblah2/ping</b><br>
<b>source_eid [dtn://sphere.dtn/ping.1747]</b><br>
<b>dtn_register succeeded, regid 15</b><br>
<br>
<br>
<b>$ dtnping -c 1 -e 10 dtn://blahblah1/ping</b><br>
<b>source_eid [dtn://sphere.dtn/ping.1745]</b><br>
<b>dtn_register succeeded, regid 14</b><br>
<br>
<br>
sphere dtn% bundle list<br>
All Bundles (2): <br>
	8=A0 : dtn://sphere.dtn/ping.1745 -&gt; dtn://blahblah1/ping length 20<br>
	9=A0 : dtn://sphere.dtn/ping.1747 -&gt; dtn://blahblah2/ping length 20<br>
<br>
sphere dtn% registration list<br>
id 0: active dtn://sphere.dtn (DEFER) [expiration 0]<br>
id 2: active dtn://sphere.dtn/ping (DEFER) [expiration 0]<br>
id 14: active dtn://sphere.dtn/ping.1745 (DEFER) [expiration 0]<br>
id 15: active dtn://sphere.dtn/ping.1747 (DEFER) [expiration 0]<br>
<br>
sphere dtn% route dump<br>
Route table for flood router:<br>
<br>
destinatio source COS=A0=A0=A0 next hop=A0=A0=A0 fwd=A0=A0=A0 route [custod=
y timeout]<br>
endpoint i=A0 eid=A0=A0 BNE=A0=A0=A0 link/eid=A0=A0 action=A0=A0 prio [min=
=A0=A0 pct=A0=A0 max]<br>
---------------------------------------------------------------------------=
--<br>
<br>
Class of Service (COS) bits:<br>
	B: Bulk=A0 N: Normal=A0 E: Expedited<br>
<br>
Links:<br>
<br>
<br>
<b>3) After 10 seconds as expected the registration expires and bundle expi=
res. Registrations 14 &amp; 15 and bundles 8 &amp; 9 are gone from lists. A=
 signal is given by the dtnping application for both bundles.=A0 </b><br>

<br>
<b>PING [dtn://blahblah1/ping] (expiration 10)...</b><br>
<b>bundle deleted at [dtn://sphere.dtn] (lifetime expired): seqno=3D0, time=
=3D10004 m</b><br>
<br>
<b>PING [dtn://blahblah1/ping] (expiration 10)...</b><br>
<b>bundle deleted at [dtn://sphere.dtn] (lifetime expired): seqno=3D0, time=
=3D10002 ms</b><br>
<br>
sphere dtn% bundle list<br>
All Bundles (0): <br>
<br>
sphere dtn% registration list<br>
id 0: active dtn://sphere.dtn (DEFER) [expiration 0]<br>
id 2: active dtn://sphere.dtn/ping (DEFER) [expiration 0]<br>
<br>
sphere dtn% route dump<br>
Route table for flood router:<br>
<br>
destinatio source COS=A0=A0=A0 next hop=A0=A0=A0 fwd=A0=A0=A0 route [custod=
y timeout]<br>
endpoint i=A0 eid=A0=A0 BNE=A0=A0=A0 link/eid=A0=A0 action=A0=A0 prio [min=
=A0=A0 pct=A0=A0 max]<br>
---------------------------------------------------------------------------=
--<br>
<br>
Class of Service (COS) bits:<br>
	B: Bulk=A0 N: Normal=A0 E: Expedited<br>
<br>
Links:<br>
<br>
<br>
<br>
On Wed, 2009-09-30 at 14:44 -0400, Nick Fox wrote:<br>
<blockquote type=3D"CITE">
    I am using DTN2-2.6.0 and flooding routing.=A0 I believe I am experienc=
ing some odd behavior with the bundle expire command.<br>
    <br>
    Here is my test scenario:<br>
    <br>
    Nodes N1, N2, N3, and N4 all have entries in each others link lists.=A0=
 Say N1 has a dtnsend command run on it while all links are closed which cr=
eates bundle B1.=A0 If a bundle info command is run on B1, then it is &quot=
;queued&quot; of the following lists:all_bundles, pending_bundles, FloodBun=
dleRouter::all_bundles, link-0:deferred, link-1:deferred, and link-2:deferr=
ed (link-0=3DN2, link-1=3DN3, link-2=3DN4).=A0 Now if the link opens with N=
3, the bundle is flooded to N3 and a bundle expire command is run on the bu=
ndle on N1.=A0 Here is the what I see on N1.=A0 Bundle list status =3D NOT =
PENDING.=A0 Now if bundle info is run on it, it is &quot;queued&quot; on th=
e following lists:all_bundles, link-0:deferred, link-2:deferred.=A0 If N1 n=
ow opens a link with N2 and/or N4, the bundle is still flooded to the node =
and it is removed from the corresponding link:deferred list.=A0 When all kn=
own nodes have been encountered, then the bundle finally disappears from th=
e bundle list and is deleted.=A0 Note: if N1 were to open a link to a &quot=
;new&quot; node ex. N6, then the bundle would be flooded to N6 as well.<br>

    <br>
    I am curious, is this the intended behavior of the bundle expire comman=
d? I was under the impression that expiring a bundle would simply remove it=
 from the bundle list immediately and delete the bundle.=A0 Also, if this i=
s the intended behavior for bundle expire, is there a way to manually alter=
 which lists a bundle is a part of?=A0 <br>

    <br>
    Thanks in advance for your comments/suggestions.<br>
    <br>
    Nick Fox
<pre>_______________________________________________
dtn-users mailing list
<a href=3D"mailto:[email-masked]" target=3D"_blank"=
>[email-masked]</a>
<a href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-users" =
target=3D"_blank">http://maillists.intel-research.net/mailman/listinfo/dtn-=
users</a>
</pre>
</blockquote>
</div>

</blockquote></div><br>

--00c09ffb4d2fb315a104776509d9--