From elwynd@folly.org.uk Wed Jan 2 08:26:17 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71BFA21F8644 for ; Wed, 2 Jan 2013 08:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMKy5CRVYuYk for ; Wed, 2 Jan 2013 08:26:17 -0800 (PST) Received: from b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) by ietfa.amsl.com (Postfix) with ESMTP id EA87921F85EA for ; Wed, 2 Jan 2013 08:26:16 -0800 (PST) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by b.painless.aa.net.uk with esmtp (Exim 4.72) (envelope-from ) id 1TqR8v-00048R-PG; Wed, 02 Jan 2013 16:26:14 +0000 From: Elwyn Davies To: Angela Hennessy Content-Type: text/plain Organization: Folly Consulting Date: Wed, 02 Jan 2013 16:25:14 +0000 Message-Id: <1357143914.11916.16780.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Cc: DTN Users Subject: [dtn-users] IPND in DTN2 X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 16:26:17 -0000 Hi, Angela I just enabled the new IPND capability in DTN2. I have now realized that this is currently setup as an either/or with the pre-existing IP discovery. I discovered this when my existing configuration file barfed on the old style 'add discovery' command. Looking at the code and compilation setup, it appears that the two types of discovery could co-exist in the daemon provided the two mechanisms have separate 'afname' parameters. At present they share the 'ip' name - would it be possible to use a different afname for your new code ('ip2' or 'ipnd' perhaps) so that both types of discovery can be used with a single daemon. In practice, at present, the code for both types of discovery is compiled whether IPND is enabled or not - only the selection of class to initialize and some minor variations to the help text are changed by selecting --with-ipnd - so the overhead of allowing both types of discovery to be used is minimal. [It would probably be better from an efficiency point of view if the IPND code was not compiled if the --with-ipnd options is not selected.] Regards, Elwyn From elwynd@folly.org.uk Wed Jan 2 15:37:17 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3349421F8840 for ; Wed, 2 Jan 2013 15:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.842 X-Spam-Level: X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEBC0LriEEvc for ; Wed, 2 Jan 2013 15:37:12 -0800 (PST) Received: from a.painless.aa.net.uk (a.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e33]) by ietfa.amsl.com (Postfix) with ESMTP id 427FB21F882C for ; Wed, 2 Jan 2013 15:37:05 -0800 (PST) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by a.painless.aa.net.uk with esmtp (Exim 4.77) (envelope-from ) id 1TqXrr-0002bI-43 for dtn-users@irtf.org; Wed, 02 Jan 2013 23:37:03 +0000 From: Elwyn Davies To: DTN Users Content-Type: text/plain Organization: Folly Consulting Date: Wed, 02 Jan 2013 23:36:02 +0000 Message-Id: <1357169763.11916.16791.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Subject: [dtn-users] Metadata blocks in DTN2 X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 23:37:17 -0000 Hi. Has anybody out there tried to use the API to add metadata blocks to a bundle? I have just been trying and have discovered that the code is what we round this part of the woods describe as a bit of a pig's breakfast. In particular, the APIServer.cc code corrupts the internal state when the block arrives across the API by copying the Bundle Protocol block type into the ontology field so that the generated internal data block is different from the one you sent across the wire. It also appears that the metadata block structure as implemented in the code doesn't match the structure in RFC 6258. I need to fix this as I want to use a metadata block. Is it going to screw anybody else up if I change the code to match the specification? Please let me know asap. Best wishes for a Happy New Year. Elwyn From kscott@mitre.org Thu Jan 3 05:03:46 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C20521F8BCD for ; Thu, 3 Jan 2013 05:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrfhZElRGOW6 for ; Thu, 3 Jan 2013 05:03:45 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD4621F892F for ; Thu, 3 Jan 2013 05:03:44 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B5D651F209D; Thu, 3 Jan 2013 08:03:40 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id ACF9F1F2096; Thu, 3 Jan 2013 08:03:40 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0318.004; Thu, 3 Jan 2013 08:03:40 -0500 From: "Scott, Keith L." To: Elwyn Davies , DTN Users Thread-Topic: [dtn-users] Metadata blocks in DTN2 Thread-Index: AQHN6UIbhFxNg/Pe0EerBXUOPbeGUJg3kueQ Date: Thu, 3 Jan 2013 13:03:39 +0000 Message-ID: <5EE81C5C4CFFF4418C5EAD12F49D64EE068432D1@IMCMBX01.MITRE.ORG> References: <1357169763.11916.16791.camel@mightyatom> In-Reply-To: <1357169763.11916.16791.camel@mightyatom> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dtn-users] Metadata blocks in DTN2 X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 13:03:46 -0000 Won't mess us up, but thanks for volunteering! --keith -----Original Message----- From: dtn-users-bounces@irtf.org [mailto:dtn-users-bounces@irtf.org] On Beh= alf Of Elwyn Davies Sent: Wednesday, January 02, 2013 6:36 PM To: DTN Users Subject: [dtn-users] Metadata blocks in DTN2 Hi. Has anybody out there tried to use the API to add metadata blocks to a bundle? I have just been trying and have discovered that the code is what we round this part of the woods describe as a bit of a pig's breakfast. In particular, the APIServer.cc code corrupts the internal state when the block arrives across the API by copying the Bundle Protocol block type into the ontology field so that the generated internal data block is different from the one you sent across the wire. =20 It also appears that the metadata block structure as implemented in the code doesn't match the structure in RFC 6258. I need to fix this as I want to use a metadata block. Is it going to screw anybody else up if I change the code to match the specification? Please let me know asap. Best wishes for a Happy New Year. Elwyn _______________________________________________ dtn-users mailing list dtn-users@irtf.org https://www.irtf.org/mailman/listinfo/dtn-users From elwynd@folly.org.uk Sat Jan 12 14:39:58 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647CB21F88ED for ; Sat, 12 Jan 2013 14:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyitlqmTVM14 for ; Sat, 12 Jan 2013 14:39:57 -0800 (PST) Received: from a.painless.aa.net.uk (a.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e33]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA8B21F8923 for ; Sat, 12 Jan 2013 14:39:57 -0800 (PST) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by a.painless.aa.net.uk with esmtp (Exim 4.77) (envelope-from ) id 1Tu9k2-0007y1-HO; Sat, 12 Jan 2013 22:39:54 +0000 From: Elwyn Davies To: Brian Adamson Content-Type: text/plain Organization: Folly Consulting Date: Sat, 12 Jan 2013 22:38:32 +0000 Message-Id: <1358030312.28723.4339.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Cc: DTN Users Subject: [dtn-users] DTN2 NORM convergence layer X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 22:39:58 -0000 Hi, Brian. Sergey Reskin and I have been trying to get the NORM convergence layer working in DTN2. I get the impression that the NORM code has moved along a bit since there was much activity with NORM and DTN2 with the result that it appears the latest daily snapshot compiles and links OK with DTN2 but doesn't run. Crashes when trying to send a bundle for transmission. I took a snapshot of the version 1.4b4 code about 2 years ago - the README.TXT is dated March 13 2009 and the TODO.TXT April 12 2010. This version appears to be nearly compabible with DTN2 - it runs after I added case statements for NORM_TX_RATE_CHANGED to NORMReceiver.cc and NORMSessionManager.cc event case statements. Would it be possible to: 1. Put a snapshot of the code that will work on the navy.mil downlaod site. 2. Let us know what has been changed and/or provide some patches that will allow the most recent code to be used with DTN2. Regards, Elwyn Davies Folly Consulting/ Trinity College Dublin From elwynd@folly.org.uk Tue Jan 15 03:40:38 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D3621F87F7; Tue, 15 Jan 2013 03:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.493 X-Spam-Level: X-Spam-Status: No, score=-1.493 tagged_above=-999 required=5 tests=[AWL=1.106, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chltQ-Bw1UDQ; Tue, 15 Jan 2013 03:40:37 -0800 (PST) Received: from a.painless.aa.net.uk (a.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e33]) by ietfa.amsl.com (Postfix) with ESMTP id 3131221F84DA; Tue, 15 Jan 2013 03:40:37 -0800 (PST) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by a.painless.aa.net.uk with esmtp (Exim 4.77) (envelope-from ) id 1Tv4sc-0006TY-LK; Tue, 15 Jan 2013 11:40:34 +0000 From: Elwyn Davies To: DTN Users Content-Type: text/plain Organization: Folly Consulting Date: Tue, 15 Jan 2013 11:39:06 +0000 Message-Id: <1358249946.28723.8372.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Cc: DTN interest , Joerg Ott Subject: [dtn-users] Last call of TCP CL draft: Proposal to add reason for refusal to BUNDLE_REFUSE message X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 11:40:38 -0000 Hi. On reviewing the TCP Convergence Layer draft, it occurred to me that in order for both bundle sender and receiver to determine the consequences of a REFUSE_BUNDLE message, the message should have a reason for the refusal associated with the message. Section 3 of the draft currently says: > Another optional feature is that a receiver may interrupt the > transmission of a bundle at any point in time by replying with a > REFUSE_BUNDLE message which causes the sender to stop transmission of > the current bundle, after completing transmission of a partially sent > data segment. Note: This enables a cross-layer optimization in that > it allows a receiver that detects that it already has received a > certain bundle to interrupt transmission as early as possible and > thus save transmission capacity for other bundles. In order to actually save transmission capacity, the sender needs to understand why the receiver wants to cancel the transmission, and needs to act differently depending on what the reason was. There seem to be three cases: 1. The receiver already has all of the bundle (fragment) or what has been received so far completes the bundle (fragment) because the receiver already had fragment(s) that can be combined with what has just been received. - The sender need not try to send the bundle (fragment) again. 2. The receiver can store what it has already received but cannot take any more for the moment. - The sender and receiver can do reactive fragmentation and the sender can try to send the remaining fragment later. 3. The receiver either has no (more) resources to store the bundle or resources that it thought it had have been preempted (e.g., by a higher priority bundle on another link) during reception, and needs to discard what has already been received, if anything. - The receiver should retry sending the whole bundle later. If the sender isn't told the reason explicitly then it will have to assume one of the cases. This would probably be case 1 if we assume that the 'note' in the current version of the draft is the primary intention of the REFUSE_BUNDLE message. This means that the receiver has no way to request a retransmission other than a peremptory shutdown of the link which may not be a very efficient way of handling temporary resource shortage. Suggestion: The flags in the REFUSE_BUNDLE message (currently unused) are used to encode the three cases above. This is backwards compatible assuming that standard IP prectice of ignoring unused flags has been adopted. Question to implementors: DTN2 does not currently implement REFUSE_BUNDLE: It never sends REFUSE_BUNDLE messages and treats a received REFUSE_BUNDLE as a protocol error, breaking contact immediately. So.. do any other bundle protocol implementations actually implement REFUSE_BUNDLE? From brian.adamson@nrl.navy.mil Sat Jan 12 15:40:43 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D35921F8942 for ; Sat, 12 Jan 2013 15:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zd+7-N6RZgoT for ; Sat, 12 Jan 2013 15:40:42 -0800 (PST) Received: from mail4.nrl.navy.mil (mail4.nrl.navy.mil [IPv6:2001:480:20:421::587:27]) by ietfa.amsl.com (Postfix) with ESMTP id 8232421F893E for ; Sat, 12 Jan 2013 15:40:41 -0800 (PST) Received: from [10.138.113.29] (mobile-032-170-187-161.mycingular.net [32.170.187.161] (may be forged)) (authenticated bits=0) by mail4.nrl.navy.mil (8.14.5/8.14.5) with ESMTP id r0CNeOs7006755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 12 Jan 2013 18:40:27 -0500 References: <1358030312.28723.4339.camel@mightyatom> Mime-Version: 1.0 (1.0) In-Reply-To: <1358030312.28723.4339.camel@mightyatom> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10A523) From: Brian Adamson Date: Sat, 12 Jan 2013 18:40:21 -0500 To: Elwyn Davies X-Scanned-By: MIMEDefang 2.72 X-Mailman-Approved-At: Thu, 17 Jan 2013 08:25:44 -0800 Cc: Brian Adamson , DTN Users Subject: Re: [dtn-users] DTN2 NORM convergence layer X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 23:40:43 -0000 I'll talk to the guys who did the DTN binding. There are some important fix= es to pick up from the current code and I suspect the NORM API calls may nee= d some minor tweaking Sent from my iPhone On Jan 12, 2013, at 5:38 PM, Elwyn Davies wrote: > Hi, Brian. >=20 > Sergey Reskin and I have been trying to get the NORM convergence layer > working in DTN2. >=20 > I get the impression that the NORM code has moved along a bit since > there was much activity with NORM and DTN2 with the result that it > appears the latest daily snapshot compiles and links OK with DTN2 but > doesn't run. Crashes when trying to send a bundle for transmission. >=20 > I took a snapshot of the version 1.4b4 code about 2 years ago - the > README.TXT is dated March 13 2009 and the TODO.TXT April 12 2010. This > version appears to be nearly compabible with DTN2 - it runs after I > added case statements for NORM_TX_RATE_CHANGED to NORMReceiver.cc and > NORMSessionManager.cc event case statements. >=20 > Would it be possible to: > 1. Put a snapshot of the code that will work on the navy.mil downlaod > site. > 2. Let us know what has been changed and/or provide some patches that > will allow the most recent code to be used with DTN2. >=20 > Regards, > Elwyn Davies > Folly Consulting/ Trinity College Dublin >=20 >=20 From wangjingppwj@yahoo.com.cn Mon Jan 21 04:43:47 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F04C321F87B2 for ; Mon, 21 Jan 2013 04:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.843 X-Spam-Level: X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, SARE_SUB_OBFU_Q0=0.303] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7G83vwLfpEA0 for ; Mon, 21 Jan 2013 04:43:47 -0800 (PST) Received: from nm36-vm2.bullet.mail.sg3.yahoo.com (nm36-vm2.bullet.mail.sg3.yahoo.com [106.10.151.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBED21F8794 for ; Mon, 21 Jan 2013 04:43:46 -0800 (PST) Received: from [106.10.166.114] by nm36.bullet.mail.sg3.yahoo.com with NNFMP; 21 Jan 2013 12:43:44 -0000 Received: from [106.10.151.234] by tm3.bullet.mail.sg3.yahoo.com with NNFMP; 21 Jan 2013 12:43:44 -0000 Received: from [127.0.0.1] by omp1018.mail.sg3.yahoo.com with NNFMP; 21 Jan 2013 12:43:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 729582.23752.bm@omp1018.mail.sg3.yahoo.com Received: (qmail 67562 invoked by uid 60001); 21 Jan 2013 12:43:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.cn; s=s1024; t=1358772223; bh=UNq6oMjwU4ihvKNY7Slj0BLKFE522N7+UpXhc7ff5lc=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=RTRrVq/XdEKSqUg5eVfRObdkkYarxfFUlLfSWIsaUAONlPa5l8v+O3uXVb6eDMK1+7DP2H+8TbcETVTCWCGTenqDKzAbLi2FP7HOQ3wQ2LzOD5ju0bMUHRNeUIo13UbmTT86L+H+bVVDgjY+Qbc2DSL+zOIPg+eBAl6uVJjIGBc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=rFo94uYc/sPXhBGrGD6Vv5x3s8g67jhlMWPMB2Ynm3tWXM4fkbqv61WCmYAB+4iSnRPXd0lXtpVcQKhWGArSVeDlpcJWB+QzyNzt7UdSzJDj63LPqBJsuhwbJnB8WxUKcUO8lPANf584Ld3GEM02ajMZ+TTL4KY4mJUXpBdj94o=; X-YMail-OSG: uSNdhg8VM1mHaSUkSaKsAlkMqVrxH4YYYHDEUa7G2S33yjW wwy2LohZrxWSrX2LVTQ8Luacho1U1AJ_SOzLmGDkKL_PZuMjH1niwvUOZB4a jLMIb.bxbno4X24Sra_cbB5DkDKBYULojhYCvkuvVu_IhgMudaSpBVTnF4O8 5UHTnWFPTyoWeB4aBNPwtX8n4m1ktlooAddHS6t64djMRVk6frOfxnECvzYA fz7RNh6tp.F3w5y.AwcYi7lp1zx4mLsKwAeeqIw34Q9FTEIFr0Ua4oliv7WC 37jg82EaRaNgUn7RiYA0_9W0BkB.d_zv3TQfJOMUm_wZcQmFnvXB.XemsqWl pRtpYnCXuwR5cfIN90cQcnqHnK_zDKvkILkONDAT7i1WhA7YqdK9qwk.K2jO Fj5kZZV4IlEAAeAzuXfM2pO8ZzGqrEOC7HZSGEtcXnufCQZ5cWO2NODiaLsx UrSGcG35F51AKOWaf28UV5uJmh9GbtXkCuuuHxvDVC78- Received: from [202.114.106.35] by web15307.mail.cnb.yahoo.com via HTTP; Mon, 21 Jan 2013 20:43:43 CST X-Rocket-MIMEInfo: 001.001, CgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiDlj5Hku7bkurrvvJogImR0bi11c2Vyc0BpZXRmYS5hbXNsLmNvbSIgPGR0bi11c2Vyc0BpZXRmYS5hbXNsLmNvbT4K5pS25Lu25Lq677yaIHdhbmdqaW5ncHB3akB5YWhvby5jb20uY24gCuWPkemAgeaXpeacn..8miAyMDEz5bm0MeaciDIx5pelLCDmmJ_mnJ_kuIAsIDExOjQ1IOS4iuWNiArkuLvpopg6IENvbmZpcm06IGR0bi11c2Vyc0BpZXRmYS5hbXNsLmNvbTpmN2lydmxVUHk1NHc6UnlnMmNoUjN5dXlTNnpTTE1uM2h1NVBRZ0V5S2E5MWoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.130.494 References: <20130121034539.CD30821F8689@ietfa.amsl.com> Message-ID: <1358772223.67250.YahooMailNeo@web15307.mail.cnb.yahoo.com> Date: Mon, 21 Jan 2013 20:43:43 +0800 (CST) From: =?utf-8?B?6Z2WIOeOiw==?= To: "dtn-users@ietfa.amsl.com" In-Reply-To: <20130121034539.CD30821F8689@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1250308497-1838229390-1358772223=:67250" Subject: [dtn-users] =?utf-8?b?5Zue5aSN77yaIENvbmZpcm06IGR0bi11c2Vyc0Bp?= =?utf-8?q?etfa=2Eamsl=2Ecom=3Af7irvlUPy54w=3ARyg2chR3yuyS6zSLMn3hu5PQgEyK?= =?utf-8?q?a91j4Hvq1A?= X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: =?utf-8?B?6Z2WIOeOiw==?= List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 12:43:48 -0000 --1250308497-1838229390-1358772223=:67250 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A=0A=0A=0A________________________________=0A =E5=8F=91=E4=BB=B6=E4=BA=BA= =EF=BC=9A "dtn-users@ietfa.amsl.com" =0A=E6=94=B6= =E4=BB=B6=E4=BA=BA=EF=BC=9A wangjingppwj@yahoo.com.cn =0A=E5=8F=91=E9=80=81= =E6=97=A5=E6=9C=9F=EF=BC=9A 2013=E5=B9=B41=E6=9C=8821=E6=97=A5, =E6=98=9F= =E6=9C=9F=E4=B8=80, 11:45 =E4=B8=8A=E5=8D=88=0A=E4=B8=BB=E9=A2=98: Confirm:= dtn-users@ietfa.amsl.com:f7irvlUPy54w:Ryg2chR3yuyS6zSLMn3hu5PQgEyKa91j4Hvq= 1A=0A reply=0A=0AConfirmation of list posting -- confirmation ID: f7irvlUPy= 54w=0A=0AThe ietf.org mailing-list server has received a list posting from = =0Awangjingppwj@yahoo.com.cn to dtn-users@ietfa.amsl.com with the subject = =0A'***SPAM*** 7.685 (5)'=0A=0AAs the sender address isn't subscribed to th= e list, and has not been=0Aconfirmed earlier, we have to request a confirma= tion of the address.=0ATo confirm the address, send a message to dtn-users@= ietfa.amsl.com,=0Awith the same subject line as this message.=0A=0A(Simply = sending a 'reply' to this message should work from most email=0Ainterfaces,= since that usually leaves the subject line in the right=0Aform.=C2=A0 The = reply's additional "Re:" is ok.)=0A=0AIf you do not wish your posting to th= e list to go through, simply=0Adisregard this message.=C2=A0 Questions to p= ostmaster@ietf.org. --1250308497-1838229390-1358772223=:67250 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


<= font size=3D"2" face=3D"Arial">
=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A "dtn-users@ietfa= .amsl.com" <dtn-users@ietfa.amsl.com>
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A wangjingppwj@yah= oo.com.cn
=E5=8F=91=E9=80=81=E6= =97=A5=E6=9C=9F=EF=BC=9A 2013=E5=B9=B41=E6=9C=8821=E6=97=A5, =E6= =98=9F=E6=9C=9F=E4=B8=80, 11:45 =E4=B8=8A=E5=8D=88
=E4=B8=BB=E9=A2=98: Confirm: dtn-users@ietfa.a= msl.com:f7irvlUPy54w:Ryg2chR3yuyS6zSLMn3hu5PQgEyKa91j4Hvq1A
reply

Confirmation of list posting -- confirmation ID: f7irvlUPy54w

The ietf.org mailing-list server has received a list p= osting from
wangjingppwj@yahoo.com.cn to dtn-users@ietfa.amsl.com with the subject
'***SPAM*** 7.685 (5)'=

As the sender address isn't subscribed to the list, and has not bee= n
confirmed earlier, we have to request a confirmation of the address.To confirm the address, send a message to dtn-users@ietfa.am= sl.com,
with the same subject line as this message.

(Simply s= ending a 'reply' to this message should work from most email
interfaces,= since that usually leaves the subject line in the right
form.  The= reply's additional "Re:" is ok.)

If you do not wish your posting to= the list to go through, simply
disregard this message.  Questions to <= a ymailto=3D"mailto:postmaster@ietf.org" href=3D"mailto:postmaster@ietf.org= ">postmaster@ietf.org.



--1250308497-1838229390-1358772223=:67250-- From davieseb@scss.tcd.ie Wed Jan 30 06:56:10 2013 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386F621F8AB4 for ; Wed, 30 Jan 2013 06:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHTxSaexUkwy for ; Wed, 30 Jan 2013 06:56:09 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2865B21F8AB2 for ; Wed, 30 Jan 2013 06:56:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E8D07BE56 for ; Wed, 30 Jan 2013 14:55:44 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWQfUHj0YpWD; Wed, 30 Jan 2013 14:55:43 +0000 (GMT) Received: from [81.187.254.250] (mightyatom.folly.org.uk [81.187.254.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 944C2BE3B; Wed, 30 Jan 2013 14:55:43 +0000 (GMT) From: Elwyn Davies To: Alex McMahon Content-Type: multipart/mixed; boundary="=-9XUUcSKuvxOw59yQTYob" Organization: School of Computer Science and Statistics, TCD Date: Wed, 30 Jan 2013 14:57:01 +0000 Message-Id: <1359557821.4494.48.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Cc: DTN Users Subject: [dtn-users] Bug found in Registration.cc - patch attached X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 14:56:10 -0000 --=-9XUUcSKuvxOw59yQTYob Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi. While testing some other stuff, I discovered that the changes that were made to introduce 'replay_actions' into Registrations (changeset 3518) missed a couple of things. - replay_actions_ and delivery_acking_ are not in the serialize method - the 'Builder' constructor, which is used mostly when reading stored registrations back from persistent store at startup, doesn't] initialize replay_actions_, delivery_acking_ or session_flags_. The result is that for any Registrations that have a lifetime that makes them persistent across restarts will have random values in the replay_actions and delivery_acking_ fields after restart. If you are unlucky, this may trigger an assert in APIRegistration::set_active_callback (It did for me!) The attached patch fixes the problem. An additional item which I will fix shortly is that theese fields are not accessible through the scripting API, but that's not so urgent. Regards Elwyn COMMIT NARRATIVE: Ensure extra fields from Changeset 3518 in Registration structure are stored and restored correctly. Fixes: - Add replay_actions_ and delivery_acking_ to fields processed in Registration::serialize - Add initializers for replay_actions_, delivery_acking_ and session_flags_ to Registration::Registration(const oasys::Builder&) --=-9XUUcSKuvxOw59yQTYob Content-Disposition: attachment; filename="patch_reg" Content-Type: text/x-patch; name="patch_reg"; charset="us-ascii" Content-Transfer-Encoding: 7bit diff -r 480758b2ff34 servlib/reg/Registration.cc --- a/servlib/reg/Registration.cc Fri Jan 18 23:27:41 2013 +0000 +++ b/servlib/reg/Registration.cc Wed Jan 30 14:25:20 2013 +0000 @@ -90,6 +90,9 @@ regid_(0), endpoint_(), failure_action_(DEFER), + replay_action_(NEW), + session_flags_(0), + delivery_acking_(false), script_(), expiration_(0), creation_time_(0), @@ -165,7 +168,9 @@ a->process("endpoint", &endpoint_); a->process("regid", ®id_); a->process("failure_action", &failure_action_); + a->process("replay_action", &replay_action_); a->process("session_flags", &session_flags_); + a->process("delivery_acking", &delivery_acking_); a->process("script", &script_); a->process("creation_time", &creation_time_); a->process("expiration", &expiration_); --=-9XUUcSKuvxOw59yQTYob--