I submitted a patch based on the discussion in this thread= , but predicting the fragment lengths really is a nightmare. =A0With a lot = of effort, I do it badly. =A0So, I was rethinking this again. =A0What if fr= agments were based off of xmit_blocks but we actually then ran those blocks= through produce/consume to create recv_blocks? =A0Would that clear up all = the issues with bundle validity? =A0The downside is that this may create he= adaches with BAB since we're going to try to validate the blocks we wer= e planning to send as though we just received them, and then we're goin= g to try to add BAB again. =A0I haven't thought through how to deal wit= h those issues.

It feels like what we need is a way to call produce th= at produces serialized fragments to send out a convergence layer.

On Tue, Feb= 26, 2013 at 7:33 AM, Elwyn Davies <elwynd@folly.org.uk> w= rote:

Hi, Amy.

On Mon, 2013-02-25 at 20:21 -0500, Amy Alford wrote:
>
> Why is it pointless to copy the xmit_blocks? =A0They certainly need > patching up, but I've been able to do that AFAICT. =A0It ends up > behaving as though you sent the original bundle on the link, then the<= br> > next hop fragmented it.

Perhaps pointless was the wrong word. The problem is that the Bundle<= br> structure that is created for each fragment is not properly 'valid'= .
Things will probably work out as long as it remains on the link for
which the xmit blocks were created, but things will a.s. go very pear
shaped if the daemon is shutdown and restarted because the bundle, as
stored in persistent storage, will have no blocks since the storage is
driven from recv_blocks and api_blocks which remain empty. =A0The
resulting bundle read back will be flagged as invalid because it has no
primary or payload blocks - at best it will be flagged and discarded -
but there is a good chance it will trigger an assert somewhere. =A0A
similar problem will occur if a new link is opened along which the
fragment bundle could be routed - reroute_all_blocks will be called and
the fragments may end up on other links. An attempt to create
xmit_blocks for this new link will also barf. The same will happen if
the the link is closed down and/or restarted.

> Whether that's what you want for BSP (as opposed to fragmenting th= en
> adding BSP blocks), I don't know.

Right.. that depends on what sort of blocks you were adding. =A0The hop-by-hop integrity checks might have to be different - I don't know whether BAB blocks for hop-by-hop would be verified at the next security destination before or after reassembly (or indeed whether fragmentation
of such a bundle would be allowed).

Generated metadata blocks could also be a problem although that is more
of a theoretical problem at the moment because the generated metadata
block capability is not really used at present (the BPQ stuff that I am
working on is nearest to it AFAICS as it generates bundles in response
to queries if it has a match in the bundle cache and these have metadata blocks).

>
> On Mon, Feb 25, 2013 at 12:02 PM, Elwyn Davies <elwynd@folly.org.uk>
> wrote:
> =A0 =A0 =A0 =A0 Looking at the two create_fragment methods, the second= one is
> =A0 =A0 =A0 =A0 essentially useless (that's the one with 'link= ' in its
> =A0 =A0 =A0 =A0 parameters - it
> =A0 =A0 =A0 =A0 should probably be deleted as it is pointless copying = the xmit
> =A0 =A0 =A0 =A0 blocks as
> =A0 =A0 =A0 =A0 Amy discovered) and the first one needs some refinemen= t to
> =A0 =A0 =A0 =A0 make it work
> =A0 =A0 =A0 =A0 properly. If we actually generated a new recv_blocks l= ist (and
> =A0 =A0 =A0 =A0 possibly
> =A0 =A0 =A0 =A0 an api_blocks list - but that is probably not vital) t= he new
> =A0 =A0 =A0 =A0 fragments
> =A0 =A0 =A0 =A0 would get transmitted properly without needing to fudg= e
> =A0 =A0 =A0 =A0 queue_bundles
> =A0 =A0 =A0 =A0 and also without deleteing the original full size bund= le (I
> =A0 =A0 =A0 =A0 believe).
> =A0 =A0 =A0 =A0 However I think recording the MTU size to which the bu= ndle has
> =A0 =A0 =A0 =A0 been
> =A0 =A0 =A0 =A0 fragmented would help as we could avoid refragmenting = the
> =A0 =A0 =A0 =A0 whole bundle
> =A0 =A0 =A0 =A0 if it got tested on the same =A0link again (as it migh= t after a
> =A0 =A0 =A0 =A0 new link
> =A0 =A0 =A0 =A0 opened).
>

--089e0149c752cb5f3004db835922-- From sickmind@lavabit.com Mon Apr 29 14:59:07 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 EB6AC21F9C17 for ; Mon, 29 Apr 2013 14:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-gzBTpUxj1t for ; Mon, 29 Apr 2013 14:59:03 -0700 (PDT) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4110721F9C15 for ; Mon, 29 Apr 2013 14:59:03 -0700 (PDT) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id 87C6211BB95 for ; Mon, 29 Apr 2013 16:59:02 -0500 (CDT) Received: from localhost (pppoe.178-66-156-5.dynamic.avangarddsl.ru [178.66.156.5]) by lavabit.com with ESMTP id VHC7XCGCTLNL for ; Mon, 29 Apr 2013 16:59:02 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=rUa8cY/vg2d7whNnp8eddL/9+Eie7OOQLL/P/ShgHIVj86QhUJOXAd0tT2D45BoxuoQp6cs8b2tnBm6gWWOijdbBq2SVWJg4B0Tsizn0cuiimU1aElcVRTLEDywQipuRqBYmbVo0JjSVHJanbYVOlK3pp+qGbqEyTQ1cKio7tpU=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type:Content-Disposition:User-Agent; Date: Mon, 29 Apr 2013 21:59:17 +0000 From: Lana Black To: dtn-users maillist Message-ID: <20130429215917.GA16213@glow> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dtn-users] Ethernet announce patch 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: Mon, 29 Apr 2013 21:59:08 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, The ethernet announce code I submitted some time ago lacks gettimeofday() call, which results in beacons flood. The patch attached resolves this issue. With best regards. --rwEMma7ioTxnRzrJ Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="gettimeofday.patch" diff --git a/servlib/discovery/EthAnnounce.cc b/servlib/discovery/EthAnnounce.cc index 426817d..dd62502 100644 --- a/servlib/discovery/EthAnnounce.cc +++ b/servlib/discovery/EthAnnounce.cc @@ -49,6 +49,8 @@ size_t EthAnnounce::format_advertisement(u_char *bp, size_t len) beacon->eid_len = htons(eid.length()); memcpy(beacon->sender_eid, eid.c_str(), eid.length()); + ::gettimeofday(&data_sent_,0); + return sizeof(*beacon) + eid.length(); } --rwEMma7ioTxnRzrJ-- From sickmind@lavabit.com Tue Apr 30 06:39:27 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 E4C2521F9AD5 for ; Tue, 30 Apr 2013 06:39:27 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnJYvqRXdmU7 for ; Tue, 30 Apr 2013 06:39:23 -0700 (PDT) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1898121F9B83 for ; Tue, 30 Apr 2013 06:39:23 -0700 (PDT) Received: from b.earth.lavabit.com (b.earth.lavabit.com [192.168.111.11]) by karen.lavabit.com (Postfix) with ESMTP id A48BA11BC32 for ; Tue, 30 Apr 2013 08:39:22 -0500 (CDT) Received: from localhost (193.160.158.7) by lavabit.com with ESMTP id PM8MCFQ4N558 for ; Tue, 30 Apr 2013 08:39:22 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=TO3LbuGD7IENTvbSQAXrXFQPJ4J3NKZ0lCMQzDRfm9DCHy1HMqPTrU6onTwSC+fJBr5dhwQAtCypTix5IHPNz9tQ5a3UBz0eyfCsNywNjevCj6lg1Js6uomGZq6cGAK1fM4aODai1g+W5f8qYOHTQ/LwPETdHVlfUqGDhWzG5Cg=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type:Content-Disposition:User-Agent; Date: Tue, 30 Apr 2013 13:39:09 +0000 From: Lana Black To: dtn-users maillist Message-ID: <20130430133909.GA26220@kasumi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dtn-users] contributing file 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, 30 Apr 2013 13:39:28 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, The patch attached removes Michael Demmer from CONTRIBUTING file as a person to contact. Last time I contacted him he wrote he hadn't been working on this project anymore. With best regards. --OgqxwSJOaUobr8KG Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="contrib.patch" diff --git a/CONTRIBUTING b/CONTRIBUTING index 73d926a..3f2ee56 100644 --- a/CONTRIBUTING +++ b/CONTRIBUTING @@ -9,8 +9,8 @@ Contribution Process Anonymous source code repository access is available for the general public. To gain access for checkins via ssh access requires -permission. Send email to Michael Demmer if -you're interested in contributing. +permission. Send email to DTN Users mailing list +if you're interested in contributing. Coding Conventions ------------------ --OgqxwSJOaUobr8KG--