Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.185]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9VHpRtQ013988; Fri, 31 Oct 2008 10:51:28 -0700
Received: by rn-out-0910.google.com with SMTP id k32so1181825rnd.7 for <multiple recipients>; Fri, 31 Oct 2008 10:40:01 -0700 (PDT)
Received: by 10.142.180.11 with SMTP id c11mr5538256wff.159.1225474800404; Fri, 31 Oct 2008 10:40:00 -0700 (PDT)
Received: by 10.142.73.13 with HTTP; Fri, 31 Oct 2008 10:40:00 -0700 (PDT)
Message-ID: <59e8babf0810311040q7f0ee872r14d42f1d1897accf@mail.gmail.com>
Date: Fri, 31 Oct 2008 10:40:00 -0700
From: "Michael Demmer" <demmer@cs.berkeley.edu>
Sender: demmer@gmail.com
To: dtn-dev@mailman.dtnrg.org, "dtn-users mailing list" <dtn-users@mailman.dtnrg.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Google-Sender-Auth: 6036e23bf9b4e43d
Subject: [dtn-users] DTN mercurial repository on sourceforge
X-BeenThere: dtn-users@maillists.intel-research.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: dtn-users mailing list <dtn-users.maillists.intel-research.net>
List-Unsubscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=unsubscribe>
List-Archive: <http://maillists.intel-research.net/pipermail/dtn-users>
List-Post: <mailto:dtn-users@maillists.intel-research.net>
List-Help: <mailto:dtn-users-request@maillists.intel-research.net?subject=help>
List-Subscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=subscribe>
X-List-Received-Date: Fri, 31 Oct 2008 17:51:28 -0000

Sourceforge seems to have recently re-enabled their shell service
(with some changes), which among other things means that I was able to
log into their server and fix the mercurial installation so that the
repository works again.

For developers in the dtn project there's some new procedures needed
for shell login -- (you need to first create one, then you can ssh to
use it).

But in general, the normal HTTP-based cloning works again for
downloads and it looks like ssh-based cloning will work for commits.

hg clone http://dtn.sf.net/hg/DTN2/

-m


Received: from bacon.cs.umd.edu (server-nat-4.cs.umd.edu [128.8.127.147]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9SKI16l019577 for <dtn-users@maillists.intel-research.net>; Tue, 28 Oct 2008 13:18:01 -0700
X-CSD-MailScanner-Watermark: 1225829271.10094@c2A67J2VV035YXtadhJktw
Received: from webmail.cs.umd.edu (newman.cs.umd.edu [172.24.0.4]) by bacon.cs.umd.edu (8.13.1/8.14.1) with ESMTP id m9SK7mD5006212 for <dtn-users@maillists.intel-research.net>; Tue, 28 Oct 2008 16:07:48 -0400
Received: from 65.127.220.45 (SquirrelMail authenticated user jkseast) by webmail.cs.umd.edu with HTTP; Tue, 28 Oct 2008 16:07:48 -0400 (EDT)
Message-ID: <59825.65.127.220.45.1225224468.squirrel@webmail.cs.umd.edu>
Date: Tue, 28 Oct 2008 16:07:48 -0400 (EDT)
From: jkseast@cs.umd.edu
To: dtn-users@maillists.intel-research.net
User-Agent: SquirrelMail/1.4.10a
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (bacon.cs.umd.edu [172.24.3.34]); Tue, 28 Oct 2008 16:07:48 -0400 (EDT)
Subject: [dtn-users] Update Last Post
X-BeenThere: dtn-users@maillists.intel-research.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: dtn-users mailing list <dtn-users.maillists.intel-research.net>
List-Unsubscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=unsubscribe>
List-Archive: <http://maillists.intel-research.net/pipermail/dtn-users>
List-Post: <mailto:dtn-users@maillists.intel-research.net>
List-Help: <mailto:dtn-users-request@maillists.intel-research.net?subject=help>
List-Subscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=subscribe>
X-List-Received-Date: Tue, 28 Oct 2008 20:18:01 -0000

As an update to my other post.

Here's what I've observed with UDP and certain flags with dtnsend:

dtnsend -s <node1> -d <node2>  -c <node2> -r <node2> -t m -p "msg" -w -C -R

Behavior when node1 and node2 out of range:
bundle list shows 3 bundles, 2 47-byte (I assume rcpts) and 1 3 byte
(assume actual msg) All marked as NOT PENDING even though the nodes are
not in range.

dtnsend -s <node1> -d <node2>  -c <node2> -r <node2> -t m -p "msg" -C -R
(no -w)

Then bundle list shows one 3 byte bundle (assume msg) without a NOT
PENDING status. One 47 byte bundle without a NOT PENDING status.

With both cmd lines, no change when nodes are now in range.
Also, after a number of bundles stack up this way, no additional are added
when sent. This is when I appear to see the "delivered before custody
accepted" (but not 100% sure of this). I do know no additional bundles
appear in the list (probably a storage param I can adjust).

Can someone help with what is the expected behavior with the above cmds
using UDP at CL?

Thanks!!




Received: from bacon.cs.umd.edu (server-nat-4.cs.umd.edu [128.8.127.147]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9SJlvIA018227 for <dtn-users@maillists.intel-research.net>; Tue, 28 Oct 2008 12:47:57 -0700
X-CSD-MailScanner-Watermark: 1225827467.1783@TdNYVZRMFo+A/liAvMybKg
Received: from webmail.cs.umd.edu (newman.cs.umd.edu [172.24.0.4]) by bacon.cs.umd.edu (8.13.1/8.14.1) with ESMTP id m9SJbj90004296 for <dtn-users@maillists.intel-research.net>; Tue, 28 Oct 2008 15:37:45 -0400
Received: from 65.127.220.45 (SquirrelMail authenticated user jkseast) by webmail.cs.umd.edu with HTTP; Tue, 28 Oct 2008 15:37:45 -0400 (EDT)
Message-ID: <58462.65.127.220.45.1225222665.squirrel@webmail.cs.umd.edu>
Date: Tue, 28 Oct 2008 15:37:45 -0400 (EDT)
From: jkseast@cs.umd.edu
To: dtn-users@maillists.intel-research.net
User-Agent: SquirrelMail/1.4.10a
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (bacon.cs.umd.edu [172.24.3.34]); Tue, 28 Oct 2008 15:37:46 -0400 (EDT)
Subject: [dtn-users] UDP State Change
X-BeenThere: dtn-users@maillists.intel-research.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: dtn-users mailing list <dtn-users.maillists.intel-research.net>
List-Unsubscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=unsubscribe>
List-Archive: <http://maillists.intel-research.net/pipermail/dtn-users>
List-Post: <mailto:dtn-users@maillists.intel-research.net>
List-Help: <mailto:dtn-users-request@maillists.intel-research.net?subject=help>
List-Subscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=subscribe>
X-List-Received-Date: Tue, 28 Oct 2008 19:47:58 -0000

Hello Again,

Using the -l info command has been very helpful. I've been able to observe
reception receipts and custody transfer receipts with UDP now.

Does anyone know if UDP ever changes state with OPPORTUNISTIC routes? This
is key for me to continue my CL experiments. When my wireless nodes are
out of range from each other, the UDP state (listed via route dump)
remains OPEN. Even with custody transfer enabled, "bundle list" marks this
bundle as NOT PENDING when the nodes are not within range. The bundle
never appears in the dest bundle list. When the nodes come back into
range, the bundle is never delivered to the dest node and again never
appears in the bundle list at the destination. Subsequent connections with
the node sin range seems to work.

There is an entry:
delivered before custody accepted
using -l. Is this an indication that the bundle is being delivered to an
out-of-range node?

I have no problem hacking the code to fix this if it is a bug...but if
it's just user error and this has been tested and works I'd appreciate the
feedback.

Many thanks!





Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9OJOsj3018551 for <dtn-users@maillists.intel-research.net>; Fri, 24 Oct 2008 12:24:55 -0700
Received: by gxk10 with SMTP id 10so74866gxk.10 for <dtn-users@maillists.intel-research.net>; Fri, 24 Oct 2008 12:16:31 -0700 (PDT)
Received: by 10.142.177.7 with SMTP id z7mr503053wfe.249.1224875791032; Fri, 24 Oct 2008 12:16:31 -0700 (PDT)
Received: by 10.143.10.11 with HTTP; Fri, 24 Oct 2008 12:16:31 -0700 (PDT)
Message-ID: <59e8babf0810241216v2354f643xa6979fdf7ca3e0b6@mail.gmail.com>
Date: Fri, 24 Oct 2008 12:16:31 -0700
From: "Michael Demmer" <demmer@cs.berkeley.edu>
Sender: demmer@gmail.com
To: jkseast@cs.umd.edu
In-Reply-To: <44925.65.127.220.45.1224868168.squirrel@webmail.cs.umd.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <44925.65.127.220.45.1224868168.squirrel@webmail.cs.umd.edu>
X-Google-Sender-Auth: 8280ae72e6feca13
Cc: dtn-users@maillists.intel-research.net
Subject: Re: [dtn-users] Custody Transfer
X-BeenThere: dtn-users@maillists.intel-research.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: dtn-users mailing list <dtn-users.maillists.intel-research.net>
List-Unsubscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=unsubscribe>
List-Archive: <http://maillists.intel-research.net/pipermail/dtn-users>
List-Post: <mailto:dtn-users@maillists.intel-research.net>
List-Help: <mailto:dtn-users-request@maillists.intel-research.net?subject=help>
List-Subscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=subscribe>
X-List-Received-Date: Fri, 24 Oct 2008 19:24:55 -0000

Jessica,

>From your output, all you know is that the bundle was transferred from
the application to the dtn daemon on node1, but nothing thereafter.

You'll need to take a look at the output from the dtnd process and/or
interact using the console interface to understand more of what's
going on.

As an initial start, run dtnd with '-l info' to get more debugging
output, and you can type 'help' at the console prompt to query on the
different management functions that are available.

-m

On Fri, Oct 24, 2008 at 10:09 AM,  <jkseast@cs.umd.edu> wrote:
> I'm not really having too much success with custody transfer and would
> really appreciate some help.
>
> 1. I'm using UDP for the convergence layer.
> 2. I am using the dtnsend and dtnrecv apps with the following commands:
> (I replaced the uri's with node1 and node2 for compactness).
>
> dtnsend -s dtn://<node1>.dtn/ -d dtn://<node2>.dtn/ -e 12000 -t m -p
> "test" -c dtn://<node2>.dtn/ -C -R -v
>
> dtnrecv dtn://<node2>.dtn/*
>
> 3. The following is the dtnsend output:
>
> Opening connection to local DTN daemon
> Destination: dtn://<node2>.dtn/
> dtn://<node2>.dtn/ (literal)
> Source: dtn://<node1>.dtn/
> dtn://<node1>.dtn/ (literal)
> Reply To: same as source
> source_eid [dtn://<node1>.dtn/]
> replyto_eid [dtn://<node1>.dtn/]
> dest_eid [dtn://<node2>.dtn/]
> bundle sent successfully: id dtn://<node1>.dtn/,278177179.55
>
> 4. I am trying to establish that node2 actually takes custody of the
> bundle.  I see the receipt above that "bundle sent successfully", but this
> is to node1. Which I understand to mean the dtn at node1 has accepted
> custody.
>
> I am looking for an endpoint receipt from node2 when it takes custody and
> don't seem to get this even when nodes are in range of each other. The
> second issue occurs when nodes 1 and 2 move in and out of range. There
> never seems to be a point at which node1 discovers node2, discovers a
> pending bundle, and transfers custody of the bundle to node2.
>
> I am very new to dtn work and I'm sure these are all misunderstanding I
> have with the implementation or the spec. I would however very much
> appreciate any help to help get me up and running.
>
> Thank you,
> Jessica Seastrom
>
> _______________________________________________
> dtn-users mailing list
> dtn-users@maillists.intel-research.net
> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>


Received: from bacon.cs.umd.edu (server-nat-4.cs.umd.edu [128.8.127.147]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9OHHprU012728 for <dtn-users@maillists.intel-research.net>; Fri, 24 Oct 2008 10:17:51 -0700
X-CSD-MailScanner-Watermark: 1225472970.13036@kkt+9kIU70MWznmK15QrtQ
Received: from webmail.cs.umd.edu (newman.cs.umd.edu [172.24.0.4]) by bacon.cs.umd.edu (8.13.1/8.14.1) with ESMTP id m9OH9S9k019621 for <dtn-users@maillists.intel-research.net>; Fri, 24 Oct 2008 13:09:28 -0400
Received: from 65.127.220.45 (SquirrelMail authenticated user jkseast) by webmail.cs.umd.edu with HTTP; Fri, 24 Oct 2008 13:09:28 -0400 (EDT)
Message-ID: <44925.65.127.220.45.1224868168.squirrel@webmail.cs.umd.edu>
Date: Fri, 24 Oct 2008 13:09:28 -0400 (EDT)
From: jkseast@cs.umd.edu
To: dtn-users@maillists.intel-research.net
User-Agent: SquirrelMail/1.4.10a
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (bacon.cs.umd.edu [172.24.3.34]); Fri, 24 Oct 2008 13:09:28 -0400 (EDT)
Subject: [dtn-users] Custody Transfer
X-BeenThere: dtn-users@maillists.intel-research.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: dtn-users mailing list <dtn-users.maillists.intel-research.net>
List-Unsubscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=unsubscribe>
List-Archive: <http://maillists.intel-research.net/pipermail/dtn-users>
List-Post: <mailto:dtn-users@maillists.intel-research.net>
List-Help: <mailto:dtn-users-request@maillists.intel-research.net?subject=help>
List-Subscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=subscribe>
X-List-Received-Date: Fri, 24 Oct 2008 17:17:51 -0000

I'm not really having too much success with custody transfer and would
really appreciate some help.

1. I'm using UDP for the convergence layer.
2. I am using the dtnsend and dtnrecv apps with the following commands:
(I replaced the uri's with node1 and node2 for compactness).

dtnsend -s dtn://<node1>.dtn/ -d dtn://<node2>.dtn/ -e 12000 -t m -p
"test" -c dtn://<node2>.dtn/ -C -R -v

dtnrecv dtn://<node2>.dtn/*

3. The following is the dtnsend output:

Opening connection to local DTN daemon
Destination: dtn://<node2>.dtn/
dtn://<node2>.dtn/ (literal)
Source: dtn://<node1>.dtn/
dtn://<node1>.dtn/ (literal)
Reply To: same as source
source_eid [dtn://<node1>.dtn/]
replyto_eid [dtn://<node1>.dtn/]
dest_eid [dtn://<node2>.dtn/]
bundle sent successfully: id dtn://<node1>.dtn/,278177179.55

4. I am trying to establish that node2 actually takes custody of the
bundle.  I see the receipt above that "bundle sent successfully", but this
is to node1. Which I understand to mean the dtn at node1 has accepted
custody.

I am looking for an endpoint receipt from node2 when it takes custody and
don't seem to get this even when nodes are in range of each other. The
second issue occurs when nodes 1 and 2 move in and out of range. There
never seems to be a point at which node1 discovers node2, discovers a
pending bundle, and transfers custody of the bundle to node2.

I am very new to dtn work and I'm sure these are all misunderstanding I
have with the implementation or the spec. I would however very much
appreciate any help to help get me up and running.

Thank you,
Jessica Seastrom



Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by maillists.intel-research.net (8.13.8/8.13.8) with SMTP id m9N6ia3V014104 for <dtn-users@maillists.intel-research.net>; Wed, 22 Oct 2008 23:44:37 -0700
X-VirusChecked: Checked
X-Env-Sender: L.Wood@surrey.ac.uk
X-Msg-Ref: server-11.tower-78.messagelabs.com!1224743813!58240144!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [131.227.102.140]
Received: (qmail 8661 invoked from network); 23 Oct 2008 06:36:53 -0000
Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-11.tower-78.messagelabs.com with SMTP; 23 Oct 2008 06:36:53 -0000
Received: from EVS-EC1-NODE4.surrey.ac.uk ([131.227.102.139]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 23 Oct 2008 07:36:52 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C934D9.BBF20CA9"
Date: Thu, 23 Oct 2008 07:36:52 +0100
Message-ID: <4835AFD53A246A40A3B8DA85D658C4BE7B0CAC@EVS-EC1-NODE4.surrey.ac.uk>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dtn-users] UDP Question
Thread-Index: Ack0lFwaSI/i4nO5SNykpHlhXgI+sgAREcSe
References: <57811.65.127.220.45.1224712870.squirrel@webmail.cs.umd.edu> <59e8babf0810221512m7c9e73fbs37e9e719db64a18b@mail.gmail.com>
From: <L.Wood@surrey.ac.uk>
To: <demmer@cs.berkeley.edu>, <jkseast@cs.umd.edu>
X-OriginalArrivalTime: 23 Oct 2008 06:36:52.0690 (UTC) FILETIME=[BC34E320:01C934D9]
Cc: dtn-users@maillists.intel-research.net
Subject: Re: [dtn-users] UDP Question
X-BeenThere: dtn-users@maillists.intel-research.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: dtn-users mailing list <dtn-users.maillists.intel-research.net>
List-Unsubscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=unsubscribe>
List-Archive: <http://maillists.intel-research.net/pipermail/dtn-users>
List-Post: <mailto:dtn-users@maillists.intel-research.net>
List-Help: <mailto:dtn-users-request@maillists.intel-research.net?subject=help>
List-Subscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=subscribe>
X-List-Received-Date: Thu, 23 Oct 2008 06:44:39 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01C934D9.BBF20CA9
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Although the UDP convergence layer in dtnd does not implement =
reliability, both Saratoga and LTP (Licklider) both build on UDP, and =
implement acknowledgement-based reliability to prevent erasures. Error =
detection reliability with a checksum across transferred files is also =
included in Saratoga. Custody transfer can prevent erasures, but does =
not implement error detection or checking.

However, neither Saratoga nor LTP are implemented in dtnd. LTP =
implementations are available:
http://www.dtnrg.org/wiki/Code

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@surrey.ac.uk>



-----Original Message-----
From: dtn-users-bounces@maillists.intel-research.net on behalf of =
Michael Demmer
Sent: Wed 2008-10-22 23:12
To: jkseast@cs.umd.edu
Cc: dtn-users@maillists.intel-research.net
Subject: Re: [dtn-users] UDP Question
=20
Currently the only way to get reliability when using UDP is to use
custody transfer.

-m

On Wed, Oct 22, 2008 at 3:01 PM,  <jkseast@cs.umd.edu> wrote:
> I'd like some help with reliable bundle transfer with udp.
>
> Q1: I've configured dtnd to discover wireless nodes that come within =
range
> and to use udp. When nodes are discovered, I notice the links are =
added
> and udp state=3DOPEN. However, when the wireless nodes are moved out =
of
> range, the state never changes. Should the state change to =
UNAVAILABLE?
> (it does change with TCP).
>
> Q2: A bundle is marked as transmitted and deleted from the bundle list
> even when the recv node is out of range. However, the recv node does =
not
> indicate a received bundle in its bundle list. I would like to add
> reliability and for the bundle to remain in a pending status until it =
is
> recvd at the dtn layer. Is there a config param I can set to ensure
> reliability when using a UDP convergence layer?
>
> Config file below.
>
> #
> # dtn.conf
> #
> # Default configuration file for Internet-connected DTN nodes. The
> # daemon uses a tcl interpreter to parse this file, thus any standard
> # tcl commands are valid, and all settings are get/set using a single
> # 'set' functions as: <module> set <var> <val?>
> #
>
> log /dtnd info "dtnd parsing configuration..."
>
> ########################################
> #
> # Daemon Console Configuration
> #
> ########################################
>
> #
> # console set stdio [ true | false ]
> #
> # If set to false, disable the interactive console on stdin/stdout.
> # The default is set to true (unless the dtnd process is run as a
> # daemon).
> #
> # console set stdio false
>
> #
> # console set addr <port>
> # console set port <port>
> #
> # Settings for the socket based console protocol.
> # (this interprets user commands)
> #
> console set addr 127.0.0.1
> console set port 5050
>
> #
> # console set prompt <prompt>
> #
> # Set the prompt string.  Helps if running multiple dtnd's
> #
> set shorthostname [lindex [split [info hostname] .] 0]
> console set prompt "$shorthostname dtn% "
>
> ########################################
> #
> # Storage Configuration
> #
> ########################################
>
> #
> # storage set type [ berkeleydb | postgres | mysql  | external ]
> #
> # Set the storage system to be used
> #
> storage set type berkeleydb
>
> # the following are for use with external data stores
> #
> # The server port to connect to (on localhost)
> # Note that 62345 has no special significance -- chosen randomly
> storage set server_port 62345
>
> # The external data store schema location, which can be
> # found in dtn2/oasys/storage/DS.xsd.
> storage set schema /etc/DS.xsd
>
>
> #
> # Do a runtime check for the standard locations for the persistent
> # storage directory
> #
> set dbdir ""
> foreach dir {/var/dtn /var/tmp/dtn} {
>    if {[file isdirectory $dir]} {
>        set dbdir $dir
>        break
>    }
> }
>
> if {$dbdir =3D=3D ""} {
>    puts stderr "Must create /var/dtn or /var/tmp/dtn storage =
directory"
>    exit 1
> }
>
> #
> # storage set payloaddir <dir>
> #
> # Set the directory to be used for bundle payload files
> #
> storage set payloaddir $dbdir/bundles
>
> #
> # storage set dbname <db>
> #
> # Set the database name (appended with .db as the filename in berkeley
> # db, used as-is for SQL variants
> #
> storage set dbname     DTN
>
> #
> # storage set dbdir    <dir>
> #
> #
> # When using berkeley db, set the directory to be used for the
> # database files and the name of the files and error log.
> #
> storage set dbdir      $dbdir/db
>
> ########################################
> #
> # Routing configuration
> #
> ########################################
>
> #
> # Set the algorithm used for dtn routing.
> #
> # route set type [static | flood | neighborhood | linkstate | =
external]
> #
> route set type static
>
> #
> # route local_eid <eid>
> #
> # Set the local administrative id of this node. The default just uses
> # the internet hostname plus the appended string ".dtn" to make it
> # clear that the hostname isn't really used for DNS lookups.
> #
> route local_eid "dtn://[info hostname].dtn"
>
> #
> # External router specific options
> #
> # route set server_port 8001
> # route set hello_interval 30
> route set add_nexthop_routes true
> route set open_discovered_links true
> route set hello_interval 10
> # route set schema "/etc/router.xsd"
>
> ########################################
> #
> # TCP convergence layer configuration
> #
> ########################################
>
> #
> # interface add [name] [CL]
> #
> # Add an input interface to listen on addr:port for incoming bundles
> # from other tcp / udp convergence layers
> #
> # For IP-based interfaces, interfaces listen on INADDR_ANY port 4556
> # by default. These can be overridden by using the local_addr and/or
> # local_port arguments.
> interface add tcp0 tcp
> interface add udp0 udp
> #interface add tcp0 tcp local_port=3D4556
> #interface add udp0 udp local_port=3D4557
>
> #
> # link add <name> <nexthop> <type> <clayer> <args...>
> #
> # Add a link to a peer node.
> #
> # For IP-based links (tcp or udp), the nexthop should contain a DNS
> # hostname or IP address, followed optionally by a : and a port. If
> # the port is not specified, the default of 4556 is used.
> #
> # e.g.  link add link1 dtn.dtnrg.org ONDEMAND tcp
> #       link add link2 dtn2.dtnrg.org:10000 ONDEMAND tcp
>
> #link add link_tcp 192.168.10.2:4456 ONDEMAND tcp
> #link add link_udp 192.168.10.2:4557 ONDEMAND udp
>
> #
> # route add <dest> <link|peer>
> #
> # Add a route to the given bundle endpoint id pattern <dest> using the
> # specified link name or peer endpoint.
> #
> # e.g. route add dtn://host.domain/* tcp0
>
> #route add dtn://node1-2.grid.lts.org.dtn/* link_tcp
> #route add dtn://node1-2.grid.lts.org.dtn/* link_udp
>
> ########################################
> #
> # Service discovery
> #
> ########################################
>
> #
> # discovery add <name> <af> <opts...>
> # discovery announce <cl_name> <discovery_name> <cl_type> <opts...>
> #
> # Add a local neighborhood discovery module
> #
> # e.g. discovery add discovery_bonjour bonjour
> # figure out my IP address
> set my_disco_ip [regexp -inline {\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}} =
[exec
> /sbin/ifconfig ath0] ]
>
> discovery add discovery_test ip port=3D2000 addr=3D192.168.10.255
> discovery announce name discovery_test udp interval=3D5 =
cl_addr=3D$my_disco_ip
> ########################################
> #
> # Parameter Tuning
> #
> ########################################
>
> #
> # Set the size threshold for the daemon so any bundles smaller than =
this
> # size maintain a shadow copy in memory to minimize disk accesses.
> #
> # param set payload_mem_threshold 16384
>
> #
> # Test option to keep all bundle files in the filesystem, even after =
the
> # bundle is no longer present at the daemon.
> #
> # param set payload_test_no_remove true
>
> #
> # Set the size for which the tcp convergence layer sends partial =
reception
> # acknowledgements. Used with reactive fragmentation
> #
> # param set tcpcl_partial_ack_len 4096
>
> #
> # Set if bundles are automatically deleted after transmission
> #
> # param set early_deletion true
>
> # (others exist but are not fully represented here)
>
> log /dtnd info "dtnd configuration parsing complete"
>
> ## emacs settings to use tcl-mode by default
> ## Local Variables: ***
> ## mode:tcl ***
> ## End: ***
>
>
> _______________________________________________
> dtn-users mailing list
> dtn-users@maillists.intel-research.net
> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>
_______________________________________________
dtn-users mailing list
dtn-users@maillists.intel-research.net
http://maillists.intel-research.net/mailman/listinfo/dtn-users


------_=_NextPart_001_01C934D9.BBF20CA9
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7652.24">
<TITLE>RE: [dtn-users] UDP Question</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Although the UDP convergence layer in dtnd does not =
implement reliability, both Saratoga and LTP (Licklider) both build on =
UDP, and implement acknowledgement-based reliability to prevent =
erasures. Error detection reliability with a checksum across transferred =
files is also included in Saratoga. Custody transfer can prevent =
erasures, but does not implement error detection or checking.<BR>
<BR>
However, neither Saratoga nor LTP are implemented in dtnd. LTP =
implementations are available:<BR>
<A =
HREF=3D"http://www.dtnrg.org/wiki/Code">http://www.dtnrg.org/wiki/Code</A=
><BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;L.Wood@surrey.ac.uk&gt;<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: dtn-users-bounces@maillists.intel-research.net on behalf of =
Michael Demmer<BR>
Sent: Wed 2008-10-22 23:12<BR>
To: jkseast@cs.umd.edu<BR>
Cc: dtn-users@maillists.intel-research.net<BR>
Subject: Re: [dtn-users] UDP Question<BR>
<BR>
Currently the only way to get reliability when using UDP is to use<BR>
custody transfer.<BR>
<BR>
-m<BR>
<BR>
On Wed, Oct 22, 2008 at 3:01 PM,&nbsp; &lt;jkseast@cs.umd.edu&gt; =
wrote:<BR>
&gt; I'd like some help with reliable bundle transfer with udp.<BR>
&gt;<BR>
&gt; Q1: I've configured dtnd to discover wireless nodes that come =
within range<BR>
&gt; and to use udp. When nodes are discovered, I notice the links are =
added<BR>
&gt; and udp state=3DOPEN. However, when the wireless nodes are moved =
out of<BR>
&gt; range, the state never changes. Should the state change to =
UNAVAILABLE?<BR>
&gt; (it does change with TCP).<BR>
&gt;<BR>
&gt; Q2: A bundle is marked as transmitted and deleted from the bundle =
list<BR>
&gt; even when the recv node is out of range. However, the recv node =
does not<BR>
&gt; indicate a received bundle in its bundle list. I would like to =
add<BR>
&gt; reliability and for the bundle to remain in a pending status until =
it is<BR>
&gt; recvd at the dtn layer. Is there a config param I can set to =
ensure<BR>
&gt; reliability when using a UDP convergence layer?<BR>
&gt;<BR>
&gt; Config file below.<BR>
&gt;<BR>
&gt; #<BR>
&gt; # dtn.conf<BR>
&gt; #<BR>
&gt; # Default configuration file for Internet-connected DTN nodes. =
The<BR>
&gt; # daemon uses a tcl interpreter to parse this file, thus any =
standard<BR>
&gt; # tcl commands are valid, and all settings are get/set using a =
single<BR>
&gt; # 'set' functions as: &lt;module&gt; set &lt;var&gt; =
&lt;val?&gt;<BR>
&gt; #<BR>
&gt;<BR>
&gt; log /dtnd info &quot;dtnd parsing configuration...&quot;<BR>
&gt;<BR>
&gt; ########################################<BR>
&gt; #<BR>
&gt; # Daemon Console Configuration<BR>
&gt; #<BR>
&gt; ########################################<BR>
&gt;<BR>
&gt; #<BR>
&gt; # console set stdio [ true | false ]<BR>
&gt; #<BR>
&gt; # If set to false, disable the interactive console on =
stdin/stdout.<BR>
&gt; # The default is set to true (unless the dtnd process is run as =
a<BR>
&gt; # daemon).<BR>
&gt; #<BR>
&gt; # console set stdio false<BR>
&gt;<BR>
&gt; #<BR>
&gt; # console set addr &lt;port&gt;<BR>
&gt; # console set port &lt;port&gt;<BR>
&gt; #<BR>
&gt; # Settings for the socket based console protocol.<BR>
&gt; # (this interprets user commands)<BR>
&gt; #<BR>
&gt; console set addr 127.0.0.1<BR>
&gt; console set port 5050<BR>
&gt;<BR>
&gt; #<BR>
&gt; # console set prompt &lt;prompt&gt;<BR>
&gt; #<BR>
&gt; # Set the prompt string.&nbsp; Helps if running multiple dtnd's<BR>
&gt; #<BR>
&gt; set shorthostname [lindex [split [info hostname] .] 0]<BR>
&gt; console set prompt &quot;$shorthostname dtn% &quot;<BR>
&gt;<BR>
&gt; ########################################<BR>
&gt; #<BR>
&gt; # Storage Configuration<BR>
&gt; #<BR>
&gt; ########################################<BR>
&gt;<BR>
&gt; #<BR>
&gt; # storage set type [ berkeleydb | postgres | mysql&nbsp; | external =
]<BR>
&gt; #<BR>
&gt; # Set the storage system to be used<BR>
&gt; #<BR>
&gt; storage set type berkeleydb<BR>
&gt;<BR>
&gt; # the following are for use with external data stores<BR>
&gt; #<BR>
&gt; # The server port to connect to (on localhost)<BR>
&gt; # Note that 62345 has no special significance -- chosen =
randomly<BR>
&gt; storage set server_port 62345<BR>
&gt;<BR>
&gt; # The external data store schema location, which can be<BR>
&gt; # found in dtn2/oasys/storage/DS.xsd.<BR>
&gt; storage set schema /etc/DS.xsd<BR>
&gt;<BR>
&gt;<BR>
&gt; #<BR>
&gt; # Do a runtime check for the standard locations for the =
persistent<BR>
&gt; # storage directory<BR>
&gt; #<BR>
&gt; set dbdir &quot;&quot;<BR>
&gt; foreach dir {/var/dtn /var/tmp/dtn} {<BR>
&gt;&nbsp;&nbsp;&nbsp; if {[file isdirectory $dir]} {<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; set dbdir $dir<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; break<BR>
&gt;&nbsp;&nbsp;&nbsp; }<BR>
&gt; }<BR>
&gt;<BR>
&gt; if {$dbdir =3D=3D &quot;&quot;} {<BR>
&gt;&nbsp;&nbsp;&nbsp; puts stderr &quot;Must create /var/dtn or =
/var/tmp/dtn storage directory&quot;<BR>
&gt;&nbsp;&nbsp;&nbsp; exit 1<BR>
&gt; }<BR>
&gt;<BR>
&gt; #<BR>
&gt; # storage set payloaddir &lt;dir&gt;<BR>
&gt; #<BR>
&gt; # Set the directory to be used for bundle payload files<BR>
&gt; #<BR>
&gt; storage set payloaddir $dbdir/bundles<BR>
&gt;<BR>
&gt; #<BR>
&gt; # storage set dbname &lt;db&gt;<BR>
&gt; #<BR>
&gt; # Set the database name (appended with .db as the filename in =
berkeley<BR>
&gt; # db, used as-is for SQL variants<BR>
&gt; #<BR>
&gt; storage set dbname&nbsp;&nbsp;&nbsp;&nbsp; DTN<BR>
&gt;<BR>
&gt; #<BR>
&gt; # storage set dbdir&nbsp;&nbsp;&nbsp; &lt;dir&gt;<BR>
&gt; #<BR>
&gt; #<BR>
&gt; # When using berkeley db, set the directory to be used for the<BR>
&gt; # database files and the name of the files and error log.<BR>
&gt; #<BR>
&gt; storage set dbdir&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $dbdir/db<BR>
&gt;<BR>
&gt; ########################################<BR>
&gt; #<BR>
&gt; # Routing configuration<BR>
&gt; #<BR>
&gt; ########################################<BR>
&gt;<BR>
&gt; #<BR>
&gt; # Set the algorithm used for dtn routing.<BR>
&gt; #<BR>
&gt; # route set type [static | flood | neighborhood | linkstate | =
external]<BR>
&gt; #<BR>
&gt; route set type static<BR>
&gt;<BR>
&gt; #<BR>
&gt; # route local_eid &lt;eid&gt;<BR>
&gt; #<BR>
&gt; # Set the local administrative id of this node. The default just =
uses<BR>
&gt; # the internet hostname plus the appended string &quot;.dtn&quot; =
to make it<BR>
&gt; # clear that the hostname isn't really used for DNS lookups.<BR>
&gt; #<BR>
&gt; route local_eid &quot;dtn://[info hostname].dtn&quot;<BR>
&gt;<BR>
&gt; #<BR>
&gt; # External router specific options<BR>
&gt; #<BR>
&gt; # route set server_port 8001<BR>
&gt; # route set hello_interval 30<BR>
&gt; route set add_nexthop_routes true<BR>
&gt; route set open_discovered_links true<BR>
&gt; route set hello_interval 10<BR>
&gt; # route set schema &quot;/etc/router.xsd&quot;<BR>
&gt;<BR>
&gt; ########################################<BR>
&gt; #<BR>
&gt; # TCP convergence layer configuration<BR>
&gt; #<BR>
&gt; ########################################<BR>
&gt;<BR>
&gt; #<BR>
&gt; # interface add [name] [CL]<BR>
&gt; #<BR>
&gt; # Add an input interface to listen on addr:port for incoming =
bundles<BR>
&gt; # from other tcp / udp convergence layers<BR>
&gt; #<BR>
&gt; # For IP-based interfaces, interfaces listen on INADDR_ANY port =
4556<BR>
&gt; # by default. These can be overridden by using the local_addr =
and/or<BR>
&gt; # local_port arguments.<BR>
&gt; interface add tcp0 tcp<BR>
&gt; interface add udp0 udp<BR>
&gt; #interface add tcp0 tcp local_port=3D4556<BR>
&gt; #interface add udp0 udp local_port=3D4557<BR>
&gt;<BR>
&gt; #<BR>
&gt; # link add &lt;name&gt; &lt;nexthop&gt; &lt;type&gt; &lt;clayer&gt; =
&lt;args...&gt;<BR>
&gt; #<BR>
&gt; # Add a link to a peer node.<BR>
&gt; #<BR>
&gt; # For IP-based links (tcp or udp), the nexthop should contain a =
DNS<BR>
&gt; # hostname or IP address, followed optionally by a : and a port. =
If<BR>
&gt; # the port is not specified, the default of 4556 is used.<BR>
&gt; #<BR>
&gt; # e.g.&nbsp; link add link1 dtn.dtnrg.org ONDEMAND tcp<BR>
&gt; #&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; link add link2 =
dtn2.dtnrg.org:10000 ONDEMAND tcp<BR>
&gt;<BR>
&gt; #link add link_tcp 192.168.10.2:4456 ONDEMAND tcp<BR>
&gt; #link add link_udp 192.168.10.2:4557 ONDEMAND udp<BR>
&gt;<BR>
&gt; #<BR>
&gt; # route add &lt;dest&gt; &lt;link|peer&gt;<BR>
&gt; #<BR>
&gt; # Add a route to the given bundle endpoint id pattern &lt;dest&gt; =
using the<BR>
&gt; # specified link name or peer endpoint.<BR>
&gt; #<BR>
&gt; # e.g. route add dtn://host.domain/* tcp0<BR>
&gt;<BR>
&gt; #route add dtn://node1-2.grid.lts.org.dtn/* link_tcp<BR>
&gt; #route add dtn://node1-2.grid.lts.org.dtn/* link_udp<BR>
&gt;<BR>
&gt; ########################################<BR>
&gt; #<BR>
&gt; # Service discovery<BR>
&gt; #<BR>
&gt; ########################################<BR>
&gt;<BR>
&gt; #<BR>
&gt; # discovery add &lt;name&gt; &lt;af&gt; &lt;opts...&gt;<BR>
&gt; # discovery announce &lt;cl_name&gt; &lt;discovery_name&gt; =
&lt;cl_type&gt; &lt;opts...&gt;<BR>
&gt; #<BR>
&gt; # Add a local neighborhood discovery module<BR>
&gt; #<BR>
&gt; # e.g. discovery add discovery_bonjour bonjour<BR>
&gt; # figure out my IP address<BR>
&gt; set my_disco_ip [regexp -inline =
{\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}} [exec<BR>
&gt; /sbin/ifconfig ath0] ]<BR>
&gt;<BR>
&gt; discovery add discovery_test ip port=3D2000 =
addr=3D192.168.10.255<BR>
&gt; discovery announce name discovery_test udp interval=3D5 =
cl_addr=3D$my_disco_ip<BR>
&gt; ########################################<BR>
&gt; #<BR>
&gt; # Parameter Tuning<BR>
&gt; #<BR>
&gt; ########################################<BR>
&gt;<BR>
&gt; #<BR>
&gt; # Set the size threshold for the daemon so any bundles smaller than =
this<BR>
&gt; # size maintain a shadow copy in memory to minimize disk =
accesses.<BR>
&gt; #<BR>
&gt; # param set payload_mem_threshold 16384<BR>
&gt;<BR>
&gt; #<BR>
&gt; # Test option to keep all bundle files in the filesystem, even =
after the<BR>
&gt; # bundle is no longer present at the daemon.<BR>
&gt; #<BR>
&gt; # param set payload_test_no_remove true<BR>
&gt;<BR>
&gt; #<BR>
&gt; # Set the size for which the tcp convergence layer sends partial =
reception<BR>
&gt; # acknowledgements. Used with reactive fragmentation<BR>
&gt; #<BR>
&gt; # param set tcpcl_partial_ack_len 4096<BR>
&gt;<BR>
&gt; #<BR>
&gt; # Set if bundles are automatically deleted after transmission<BR>
&gt; #<BR>
&gt; # param set early_deletion true<BR>
&gt;<BR>
&gt; # (others exist but are not fully represented here)<BR>
&gt;<BR>
&gt; log /dtnd info &quot;dtnd configuration parsing complete&quot;<BR>
&gt;<BR>
&gt; ## emacs settings to use tcl-mode by default<BR>
&gt; ## Local Variables: ***<BR>
&gt; ## mode:tcl ***<BR>
&gt; ## End: ***<BR>
&gt;<BR>
&gt;<BR>
&gt; _______________________________________________<BR>
&gt; dtn-users mailing list<BR>
&gt; dtn-users@maillists.intel-research.net<BR>
&gt; <A =
HREF=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-users">h=
ttp://maillists.intel-research.net/mailman/listinfo/dtn-users</A><BR>
&gt;<BR>
_______________________________________________<BR>
dtn-users mailing list<BR>
dtn-users@maillists.intel-research.net<BR>
<A =
HREF=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-users">h=
ttp://maillists.intel-research.net/mailman/listinfo/dtn-users</A><BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C934D9.BBF20CA9--


Received: from mail-gx0-f19.google.com (mail-gx0-f19.google.com [209.85.217.19]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9MMKCdR023484 for <dtn-users@maillists.intel-research.net>; Wed, 22 Oct 2008 15:20:13 -0700
Received: by gxk12 with SMTP id 12so286927gxk.10 for <dtn-users@maillists.intel-research.net>; Wed, 22 Oct 2008 15:12:39 -0700 (PDT)
Received: by 10.142.155.4 with SMTP id c4mr4615187wfe.9.1224713558896; Wed, 22 Oct 2008 15:12:38 -0700 (PDT)
Received: by 10.143.10.11 with HTTP; Wed, 22 Oct 2008 15:12:38 -0700 (PDT)
Message-ID: <59e8babf0810221512m7c9e73fbs37e9e719db64a18b@mail.gmail.com>
Date: Wed, 22 Oct 2008 15:12:38 -0700
From: "Michael Demmer" <demmer@cs.berkeley.edu>
Sender: demmer@gmail.com
To: jkseast@cs.umd.edu
In-Reply-To: <57811.65.127.220.45.1224712870.squirrel@webmail.cs.umd.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <57811.65.127.220.45.1224712870.squirrel@webmail.cs.umd.edu>
X-Google-Sender-Auth: 55fc08c2b89a5e7d
Cc: dtn-users@maillists.intel-research.net
Subject: Re: [dtn-users] UDP Question
X-BeenThere: dtn-users@maillists.intel-research.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: dtn-users mailing list <dtn-users.maillists.intel-research.net>
List-Unsubscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=unsubscribe>
List-Archive: <http://maillists.intel-research.net/pipermail/dtn-users>
List-Post: <mailto:dtn-users@maillists.intel-research.net>
List-Help: <mailto:dtn-users-request@maillists.intel-research.net?subject=help>
List-Subscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=subscribe>
X-List-Received-Date: Wed, 22 Oct 2008 22:20:13 -0000

Currently the only way to get reliability when using UDP is to use
custody transfer.

-m

On Wed, Oct 22, 2008 at 3:01 PM,  <jkseast@cs.umd.edu> wrote:
> I'd like some help with reliable bundle transfer with udp.
>
> Q1: I've configured dtnd to discover wireless nodes that come within range
> and to use udp. When nodes are discovered, I notice the links are added
> and udp state=OPEN. However, when the wireless nodes are moved out of
> range, the state never changes. Should the state change to UNAVAILABLE?
> (it does change with TCP).
>
> Q2: A bundle is marked as transmitted and deleted from the bundle list
> even when the recv node is out of range. However, the recv node does not
> indicate a received bundle in its bundle list. I would like to add
> reliability and for the bundle to remain in a pending status until it is
> recvd at the dtn layer. Is there a config param I can set to ensure
> reliability when using a UDP convergence layer?
>
> Config file below.
>
> #
> # dtn.conf
> #
> # Default configuration file for Internet-connected DTN nodes. The
> # daemon uses a tcl interpreter to parse this file, thus any standard
> # tcl commands are valid, and all settings are get/set using a single
> # 'set' functions as: <module> set <var> <val?>
> #
>
> log /dtnd info "dtnd parsing configuration..."
>
> ########################################
> #
> # Daemon Console Configuration
> #
> ########################################
>
> #
> # console set stdio [ true | false ]
> #
> # If set to false, disable the interactive console on stdin/stdout.
> # The default is set to true (unless the dtnd process is run as a
> # daemon).
> #
> # console set stdio false
>
> #
> # console set addr <port>
> # console set port <port>
> #
> # Settings for the socket based console protocol.
> # (this interprets user commands)
> #
> console set addr 127.0.0.1
> console set port 5050
>
> #
> # console set prompt <prompt>
> #
> # Set the prompt string.  Helps if running multiple dtnd's
> #
> set shorthostname [lindex [split [info hostname] .] 0]
> console set prompt "$shorthostname dtn% "
>
> ########################################
> #
> # Storage Configuration
> #
> ########################################
>
> #
> # storage set type [ berkeleydb | postgres | mysql  | external ]
> #
> # Set the storage system to be used
> #
> storage set type berkeleydb
>
> # the following are for use with external data stores
> #
> # The server port to connect to (on localhost)
> # Note that 62345 has no special significance -- chosen randomly
> storage set server_port 62345
>
> # The external data store schema location, which can be
> # found in dtn2/oasys/storage/DS.xsd.
> storage set schema /etc/DS.xsd
>
>
> #
> # Do a runtime check for the standard locations for the persistent
> # storage directory
> #
> set dbdir ""
> foreach dir {/var/dtn /var/tmp/dtn} {
>    if {[file isdirectory $dir]} {
>        set dbdir $dir
>        break
>    }
> }
>
> if {$dbdir == ""} {
>    puts stderr "Must create /var/dtn or /var/tmp/dtn storage directory"
>    exit 1
> }
>
> #
> # storage set payloaddir <dir>
> #
> # Set the directory to be used for bundle payload files
> #
> storage set payloaddir $dbdir/bundles
>
> #
> # storage set dbname <db>
> #
> # Set the database name (appended with .db as the filename in berkeley
> # db, used as-is for SQL variants
> #
> storage set dbname     DTN
>
> #
> # storage set dbdir    <dir>
> #
> #
> # When using berkeley db, set the directory to be used for the
> # database files and the name of the files and error log.
> #
> storage set dbdir      $dbdir/db
>
> ########################################
> #
> # Routing configuration
> #
> ########################################
>
> #
> # Set the algorithm used for dtn routing.
> #
> # route set type [static | flood | neighborhood | linkstate | external]
> #
> route set type static
>
> #
> # route local_eid <eid>
> #
> # Set the local administrative id of this node. The default just uses
> # the internet hostname plus the appended string ".dtn" to make it
> # clear that the hostname isn't really used for DNS lookups.
> #
> route local_eid "dtn://[info hostname].dtn"
>
> #
> # External router specific options
> #
> # route set server_port 8001
> # route set hello_interval 30
> route set add_nexthop_routes true
> route set open_discovered_links true
> route set hello_interval 10
> # route set schema "/etc/router.xsd"
>
> ########################################
> #
> # TCP convergence layer configuration
> #
> ########################################
>
> #
> # interface add [name] [CL]
> #
> # Add an input interface to listen on addr:port for incoming bundles
> # from other tcp / udp convergence layers
> #
> # For IP-based interfaces, interfaces listen on INADDR_ANY port 4556
> # by default. These can be overridden by using the local_addr and/or
> # local_port arguments.
> interface add tcp0 tcp
> interface add udp0 udp
> #interface add tcp0 tcp local_port=4556
> #interface add udp0 udp local_port=4557
>
> #
> # link add <name> <nexthop> <type> <clayer> <args...>
> #
> # Add a link to a peer node.
> #
> # For IP-based links (tcp or udp), the nexthop should contain a DNS
> # hostname or IP address, followed optionally by a : and a port. If
> # the port is not specified, the default of 4556 is used.
> #
> # e.g.  link add link1 dtn.dtnrg.org ONDEMAND tcp
> #       link add link2 dtn2.dtnrg.org:10000 ONDEMAND tcp
>
> #link add link_tcp 192.168.10.2:4456 ONDEMAND tcp
> #link add link_udp 192.168.10.2:4557 ONDEMAND udp
>
> #
> # route add <dest> <link|peer>
> #
> # Add a route to the given bundle endpoint id pattern <dest> using the
> # specified link name or peer endpoint.
> #
> # e.g. route add dtn://host.domain/* tcp0
>
> #route add dtn://node1-2.grid.lts.org.dtn/* link_tcp
> #route add dtn://node1-2.grid.lts.org.dtn/* link_udp
>
> ########################################
> #
> # Service discovery
> #
> ########################################
>
> #
> # discovery add <name> <af> <opts...>
> # discovery announce <cl_name> <discovery_name> <cl_type> <opts...>
> #
> # Add a local neighborhood discovery module
> #
> # e.g. discovery add discovery_bonjour bonjour
> # figure out my IP address
> set my_disco_ip [regexp -inline {\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}} [exec
> /sbin/ifconfig ath0] ]
>
> discovery add discovery_test ip port=2000 addr=192.168.10.255
> discovery announce name discovery_test udp interval=5 cl_addr=$my_disco_ip
> ########################################
> #
> # Parameter Tuning
> #
> ########################################
>
> #
> # Set the size threshold for the daemon so any bundles smaller than this
> # size maintain a shadow copy in memory to minimize disk accesses.
> #
> # param set payload_mem_threshold 16384
>
> #
> # Test option to keep all bundle files in the filesystem, even after the
> # bundle is no longer present at the daemon.
> #
> # param set payload_test_no_remove true
>
> #
> # Set the size for which the tcp convergence layer sends partial reception
> # acknowledgements. Used with reactive fragmentation
> #
> # param set tcpcl_partial_ack_len 4096
>
> #
> # Set if bundles are automatically deleted after transmission
> #
> # param set early_deletion true
>
> # (others exist but are not fully represented here)
>
> log /dtnd info "dtnd configuration parsing complete"
>
> ## emacs settings to use tcl-mode by default
> ## Local Variables: ***
> ## mode:tcl ***
> ## End: ***
>
>
> _______________________________________________
> dtn-users mailing list
> dtn-users@maillists.intel-research.net
> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>


Received: from bacon.cs.umd.edu (server-nat-4.cs.umd.edu [128.8.127.147]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9MM8iTg022953 for <dtn-users@maillists.intel-research.net>; Wed, 22 Oct 2008 15:08:44 -0700
X-CSD-MailScanner-Watermark: 1225317671.46495@6F+NW6H6c/qFccdDQL6ovw
Received: from webmail.cs.umd.edu (newman.cs.umd.edu [172.24.0.4]) by bacon.cs.umd.edu (8.13.1/8.14.1) with ESMTP id m9MM19oH012068 for <dtn-users@maillists.intel-research.net>; Wed, 22 Oct 2008 18:01:10 -0400
Received: from 65.127.220.45 (SquirrelMail authenticated user jkseast) by webmail.cs.umd.edu with HTTP; Wed, 22 Oct 2008 18:01:10 -0400 (EDT)
Message-ID: <57811.65.127.220.45.1224712870.squirrel@webmail.cs.umd.edu>
Date: Wed, 22 Oct 2008 18:01:10 -0400 (EDT)
From: jkseast@cs.umd.edu
To: dtn-users@maillists.intel-research.net
User-Agent: SquirrelMail/1.4.10a
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (bacon.cs.umd.edu [172.24.3.34]); Wed, 22 Oct 2008 18:01:10 -0400 (EDT)
Subject: [dtn-users] UDP Question
X-BeenThere: dtn-users@maillists.intel-research.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: dtn-users mailing list <dtn-users.maillists.intel-research.net>
List-Unsubscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=unsubscribe>
List-Archive: <http://maillists.intel-research.net/pipermail/dtn-users>
List-Post: <mailto:dtn-users@maillists.intel-research.net>
List-Help: <mailto:dtn-users-request@maillists.intel-research.net?subject=help>
List-Subscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=subscribe>
X-List-Received-Date: Wed, 22 Oct 2008 22:08:45 -0000

I'd like some help with reliable bundle transfer with udp.

Q1: I've configured dtnd to discover wireless nodes that come within range
and to use udp. When nodes are discovered, I notice the links are added
and udp state=OPEN. However, when the wireless nodes are moved out of
range, the state never changes. Should the state change to UNAVAILABLE?
(it does change with TCP).

Q2: A bundle is marked as transmitted and deleted from the bundle list
even when the recv node is out of range. However, the recv node does not
indicate a received bundle in its bundle list. I would like to add
reliability and for the bundle to remain in a pending status until it is
recvd at the dtn layer. Is there a config param I can set to ensure
reliability when using a UDP convergence layer?

Config file below.

#
# dtn.conf
#
# Default configuration file for Internet-connected DTN nodes. The
# daemon uses a tcl interpreter to parse this file, thus any standard
# tcl commands are valid, and all settings are get/set using a single
# 'set' functions as: <module> set <var> <val?>
#

log /dtnd info "dtnd parsing configuration..."

########################################
#
# Daemon Console Configuration
#
########################################

#
# console set stdio [ true | false ]
#
# If set to false, disable the interactive console on stdin/stdout.
# The default is set to true (unless the dtnd process is run as a
# daemon).
#
# console set stdio false

#
# console set addr <port>
# console set port <port>
#
# Settings for the socket based console protocol.
# (this interprets user commands)
#
console set addr 127.0.0.1
console set port 5050

#
# console set prompt <prompt>
#
# Set the prompt string.  Helps if running multiple dtnd's
#
set shorthostname [lindex [split [info hostname] .] 0]
console set prompt "$shorthostname dtn% "

########################################
#
# Storage Configuration
#
########################################

#
# storage set type [ berkeleydb | postgres | mysql  | external ]
#
# Set the storage system to be used
#
storage set type berkeleydb

# the following are for use with external data stores
#
# The server port to connect to (on localhost)
# Note that 62345 has no special significance -- chosen randomly
storage set server_port 62345

# The external data store schema location, which can be
# found in dtn2/oasys/storage/DS.xsd.
storage set schema /etc/DS.xsd


#
# Do a runtime check for the standard locations for the persistent
# storage directory
#
set dbdir ""
foreach dir {/var/dtn /var/tmp/dtn} {
    if {[file isdirectory $dir]} {
        set dbdir $dir
        break
    }
}

if {$dbdir == ""} {
    puts stderr "Must create /var/dtn or /var/tmp/dtn storage directory"
    exit 1
}

#
# storage set payloaddir <dir>
#
# Set the directory to be used for bundle payload files
#
storage set payloaddir $dbdir/bundles

#
# storage set dbname <db>
#
# Set the database name (appended with .db as the filename in berkeley
# db, used as-is for SQL variants
#
storage set dbname     DTN

#
# storage set dbdir    <dir>
#
#
# When using berkeley db, set the directory to be used for the
# database files and the name of the files and error log.
#
storage set dbdir      $dbdir/db

########################################
#
# Routing configuration
#
########################################

#
# Set the algorithm used for dtn routing.
#
# route set type [static | flood | neighborhood | linkstate | external]
#
route set type static

#
# route local_eid <eid>
#
# Set the local administrative id of this node. The default just uses
# the internet hostname plus the appended string ".dtn" to make it
# clear that the hostname isn't really used for DNS lookups.
#
route local_eid "dtn://[info hostname].dtn"

#
# External router specific options
#
# route set server_port 8001
# route set hello_interval 30
route set add_nexthop_routes true
route set open_discovered_links true
route set hello_interval 10
# route set schema "/etc/router.xsd"

########################################
#
# TCP convergence layer configuration
#
########################################

#
# interface add [name] [CL]
#
# Add an input interface to listen on addr:port for incoming bundles
# from other tcp / udp convergence layers
#
# For IP-based interfaces, interfaces listen on INADDR_ANY port 4556
# by default. These can be overridden by using the local_addr and/or
# local_port arguments.
interface add tcp0 tcp
interface add udp0 udp
#interface add tcp0 tcp local_port=4556
#interface add udp0 udp local_port=4557

#
# link add <name> <nexthop> <type> <clayer> <args...>
#
# Add a link to a peer node.
#
# For IP-based links (tcp or udp), the nexthop should contain a DNS
# hostname or IP address, followed optionally by a : and a port. If
# the port is not specified, the default of 4556 is used.
#
# e.g.  link add link1 dtn.dtnrg.org ONDEMAND tcp
#       link add link2 dtn2.dtnrg.org:10000 ONDEMAND tcp

#link add link_tcp 192.168.10.2:4456 ONDEMAND tcp
#link add link_udp 192.168.10.2:4557 ONDEMAND udp

#
# route add <dest> <link|peer>
#
# Add a route to the given bundle endpoint id pattern <dest> using the
# specified link name or peer endpoint.
#
# e.g. route add dtn://host.domain/* tcp0

#route add dtn://node1-2.grid.lts.org.dtn/* link_tcp
#route add dtn://node1-2.grid.lts.org.dtn/* link_udp

########################################
#
# Service discovery
#
########################################

#
# discovery add <name> <af> <opts...>
# discovery announce <cl_name> <discovery_name> <cl_type> <opts...>
#
# Add a local neighborhood discovery module
#
# e.g. discovery add discovery_bonjour bonjour
# figure out my IP address
set my_disco_ip [regexp -inline {\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}} [exec
/sbin/ifconfig ath0] ]

discovery add discovery_test ip port=2000 addr=192.168.10.255
discovery announce name discovery_test udp interval=5 cl_addr=$my_disco_ip
########################################
#
# Parameter Tuning
#
########################################

#
# Set the size threshold for the daemon so any bundles smaller than this
# size maintain a shadow copy in memory to minimize disk accesses.
#
# param set payload_mem_threshold 16384

#
# Test option to keep all bundle files in the filesystem, even after the
# bundle is no longer present at the daemon.
#
# param set payload_test_no_remove true

#
# Set the size for which the tcp convergence layer sends partial reception
# acknowledgements. Used with reactive fragmentation
#
# param set tcpcl_partial_ack_len 4096

#
# Set if bundles are automatically deleted after transmission
#
# param set early_deletion true

# (others exist but are not fully represented here)

log /dtnd info "dtnd configuration parsing complete"

## emacs settings to use tcl-mode by default
## Local Variables: ***
## mode:tcl ***
## End: ***




Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.249]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9LESuR3001120 for <dtn-users@maillists.intel-research.net>; Tue, 21 Oct 2008 07:28:56 -0700
Received: by rv-out-0708.google.com with SMTP id c5so2012250rvf.34 for <dtn-users@maillists.intel-research.net>; Tue, 21 Oct 2008 07:21:58 -0700 (PDT)
Received: by 10.141.206.13 with SMTP id i13mr5704501rvq.100.1224598918790; Tue, 21 Oct 2008 07:21:58 -0700 (PDT)
Received: by 10.141.37.3 with HTTP; Tue, 21 Oct 2008 07:21:58 -0700 (PDT)
Message-ID: <6c3baadf0810210721x1e39369bn3d95b897fc9b826d@mail.gmail.com>
Date: Tue, 21 Oct 2008 09:21:58 -0500
From: "Paul Edelman" <paul.edelman@gmail.com>
To: dtn-users <dtn-users@maillists.intel-research.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_3713_20604440.1224598918792"
Subject: [dtn-users] Building on top of DTN
X-BeenThere: dtn-users@maillists.intel-research.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: dtn-users mailing list <dtn-users.maillists.intel-research.net>
List-Unsubscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=unsubscribe>
List-Archive: <http://maillists.intel-research.net/pipermail/dtn-users>
List-Post: <mailto:dtn-users@maillists.intel-research.net>
List-Help: <mailto:dtn-users-request@maillists.intel-research.net?subject=help>
List-Subscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=subscribe>
X-List-Received-Date: Tue, 21 Oct 2008 14:28:56 -0000

------=_Part_3713_20604440.1224598918792
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hello all,

My name is Paul Edelman.  I am a masters candidate with the department of
computer science at Baylor University.  I originally posted this message in
dtn-interest.  After review dtn-users and with the 2.6.0 release I still
have the same questions I originally posted.  We are looking at doing some
research / project work using the DTN reference implementation, specifically
building on top of DTN or even modifying DTN for the purposes of
experimentation.  For some time now I have been going through the available
publications including the latest architectural retrospective, available
release documents, the DTN manual, the mailing lists, as well as the wiki.
Despite all of that I still have a few questions.


   1. The DTN daemon configuration file (dtnd.conf) lists support for the
   following routing algorithms: static, flood, neighborhood, linkstate, and
   external.  What routing protocols are currently mature in the
   implementation?   For these protocols where might I find specific
   documentation?

   2. Does support for Prophet routing still exist?

   3. What is the best source of information for a developer new to the
   reference implementation?

   4. In practice what is the state of the reference implementation, and how
   is it currently being used?


Really what I am looking for is how we can practically use the DTN reference
implementation, where the items listed above are our core questions.  Thank
you very much for your time.

Sincerely,

*Paul Edelman*
Department of Computer Science
Baylor University
paul_edelman@baylor.edu
 paul.edelman@gmail.com

------=_Part_3713_20604440.1224598918792
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div dir="ltr">Hello all,<br><br>My name is Paul Edelman.&nbsp; I am a masters candidate
with the department of computer science at Baylor University.&nbsp; I originally posted this message in dtn-interest.&nbsp; After review dtn-users and with the 2.6.0 release I still have the same questions I originally posted.&nbsp; We are
looking at doing some research / project work using the DTN reference
implementation, specifically building on top of DTN or even modifying
DTN for the purposes of experimentation.&nbsp; For some time now I have been
going through the available publications including the latest
architectural retrospective, available release documents, the DTN
manual, the mailing lists, as well as the wiki.&nbsp; Despite all of that I still have a few
questions.<br>

<br><ol><li>The DTN daemon configuration file (dtnd.conf) lists support
for the following routing algorithms: static, flood, neighborhood,
linkstate, and external.&nbsp; What routing protocols are currently mature
in the implementation?&nbsp;&nbsp; For these protocols where might I find
specific documentation?<br>
<br></li><li>Does support for Prophet routing still exist?<br><br></li><li>What is the best source of information for a developer new to the reference implementation?<br><br></li><li>In practice what is the state of the reference implementation, and how is it currently being used?<br>





<br></li></ol>Really what I am looking for is how we can practically
use the DTN reference implementation, where the items listed above are
our core questions.&nbsp; Thank you very much for your time.<br><br>Sincerely,<br><br>
<b>Paul Edelman</b><br>Department of Computer Science<br>Baylor University<br><span style="color: rgb(51, 102, 255);"><a href="mailto:paul_edelman@baylor.edu" target="_blank">paul_edelman@baylor.edu</a></span><br style="color: rgb(51, 102, 255);">



<font color="#888888">

<span style="color: rgb(51, 102, 255);"><a href="mailto:paul.edelman@gmail.com" target="_blank">paul.edelman@gmail.com</a></span></font></div>

------=_Part_3713_20604440.1224598918792--


Received: from mail-gx0-f19.google.com (mail-gx0-f19.google.com [209.85.217.19]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9HE9pLX001637 for <dtn-users@maillists.intel-research.net>; Fri, 17 Oct 2008 07:09:51 -0700
Received: by gxk12 with SMTP id 12so1031588gxk.10 for <dtn-users@maillists.intel-research.net>; Fri, 17 Oct 2008 07:04:40 -0700 (PDT)
Received: by 10.65.241.20 with SMTP id t20mr967728qbr.62.1224252279627; Fri, 17 Oct 2008 07:04:39 -0700 (PDT)
Received: from geefour.baylor.edu (geefour.baylor.edu [129.62.45.219]) by mx.google.com with ESMTPS id k30sm1611010qba.4.2008.10.17.07.04.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 17 Oct 2008 07:04:38 -0700 (PDT)
Message-Id: <DEC89BF3-E219-430C-A0C3-16E81551BD12@cs.baylor.edu>
From: Jeff Wilson <wilsonj@cs.ecs.baylor.edu>
To: dtn-users@maillists.intel-research.net
In-Reply-To: <C3CE8BCC8091468184A04A358A72CE73@black.nurc.nato.int>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Fri, 17 Oct 2008 09:04:36 -0500
References: <C3CE8BCC8091468184A04A358A72CE73@black.nurc.nato.int>
X-Mailer: Apple Mail (2.929.2)
Sender: Jeff Wilson <jazzbotley@gmail.com>
Subject: Re: [dtn-users] Strange behavior of discovery module.
X-BeenThere: dtn-users@maillists.intel-research.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: dtn-users mailing list <dtn-users.maillists.intel-research.net>
List-Unsubscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=unsubscribe>
List-Archive: <http://maillists.intel-research.net/pipermail/dtn-users>
List-Post: <mailto:dtn-users@maillists.intel-research.net>
List-Help: <mailto:dtn-users-request@maillists.intel-research.net?subject=help>
List-Subscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=subscribe>
X-List-Received-Date: Fri, 17 Oct 2008 14:09:54 -0000

It is the correct behavior for this implementation, as currently  
defined.  You describe a scenario that I did not consider in the  
original design.  But now that you mention it, is this a problem?  One  
thing to consider is hold-time to prevent link flapping.  If a peer  
"goes away", is it permanent?  Or just a delay in responding to a keep- 
alive, something that this network should tolerate?

	Regards,
	Jeff


On Oct 17, 2008, at 8:29 AM, Massimo Gaggero wrote:

> Hello,
> 	I've noticed a strange behavior of both the ip and the bonjour
> discovery module.
> I put the following lines to my dtn.conf in order to make the DTN  
> node able
> to discover other neighbors (in two of the different subnets where I  
> have a
> NIC):
>
> discovery add ipdisc0 ip port=6789 addr=192.168.110.255
> discovery announce announce-udp0 ipdisc0 udp interval=30
>
> discovery add ipdisc1 ip port=6789 addr=192.168.100.255
> discovery announce announce-udp1 ipdisc1 udp interval=30
>
> When a new DTN node is added to the network, the discovery module  
> discovers
> and adds it to the link list, as a 'route dump' can show.
>
> But if a node is disconnected or changes subnet, the link still  
> remains in
> the list.
>
> Is the correct behavior? It's a configuration error? There are  
> params to
> set?
>
> Thank you,
> 	Massimo.
>
>
>
> *** PRIVILEGED AND CONFIDENTIAL ***
> The information contained in this e-mail message (including any  
> attached files)
> is intended for the use of the addressee(s) only and is privileged  
> information.
> The information should neither be posted to the Internet, nor  
> published in any
> other public domain, without the express permission of the sender.  
> If you are
> not the intended recipient(s) or the recipient's representative, you  
> are hereby
> notified that any use, disclosure, copying or distribution of this  
> communication
> is prohibited. If you have received this communication in error  
> please notify us
> immediately at postmaster@nurc.nato.int and remove this message from
> your system.
> _______________________________________________
> dtn-users mailing list
> dtn-users@maillists.intel-research.net
> http://maillists.intel-research.net/mailman/listinfo/dtn-users



Received: from thin4.nurc.nato.int (mail-b.nurc.nato.int [192.106.197.23]) by maillists.intel-research.net (8.13.8/8.13.8) with SMTP id m9HDYCfn032503 for <dtn-users@maillists.intel-research.net>; Fri, 17 Oct 2008 06:34:13 -0700
Received: from (unknown [172.19.172.27]) by thin4.nurc.nato.int with smtp id 1e4e_8e2bdb40_9c4f_11dd_9ebe_0014221726c4; Fri, 17 Oct 2008 15:28:59 +0200
Received: from dxp16670 ([172.19.96.83]) by slx15796.saclantc.nato.int (Switch-3.1.9/Switch-3.1.9) with ESMTP id m9HDSvEg021734 for <dtn-users@maillists.intel-research.net>; Fri, 17 Oct 2008 15:28:58 +0200
From: "Massimo Gaggero" <gaggero@nurc.nato.int>
To: <dtn-users@maillists.intel-research.net>
Date: Fri, 17 Oct 2008 15:29:01 +0200
Organization: N.U.R.C. - NATO Undersea Research Centre
Message-ID: <C3CE8BCC8091468184A04A358A72CE73@black.nurc.nato.int>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AckwXFFKEKEIa1wxT96YyAmGnmrciw==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-MASF: 0%
X-NAIMIME-Disclaimer: 1
X-NAIMIME-Modified: 1
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: [dtn-users] Strange behavior of discovery module.
X-BeenThere: dtn-users@maillists.intel-research.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: dtn-users mailing list <dtn-users.maillists.intel-research.net>
List-Unsubscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=unsubscribe>
List-Archive: <http://maillists.intel-research.net/pipermail/dtn-users>
List-Post: <mailto:dtn-users@maillists.intel-research.net>
List-Help: <mailto:dtn-users-request@maillists.intel-research.net?subject=help>
List-Subscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=subscribe>
X-List-Received-Date: Fri, 17 Oct 2008 13:34:14 -0000

Hello,
	I've noticed a strange behavior of both the ip and the bonjour
discovery module.
I put the following lines to my dtn.conf in order to make the DTN node able
to discover other neighbors (in two of the different subnets where I have a
NIC):

discovery add ipdisc0 ip port=6789 addr=192.168.110.255
discovery announce announce-udp0 ipdisc0 udp interval=30

discovery add ipdisc1 ip port=6789 addr=192.168.100.255
discovery announce announce-udp1 ipdisc1 udp interval=30

When a new DTN node is added to the network, the discovery module discovers
and adds it to the link list, as a 'route dump' can show.

But if a node is disconnected or changes subnet, the link still remains in
the list.

Is the correct behavior? It's a configuration error? There are params to
set?

Thank you,
	Massimo.



*** PRIVILEGED AND CONFIDENTIAL ***
The information contained in this e-mail message (including any attached files)
is intended for the use of the addressee(s) only and is privileged information.
The information should neither be posted to the Internet, nor published in any
other public domain, without the express permission of the sender. If you are
not the intended recipient(s) or the recipient's representative, you are hereby
notified that any use, disclosure, copying or distribution of this communication
is prohibited. If you have received this communication in error please notify us
immediately at postmaster@nurc.nato.int and remove this message from 
your system.


Received: from blu0-omc2-s16.blu0.hotmail.com (blu0-omc2-s16.blu0.hotmail.com [65.55.111.91]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m96LdKbM015560 for <dtn-users@maillists.intel-research.net>; Mon, 6 Oct 2008 14:39:21 -0700
Received: from BLU144-W40 ([65.55.111.72]) by blu0-omc2-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 6 Oct 2008 14:38:49 -0700
Message-ID: <BLU144-W40252CC301F16C7AF95DD2DA390@phx.gbl>
Content-Type: multipart/alternative; boundary="_b9e90222-7c79-4d93-9214-2d236a7df8b1_"
X-Originating-IP: [41.200.139.108]
From: Asma Simsima <benasini@hotmail.com>
To: <dtn-users@maillists.intel-research.net>
Date: Mon, 6 Oct 2008 21:38:49 +0000
Importance: Normal
In-Reply-To: <mailman.3.1223319602.8310.dtn-users@maillists.intel-research.net>
References: <mailman.3.1223319602.8310.dtn-users@maillists.intel-research.net>
MIME-Version: 1.0
X-OriginalArrivalTime: 06 Oct 2008 21:38:49.0103 (UTC) FILETIME=[EB1471F0:01C927FB]
Subject: Re: [dtn-users] dtn-users Digest, Vol 13, Issue 1
X-BeenThere: dtn-users@maillists.intel-research.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: dtn-users mailing list <dtn-users.maillists.intel-research.net>
List-Unsubscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=unsubscribe>
List-Archive: <http://maillists.intel-research.net/pipermail/dtn-users>
List-Post: <mailto:dtn-users@maillists.intel-research.net>
List-Help: <mailto:dtn-users-request@maillists.intel-research.net?subject=help>
List-Subscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=subscribe>
X-List-Received-Date: Mon, 06 Oct 2008 21:39:21 -0000

--_b9e90222-7c79-4d93-9214-2d236a7df8b1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi =2C=20

I had the same error and the solution is that you need to add a #include of=
 <sys/types.h> to oasys/util/SafeRange.h

hope it will work also for you=20

good luck=20

Asma

> From: dtn-users-request@maillists.intel-research.net
> Subject: dtn-users Digest=2C Vol 13=2C Issue 1
> To: dtn-users@maillists.intel-research.net
> Date: Mon=2C 6 Oct 2008 12:00:02 -0700
>=20
> Send dtn-users mailing list submissions to
> 	dtn-users@maillists.intel-research.net
>=20
> To subscribe or unsubscribe via the World Wide Web=2C visit
> 	http://maillists.intel-research.net/mailman/listinfo/dtn-users
> or=2C via email=2C send a message with subject or body 'help' to
> 	dtn-users-request@maillists.intel-research.net
>=20
> You can reach the person managing the list at
> 	dtn-users-owner@maillists.intel-research.net
>=20
> When replying=2C please edit your Subject line so it is more specific
> than "Re: Contents of dtn-users digest..."
>=20
>=20
> Today's Topics:
>=20
>    1. Error compiling on Ubuntu 8.04 (Teemu)
>=20
>=20
> ----------------------------------------------------------------------
>=20
> Message: 1
> Date: Mon=2C 06 Oct 2008 17:30:08 +0300
> From: Teemu <teemuk@netlab.tkk.fi>
> Subject: [dtn-users] Error compiling on Ubuntu 8.04
> To: dtn-users mailing list <dtn-users@mailman.dtnrg.org>
> Message-ID: <48EA20F0.4050406@netlab.tkk.fi>
> Content-Type: text/plain=3B charset=3Dwindows-1252=3B format=3Dflowed
>=20
> Hi=2C
>=20
> compiling dtn-2.6.0 release version fails on a fresh install of Ubuntu 8.=
04:
>=20
> > In file included from bundling/SequenceID.cc:22:
> > ../oasys/util/SafeRange.h:35: error: expected `)' before ?offset?
> > ../oasys/util/SafeRange.h:36: error: ?size_t? does not name a type
> > ../oasys/util/SafeRange.h:39: error: ?size_t? has not been declared
>  > ...
>=20
> A quick fix was to add
> #include <sys/types.h>
> in oasys/util/SafeRange.h
>=20
> Cheers=2C
> -Teemu
>=20
>=20
> ------------------------------
>=20
> _______________________________________________
> dtn-users mailing list
> dtn-users@maillists.intel-research.net
> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>=20
>=20
> End of dtn-users Digest=2C Vol 13=2C Issue 1
> ****************************************

_________________________________________________________________
Lancez des recherches en toute s=E9curit=E9 depuis n'importe quelle page We=
b. T=E9l=E9chargez GRATUITEMENT Windows Live Toolbar aujourd'hui !
http://toolbar.live.com=

--_b9e90222-7c79-4d93-9214-2d236a7df8b1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt=3B
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'><div style=3D"text-align: left=3B">Hi =2C <br><br=
>I had the same error and the solution is that you need to add a #include o=
f &lt=3Bsys/types.h&gt=3B to oasys/util/SafeRange.h<br><br>hope it will wor=
k also for you <br><br>good luck <br></div><br>Asma<br><br><hr id=3D"stopSp=
elling">&gt=3B From: dtn-users-request@maillists.intel-research.net<br>&gt=
=3B Subject: dtn-users Digest=2C Vol 13=2C Issue 1<br>&gt=3B To: dtn-users@=
maillists.intel-research.net<br>&gt=3B Date: Mon=2C 6 Oct 2008 12:00:02 -07=
00<br>&gt=3B <br>&gt=3B Send dtn-users mailing list submissions to<br>&gt=
=3B 	dtn-users@maillists.intel-research.net<br>&gt=3B <br>&gt=3B To subscri=
be or unsubscribe via the World Wide Web=2C visit<br>&gt=3B 	http://maillis=
ts.intel-research.net/mailman/listinfo/dtn-users<br>&gt=3B or=2C via email=
=2C send a message with subject or body 'help' to<br>&gt=3B 	dtn-users-requ=
est@maillists.intel-research.net<br>&gt=3B <br>&gt=3B You can reach the per=
son managing the list at<br>&gt=3B 	dtn-users-owner@maillists.intel-researc=
h.net<br>&gt=3B <br>&gt=3B When replying=2C please edit your Subject line s=
o it is more specific<br>&gt=3B than "Re: Contents of dtn-users digest..."<=
br>&gt=3B <br>&gt=3B <br>&gt=3B Today's Topics:<br>&gt=3B <br>&gt=3B    1. =
Error compiling on Ubuntu 8.04 (Teemu)<br>&gt=3B <br>&gt=3B <br>&gt=3B ----=
------------------------------------------------------------------<br>&gt=
=3B <br>&gt=3B Message: 1<br>&gt=3B Date: Mon=2C 06 Oct 2008 17:30:08 +0300=
<br>&gt=3B From: Teemu &lt=3Bteemuk@netlab.tkk.fi&gt=3B<br>&gt=3B Subject: =
[dtn-users] Error compiling on Ubuntu 8.04<br>&gt=3B To: dtn-users mailing =
list &lt=3Bdtn-users@mailman.dtnrg.org&gt=3B<br>&gt=3B Message-ID: &lt=3B48=
EA20F0.4050406@netlab.tkk.fi&gt=3B<br>&gt=3B Content-Type: text/plain=3B ch=
arset=3Dwindows-1252=3B format=3Dflowed<br>&gt=3B <br>&gt=3B Hi=2C<br>&gt=
=3B <br>&gt=3B compiling dtn-2.6.0 release version fails on a fresh install=
 of Ubuntu 8.04:<br>&gt=3B <br>&gt=3B &gt=3B In file included from bundling=
/SequenceID.cc:22:<br>&gt=3B &gt=3B ../oasys/util/SafeRange.h:35: error: ex=
pected `)' before ?offset?<br>&gt=3B &gt=3B ../oasys/util/SafeRange.h:36: e=
rror: ?size_t? does not name a type<br>&gt=3B &gt=3B ../oasys/util/SafeRang=
e.h:39: error: ?size_t? has not been declared<br>&gt=3B  &gt=3B ...<br>&gt=
=3B <br>&gt=3B A quick fix was to add<br>&gt=3B #include &lt=3Bsys/types.h&=
gt=3B<br>&gt=3B in oasys/util/SafeRange.h<br>&gt=3B <br>&gt=3B Cheers=2C<br=
>&gt=3B -Teemu<br>&gt=3B <br>&gt=3B <br>&gt=3B ----------------------------=
--<br>&gt=3B <br>&gt=3B _______________________________________________<br>=
&gt=3B dtn-users mailing list<br>&gt=3B dtn-users@maillists.intel-research.=
net<br>&gt=3B http://maillists.intel-research.net/mailman/listinfo/dtn-user=
s<br>&gt=3B <br>&gt=3B <br>&gt=3B End of dtn-users Digest=2C Vol 13=2C Issu=
e 1<br>&gt=3B ****************************************<br><br /><hr />Discu=
tez gratuitement avec vos amis en vid=E9o !  <a href=3D'http://get.live.com=
/messenger/overview' target=3D'_new'>T=E9l=E9chargez Messenger=2C c'est gra=
tuit !</a></body>
</html>=

--_b9e90222-7c79-4d93-9214-2d236a7df8b1_--


Received: from smtp.netlab.hut.fi (keskus.netlab.hut.fi [130.233.154.176]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m96EUZF5028335 for <dtn-users@mailman.dtnrg.org>; Mon, 6 Oct 2008 07:30:36 -0700
Received: from [130.233.154.131] (vivaldi-1.netlab.hut.fi [130.233.154.131]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 20AFAC50EA for <dtn-users@mailman.dtnrg.org>; Mon,  6 Oct 2008 17:30:08 +0300 (EET DST)
Message-ID: <48EA20F0.4050406@netlab.tkk.fi>
Date: Mon, 06 Oct 2008 17:30:08 +0300
From: Teemu <teemuk@netlab.tkk.fi>
User-Agent: Thunderbird 2.0.0.17 (X11/20080925)
MIME-Version: 1.0
To: dtn-users mailing list <dtn-users@mailman.dtnrg.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: [dtn-users] Error compiling on Ubuntu 8.04
X-BeenThere: dtn-users@maillists.intel-research.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: dtn-users mailing list <dtn-users.maillists.intel-research.net>
List-Unsubscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=unsubscribe>
List-Archive: <http://maillists.intel-research.net/pipermail/dtn-users>
List-Post: <mailto:dtn-users@maillists.intel-research.net>
List-Help: <mailto:dtn-users-request@maillists.intel-research.net?subject=help>
List-Subscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@maillists.intel-research.net?subject=subscribe>
X-List-Received-Date: Mon, 06 Oct 2008 14:30:37 -0000

Hi,

compiling dtn-2.6.0 release version fails on a fresh install of Ubuntu 8.04:

> In file included from bundling/SequenceID.cc:22:
> ../oasys/util/SafeRange.h:35: error: expected `)' before ‘offset’
> ../oasys/util/SafeRange.h:36: error: ‘size_t’ does not name a type
> ../oasys/util/SafeRange.h:39: error: ‘size_t’ has not been declared
 > ...

A quick fix was to add
#include <sys/types.h>
in oasys/util/SafeRange.h

Cheers,
-Teemu