Received: from mail80.messagelabs.com (mail80.messagelabs.com [195.245.230.163]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nAKDpR4l011591 for ; Fri, 20 Nov 2009 05:51:27 -0800 X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-12.tower-80.messagelabs.com!1258725086!35372240!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.31] Received: (qmail 30288 invoked from network); 20 Nov 2009 13:51:27 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-12.tower-80.messagelabs.com with AES128-SHA encrypted SMTP; 20 Nov 2009 13:51:27 -0000 Received: from [192.168.1.209] (131.227.200.4) by EXHT011P.surrey.ac.uk (131.227.200.31) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 20 Nov 2009 13:51:26 +0000 MIME-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset="us-ascii" From: Lloyd Wood In-Reply-To: <4B06968E.9030204@cs.tcd.ie> Date: Fri, 20 Nov 2009 13:51:25 +0000 Content-Transfer-Encoding: 7bit Message-ID: <5E208BEC-A3E1-4B31-AC5C-8D03B2E7FBA7@surrey.ac.uk> References: <4B053BD1.1040306@cs.tcd.ie> <3A5AA67A8B120B48825BFFCF54438561945EA7EAB3@NDJSSCC03.ndc.nasa.gov> <4B06968E.9030204@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1077) Cc: "Burleigh, Scott C. \(JPL-313B\)\[Caltech-JPL\]" , dtn-users mailing list , Lloyd Wood Subject: Re: [dtn-users] DTN2 & LTPlib X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 13:51:28 -0000 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/ Received: from TX2EHSOBE010.bigfish.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nAKDFxTu009960 for ; Fri, 20 Nov 2009 05:15:59 -0800 Received: from mail123-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 8.1.340.0; Fri, 20 Nov 2009 13:16:00 +0000 Received: from mail123-tx2 (localhost.localdomain [127.0.0.1]) by mail123-tx2-R.bigfish.com (Postfix) with ESMTP id 8FF0D14A04CE; Fri, 20 Nov 2009 13:15:59 +0000 (UTC) X-SpamScore: -16 X-BigFish: VPS-16(zz1432R98dNzz1202hzzz2dh6bh87h31eh62h) X-Spam-TCS-SCL: 1:0 X-FB-DOMAIN-IP-MATCH: fail Received: from mail123-tx2 (localhost.localdomain [127.0.0.1]) by mail123-tx2 (MessageSwitch) id 1258722955786340_32733; Fri, 20 Nov 2009 13:15:55 +0000 (UTC) Received: from TX2EHSMHS033.bigfish.com (unknown [10.9.14.245]) by mail123-tx2.bigfish.com (Postfix) with ESMTP id B9587137004D; Fri, 20 Nov 2009 13:15:55 +0000 (UTC) Received: from imx2.tcd.ie (134.226.1.156) by TX2EHSMHS033.bigfish.com (10.9.99.133) with Microsoft SMTP Server id 14.0.482.32; Fri, 20 Nov 2009 13:15:54 +0000 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 57AAF68009; Fri, 20 Nov 2009 13:15:53 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A0379653F23; Fri, 20 Nov 2009 13:15:53 +0000 Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id 46DA868009; Fri, 20 Nov 2009 13:15:53 +0000 (GMT) Message-ID: <4B06968E.9030204@cs.tcd.ie> Date: Fri, 20 Nov 2009 13:15:58 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: "Ivancic, William D. (GRC-RHN0)" References: <4B053BD1.1040306@cs.tcd.ie> <3A5AA67A8B120B48825BFFCF54438561945EA7EAB3@NDJSSCC03.ndc.nasa.gov> In-Reply-To: <3A5AA67A8B120B48825BFFCF54438561945EA7EAB3@NDJSSCC03.ndc.nasa.gov> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A1379653F23 X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.113.23) X-Reverse-DNS: imx2.tcd.ie Cc: dtn-users mailing list , "Burleigh, Scott C. \(JPL-313B\)\[Caltech-JPL\]" Subject: Re: [dtn-users] DTN2 & LTPlib X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 13:16:00 -0000 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. Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nAKD5TZX009496 for ; Fri, 20 Nov 2009 05:05:30 -0800 Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 9A87C108022; Fri, 20 Nov 2009 07:05:28 -0600 (CST) Received: from ndjshub03.ndc.nasa.gov (ndjshub03.ndc.nasa.gov [198.117.4.162]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id nAKD5T2B032714; Fri, 20 Nov 2009 07:05:29 -0600 Received: from NDJSSCC03.ndc.nasa.gov ([198.117.4.170]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Fri, 20 Nov 2009 07:05:29 -0600 From: "Ivancic, William D. (GRC-RHN0)" To: "Burleigh, Scott C. (JPL-313B)[Caltech-JPL]" , Stephen Farrell , dtn-users mailing list Date: Fri, 20 Nov 2009 07:04:56 -0600 Thread-Topic: [dtn-users] DTN2 & LTPlib Thread-Index: AcppFY+TqPxP4C44S8+tLoaUFgrArAAK1I6QACgllzA= Message-ID: <3A5AA67A8B120B48825BFFCF54438561945EA7EAB3@NDJSSCC03.ndc.nasa.gov> References: <4B053BD1.1040306@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-11-20_09:2009-11-16, 2009-11-20, 2009-11-20 signatures=0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id nAKD5TZX009496 Subject: Re: [dtn-users] DTN2 & LTPlib X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 13:05:31 -0000 > >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 > Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.106]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nAJI94de023687 for ; Thu, 19 Nov 2009 10:09:05 -0800 Received: from mail.jpl.nasa.gov (altvirehtstap01.jpl.nasa.gov [128.149.137.72]) by smtp.jpl.nasa.gov (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAJI91q4024085 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified FAIL); Thu, 19 Nov 2009 10:09:02 -0800 Received: from ALTPHYEMBEVSP10.RES.AD.JPL ([128.149.137.80]) by ALTVIREHTSTAP01.RES.AD.JPL ([128.149.137.72]) with mapi; Thu, 19 Nov 2009 10:09:01 -0800 From: "Burleigh, Scott C (313B)" To: Stephen Farrell , dtn-users mailing list Date: Thu, 19 Nov 2009 10:08:50 -0800 Thread-Topic: [dtn-users] DTN2 & LTPlib Thread-Index: AcppFY+TqPxP4C44S8+tLoaUFgrArAAK1I6Q Message-ID: References: <4B053BD1.1040306@cs.tcd.ie> In-Reply-To: <4B053BD1.1040306@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id nAJI94de023687 Subject: Re: [dtn-users] DTN2 & LTPlib X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 18:09:05 -0000 > -----Original Message----- > From: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users- > bounces@maillists.intel-research.net] 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 Received: from TX2EHSOBE010.bigfish.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nAJCac4m008855 for ; Thu, 19 Nov 2009 04:36:38 -0800 Received: from mail84-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 8.1.340.0; Thu, 19 Nov 2009 12:36:39 +0000 Received: from mail84-tx2 (localhost.localdomain [127.0.0.1]) by mail84-tx2-R.bigfish.com (Postfix) with ESMTP id D3C8CB20832 for ; Thu, 19 Nov 2009 12:36:38 +0000 (UTC) X-SpamScore: -16 X-BigFish: VPS-16(zz14ffO936eM4015Lzz1202hzzz2dh87h6bh62h) X-Spam-TCS-SCL: 1:0 X-FB-DOMAIN-IP-MATCH: fail Received: from mail84-tx2 (localhost.localdomain [127.0.0.1]) by mail84-tx2 (MessageSwitch) id 1258634196235403_23753; Thu, 19 Nov 2009 12:36:36 +0000 (UTC) Received: from TX2EHSMHS014.bigfish.com (unknown [10.9.14.252]) by mail84-tx2.bigfish.com (Postfix) with ESMTP id 461EBF0050 for ; Thu, 19 Nov 2009 12:36:35 +0000 (UTC) Received: from imx2.tcd.ie (134.226.1.156) by TX2EHSMHS014.bigfish.com (10.9.99.114) with Microsoft SMTP Server id 14.0.482.32; Thu, 19 Nov 2009 12:36:31 +0000 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 095846803C for ; Thu, 19 Nov 2009 12:36:31 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A0225F037E0; Thu, 19 Nov 2009 12:36:31 +0000 Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id CF3586803C for ; Thu, 19 Nov 2009 12:36:30 +0000 (GMT) Message-ID: <4B053BD1.1040306@cs.tcd.ie> Date: Thu, 19 Nov 2009 12:36:33 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: dtn-users mailing list X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A1225F037E0 X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.113.22) X-Reverse-DNS: imx2.tcd.ie Subject: [dtn-users] DTN2 & LTPlib X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 12:36:38 -0000 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/ Received: from a.painless.aaisp.net.uk (a.painless.aaisp.net.uk [81.187.30.51] (may be forged)) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nA6GKUwp031494 for ; Fri, 6 Nov 2009 08:20:31 -0800 Received: from 153.107.2.81.in-addr.arpa ([81.2.107.153] helo=[81.187.254.251]) by a.painless.aaisp.net.uk with esmtp (Exim 4.69) (envelope-from ) id 1N6RY9-0005No-Qk; Fri, 06 Nov 2009 16:20:34 +0000 Message-ID: <4AF44CD0.6080805@folly.org.uk> Date: Fri, 06 Nov 2009 16:20:32 +0000 From: Elwyn Davies User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: dtn-users@mailman.dtnrg.org Content-Type: multipart/mixed; boundary="------------060802000506050009080403" Subject: [dtn-users] [Fwd: Re: [dtn-interest] Help in compiling Python API for DTN] X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 16:20:32 -0000 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: <4AF44BDD.5020808@folly.org.uk> Date: Fri, 06 Nov 2009 16:16:29 +0000 From: Elwyn Davies User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: Abdullah Azfar CC: dtn-interest@maillists.intel-research.net Subject: Re: [dtn-interest] Help in compiling Python API for DTN References: <70290.31752.qm@web36201.mail.mud.yahoo.com> In-Reply-To: <70290.31752.qm@web36201.mail.mud.yahoo.com> 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 > dtn-interest@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-interest > --------------060802000506050009080403-- Received: from mail-pw0-f55.google.com (mail-pw0-f55.google.com [209.85.160.55]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nA2MrvvL030999; Mon, 2 Nov 2009 14:53:57 -0800 Received: by pwi18 with SMTP id 18so2196314pwi.34 for ; Mon, 02 Nov 2009 14:53:58 -0800 (PST) Received: by 10.114.237.18 with SMTP id k18mr9692891wah.63.1257202438253; Mon, 02 Nov 2009 14:53:58 -0800 (PST) Received: from ?10.212.112.68? (bldmz-nat-161-164.berkeley.intel-research.net [12.155.161.164]) by mx.google.com with ESMTPS id 21sm1669907pzk.3.2009.11.02.14.53.55 (version=SSLv3 cipher=RC4-MD5); Mon, 02 Nov 2009 14:53:56 -0800 (PST) Sender: Alex McMahon From: Alex McMahon To: Nick Fox In-Reply-To: <327e92bc0911020729q15c6c3a0m7396db18feef1a65@mail.gmail.com> References: <327e92bc0909301144r2ff99c35u5dd0444391a99044@mail.gmail.com> <1256941814.1375.3014.camel@sphere> <327e92bc0911020729q15c6c3a0m7396db18feef1a65@mail.gmail.com> Content-Type: multipart/alternative; boundary="=-kgzuzH0CEPIEn8btbfpN" Organization: Trinity College Dublin Date: Mon, 02 Nov 2009 14:53:53 -0800 Message-Id: <1257202433.3945.438.camel@sphere> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Cc: dtn-users@maillists.intel-research.net, dtn-interest@maillists.intel-research.net Subject: Re: [dtn-users] bundle expire malfunction?? X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: alex.mcmahon@cs.tcd.ie List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 22:53:58 -0000 --=-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 > 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 ')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 > > dtn-users@maillists.intel-research.net > > http://maillists.intel-research.net/mailman/listinfo/dtn-users > > --=-kgzuzH0CEPIEn8btbfpN Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Nick,

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.  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 "queued on" using the tcl in= terface.  

I was only able to recreate this bug using routing type flood when the bund= le is defered and expires.  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 -> dtn://nobody1.dtn 11 byte payload] still has 3 mappings (i.e. n= ot just in ALL_BUNDLES)'

The code which expires the bundle  from 'BundleDaemon.cc' is shown bel= ow. 

2114     if (event->type_ =3D=
=3D BUNDLE_EXPIRED) {

2115         bundle =3D ((Bundle=
ExpiredEvent*)event)->bundleref_.object();

2116         size_t num_mappings=
 =3D bundle->num_mappings();

2117         if (num_mappings !=
=3D 1) {

2118             log_warn("=
expired bundle *%p still has %zu mappings (i.e. not just in ALL_BUNDLES)&qu=
ot;,

2119                      bundle=
.object(), num_mappings);


)

The reason seems to be that in the implementation of flood routing the clas= s maintains an internal BundleList 'all_bundles_', a separate list,  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


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, how= ever that is not what I am seeing happen.  Let me attempt to explain a= gain more clearly.

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). = 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 second= s)

At this point I run "bundle info 0" 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.

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 on= ly queued on 4 lists: all_bundles, pending_bundles, FloodBundleRouter::all_= bundles, and link-1:deferred.  (this is what i expect since we just se= nt it to link-0)

Now the unexpected behavior.  I run "bundle expire 0".&n= bsp; 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 transmitt= ed over link-1.  At that point, it will finally disappear from the bun= dle list.

Again, is the the intended behavior?  If so is there a way to cont= rol which lists a bundle is "queued on"?  Is anyone else exp= eriencing 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 <alex.mcmahon@cs.tcd.ie> wrote:
Expiring a bundle would simply remove it from the bundle list immed= iately and delete the bundle.  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 <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&nbs= p;  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 th= at does no exist. Bundles 8 & 9 and registrations 14 & 15 are visib= le 

$ 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 len= gth 20
9  : dtn://sphere.dtn/ping.1747 -> dtn://blahblah2/ping len= gth 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&nbs= p;  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 bun= dle 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= =3D0, time=3D10004 m

PING [dtn://blahblah1/ping] (expiration 10)...
bundle deleted at [dtn://sphere.dtn] (lifetime expired): seqno= =3D0, time=3D10002 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&nbs= p;  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 a= m 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 l= ists.  Say N1 has a dtnsend command run on it while all links are clos= ed which creates bundle B1.  If a bundle info command is run on B1, th= en it is "queued" 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).  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.  Bund= le list status =3D NOT PENDING.  Now if bundle info is run on it, it i= s "queued" on the following lists:all_bundles, link-0:deferred, l= ink-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 b= undle finally disappears from the bundle list and is deleted.  Note: i= f 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 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.  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? 

Thanks in advance for your comments/suggestions.

Nick Fox=20 
_______________________________________________
dtn-users mailing list
dtn-users@maillis=
ts.intel-research.net
=
http://maillists.intel-research.net/mailman/listinfo/dtn-users

--=-kgzuzH0CEPIEn8btbfpN-- Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nA2FT5wd004001; Mon, 2 Nov 2009 07:29:06 -0800 Received: by fg-out-1718.google.com with SMTP id e12so84098fga.16 for ; Mon, 02 Nov 2009 07:29:05 -0800 (PST) MIME-Version: 1.0 Sender: foxnf288@gmail.com Received: by 10.86.13.37 with SMTP id 37mr2294317fgm.58.1257175744975; Mon, 02 Nov 2009 07:29:04 -0800 (PST) In-Reply-To: <1256941814.1375.3014.camel@sphere> References: <327e92bc0909301144r2ff99c35u5dd0444391a99044@mail.gmail.com> <1256941814.1375.3014.camel@sphere> Date: Mon, 2 Nov 2009 10:29:04 -0500 X-Google-Sender-Auth: cf3660be67a43f11 Message-ID: <327e92bc0911020729q15c6c3a0m7396db18feef1a65@mail.gmail.com> From: Nick Fox To: alex.mcmahon@cs.tcd.ie Content-Type: multipart/alternative; boundary=00c09ffb4d2fb315a104776509d9 Cc: dtn-users@maillists.intel-research.net, dtn-interest@maillists.intel-research.net Subject: Re: [dtn-users] bundle expire malfunction?? X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 15:29:07 -0000 --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 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 > ')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 listdtn-users@maillists.intel-research.nethttp://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.

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

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 se= conds)

At this point I run "bundle info 0" 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.

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.

I again run "bundle info 0".=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)

Now the unexpected behavior.=A0 I run "bundle expire 0".=A0 N= ow when I run bundle list I see:

=A0=A0=A0 All Bundles (1):
=A0= =A0=A0 =A0=A0 =A0 =A0 =A0=A0 =A0=A0 0=A0 : dtn://N1.dtn -> dtn://nobod= y.dtn length 11 (NOT PENDING)

I then run "bundle info 0".=A0 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.=A0 A= t that point, it will finally disappear from the bundle list.

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

Thanks in advance for your help/suggest= ions,

-Nick Fox



On Fri, Oct 30, 200= 9 at 5:30 PM, Alex McMahon <alex.mcmahon@cs.tcd.ie> wro= te:
=20 =20
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 'bundle expire &l= t;id>')before all known nodes have been encountered, I expect the bu= ndle would disappear from the bundle list and is deleted.=A0


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=A0=A0=A0 next hop=A0=A0=A0 fwd=A0=A0=A0 route [custod= y timeout]
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]
---------------------------------------------------------------------------= --

Class of Service (COS) bits:
B: Bulk=A0 N: Normal=A0 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=A0

$ 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=A0 : dtn://sphere.dtn/ping.1745 -> dtn://blahblah1/ping length 20
9=A0 : 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=A0=A0=A0 next hop=A0=A0=A0 fwd=A0=A0=A0 route [custod= y timeout]
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]
---------------------------------------------------------------------------= --

Class of Service (COS) bits:
B: Bulk=A0 N: Normal=A0 E: Expedited

Links:


3) After 10 seconds as expected the registration expires and bundle expi= res. Registrations 14 & 15 and bundles 8 & 9 are gone from lists. A= signal is given by the dtnping application for both bundles.=A0

PING [dtn://blahblah1/ping] (expiration 10)...
bundle deleted at [dtn://sphere.dtn] (lifetime expired): seqno=3D0, time= =3D10004 m

PING [dtn://blahblah1/ping] (expiration 10)...
bundle deleted at [dtn://sphere.dtn] (lifetime expired): seqno=3D0, time= =3D10002 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=A0=A0=A0 next hop=A0=A0=A0 fwd=A0=A0=A0 route [custod= y timeout]
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]
---------------------------------------------------------------------------= --

Class of Service (COS) bits:
B: Bulk=A0 N: Normal=A0 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.=A0 I believe I am experienc= ing 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.=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 "= ;queued" 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 "queued" 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 "= ;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 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

Thanks in advance for your comments/suggestions.

Nick Fox 
_______________________________________________
dtn-users mailing list
dtn-users@maillists.intel-research.net
http://maillists.intel-research.net/mailman/listinfo/dtn-=
users

--00c09ffb4d2fb315a104776509d9--