Subject: [dtn-interest] DARPA BAA04-13: Disruption Tolerant Networking (DTN)
From: Kevin Fall <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Fri, 28 May 2004 09:42:20 -0700
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

The DARPA DTN BAA has finally come out!  Full proposals are due to DARPA
by noon on 9-July-2004.

Here is a link, for those interested:

	http://www.eps.gov/spg/ODA/DARPA/CMO/BAA04%2D13/Attachments.html

- Kevin

From: "Josef Kriegl" <[email-masked]>
To: <[email-masked]>
Subject: Re: [dtn-interest] dynamic routes
Date: Thu, 20 May 2004 23:41:55 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_021F_01C43EC4.0893E9C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Robert,

interesting approach. like you said, knowing what the next best hop =
towards the destination is, requires some additional information. have =
you looked at using geographic routing approaches?

as a first cut i am going to make the (naive) assumption that at some =
point in the network's lifetime a full-end-to end route between 2 nodes =
existed, one or more links of which may (periodically) be down. with an =
appropriate route expiration timeout and DTN i would think that reliable =
message transfer could be possible. i realize that this approach does =
not solve the question 'what is the best next hop', and may also fail =
under certain circumstances (e.g. if only sections of the complete route =
exist at any given time).

have you looked at the bundle daemon's udp mangement interface to =
support dynamic route updates at all? Keith mentioned in one of his =
previous emails that this interface is incomplete, undocumented and =
unsupported at this point.

Josef
  ----- Original Message -----=20
  From: Robert C. Durst=20
  To: 'Josef Kriegl' ; [email-masked]=20
  Sent: Tuesday, May 18, 2004 6:16 PM
  Subject: RE: [dtn-interest] dynamic routes

  Josef,

  I, personally, am just starting to do this.  Am looking at running DTN =
over OLSR-based subnetworks.  I'm not yet to implementation, but am =
planning to consume the OLSR tables at the DTN layer, and to build some =
history to try to identify where good store-and-forward points would be, =
etc.  Have not yet thought too deeply about implementation, but plan to =
let OLSR do its thing, modifying the kernel routing table, and work DTN =
routing as an overlay, where I would pick a next-hop DTN endpoint that =
is not necessarily a next-hop OLSR endpoint.  Again, am just starting =
this.  Sorry it's still pretty squishy.

  Regards,
  Bob Durst

-------------------------------------------------------------------------=
---
    From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Josef Kriegl
    Sent: Tuesday, May 18, 2004 11:44 AM
    To: [email-masked]
    Subject: [dtn-interest] dynamic routes

    i notice that with the use of the /etc/bundles/route file routes =
between inter- and intraregion hosts have to be set up in a static =
manner.

    we are working with manet routers such as olsr and aodv over =
wireless links, which essentially employ an on-demand route discovery =
process to determine the route between any 2 nodes in the ad hoc =
network. links are frequently intermittent, due to node mobility, =
however, if node density and distribution are sufficient, the route =
discovery process may typically pick one out of multiple possible routes =
(e.g. based on shortest path, highest link stability, etc.)

    there are application domains (sensor networks) where end to end =
connectivity between any two nodes cannot always be guaranteed (due to =
node mobility, changing physical channel characteristics, node failure, =
etc) and we are thinking that store and forward may help with =
intermittent end-to-end routes.

    in the current dtn implementation, the file /etc/bundles/route is =
key in determining the next hop towards the destination. this does not =
quite fit with our scheme where aodv/olsr modify the kernel routing =
table. my question is therefore: have there been efforts within the dtn =
community to allow for dynamic route updates, or are there estimates =
what it would take to modify the bundleDaemon to employ the kernel =
routing table, rather than rely on a static set of routes?

    thanks,
    Josef
------=_NextPart_000_021F_01C43EC4.0893E9C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff background=3D"">
<DIV><FONT face=3D"Courier New" size=3D2>Hi Robert,</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>interesting approach. like you =
said,=20
knowing what the next best hop towards the destination is, requires some =

additional information. have you looked at using geographic routing=20
approaches?</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>as a first cut i am going to =
make the=20
(naive) assumption that at some point in the network's lifetime a =
full-end-to=20
end route between 2 nodes existed, one or more links of which may =
(periodically)=20
be down. with an appropriate&nbsp;route expiration timeout and DTN i =
would think=20
that reliable message transfer could be possible. i realize that this =
approach=20
does not solve the question 'what is the best next hop', and may also =
fail under=20
certain circumstances (e.g. if only sections of the complete route exist =
at any=20
given time).</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>have you looked at the bundle=20
daemon's&nbsp;udp mangement interface to support dynamic route updates =
at all?=20
Keith mentioned in one of his previous emails that this interface is =
incomplete,=20
undocumented and unsupported at this point.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Josef</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[email-masked] href=3D"mailto:[email-masked]">Robert C. =
Durst</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">'Josef Kriegl'</A> ; <A=20
  title=[email-masked]=20
  =
href=3D"mailto:[email-masked]">[email-masked]=
.org</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, May 18, 2004 =
6:16 PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: [dtn-interest] =
dynamic=20
  routes</DIV>
  <DIV><BR></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D506310816-18052004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Josef,</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D506310816-18052004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D506310816-18052004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>I, personally, am just starting to do =
this.&nbsp; Am=20
  looking at running DTN over OLSR-based subnetworks.&nbsp; I'm not yet =
to=20
  implementation, but am planning to consume the OLSR tables at the DTN =
layer,=20
  and to build some history to try to identify where good =
store-and-forward=20
  points would be, etc.&nbsp; Have not yet thought too deeply about=20
  implementation, but plan to let OLSR do its thing, modifying the =
kernel=20
  routing table, and work DTN routing as an overlay, where I would pick =
a=20
  next-hop DTN endpoint that is not necessarily a next-hop OLSR =
endpoint.&nbsp;=20
  Again, am just starting this.&nbsp; Sorry it's still pretty=20
  squishy.</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D506310816-18052004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D506310816-18052004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Regards,</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D506310816-18052004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Bob Durst</FONT></SPAN></DIV><BR>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft>
    <HR tabIndex=3D-1>
    <FONT face=3DTahoma size=3D2><B>From:</B> =
[email-masked]=20
    [mailto:[email-masked]] <B>On Behalf Of =
</B>Josef=20
    Kriegl<BR><B>Sent:</B> Tuesday, May 18, 2004 11:44 AM<BR><B>To:</B>=20
    [email-masked]<BR><B>Subject:</B> [dtn-interest] =
dynamic=20
    routes<BR></FONT><BR></DIV>
    <DIV></DIV>
    <DIV><FONT face=3D"Courier New" size=3D2></FONT><BR><FONT =
face=3D"Courier New"=20
    size=3D2>i notice that with the use of the /etc/bundles/route file =
routes=20
    between inter- and intraregion hosts have to be set up in a static=20
    manner.<BR><BR>we are working with manet routers such as olsr and =
aodv over=20
    wireless links, which essentially employ an on-demand route =
discovery=20
    process to determine the route between any 2 nodes in the ad hoc =
network.=20
    links are frequently intermittent, due to node mobility, however, if =
node=20
    density and distribution are sufficient, the route discovery process =
may=20
    typically pick one out of multiple possible routes (e.g. based on =
shortest=20
    path, highest link stability, etc.)<BR><BR>there are application =
domains=20
    (sensor networks) where end to end connectivity between any two =
nodes cannot=20
    always be guaranteed (due to node mobility, changing physical =
channel=20
    characteristics, node failure, etc) and we are thinking that store =
and=20
    forward may help with intermittent end-to-end routes.<BR><BR>in the =
current=20
    dtn implementation, the file /etc/bundles/route is key in =
determining the=20
    next hop towards the destination. this does not quite fit with our =
scheme=20
    where aodv/olsr modify the kernel routing table. my question is =
therefore:=20
    have there been efforts within the dtn community to allow for =
dynamic route=20
    updates, or are there estimates what it would take to modify the=20
    bundleDaemon to employ the kernel routing table, rather than rely on =
a=20
    static set of routes?</FONT></DIV>
    <DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3D"Courier New" size=3D2>thanks,</FONT></DIV>
    <DIV><FONT face=3D"Courier New"=20
size=3D2>Josef</FONT></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_021F_01C43EC4.0893E9C0--

From: "Matt Bradbury" <[email-masked]>
To: [email-masked]
Date: Wed, 19 May 2004 17:09:13 -0500
Subject: [dtn-interest] Protocol specs for Bundling over TCP?
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_03D6_01C43DC4.024AD700
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi, I was wondering if anyone has a formal/informal spec of how the =
prototype apps talk to each other over TCP.

I'm working on getting a Java implementation running and would love to =
be able to test against the existing code.

Thanks.

-Matt Bradbury

ps.  If anyone wants to take a look at the code in progress there is a =
cvs tree at: http://sourceforge.net/projects/dtn
------=_NextPart_000_03D6_01C43DC4.024AD700
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi, I was wondering if anyone has a =
formal/informal=20
spec of how the prototype apps talk to each other over TCP.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I'm working on getting a Java =
implementation=20
running and would love to be able to test against the existing=20
code.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>-Matt Bradbury</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>ps.&nbsp; If anyone wants to take a =
look at the=20
code in progress there is a cvs tree at: <A=20
href=3D"http://sourceforge.net/projects/dtn">http://sourceforge.net/proje=
cts/dtn</A></FONT></DIV></BODY></HTML>

------=_NextPart_000_03D6_01C43DC4.024AD700--

From: "Josef Kriegl" <[email-masked]>
To: <[email-masked]>
Cc: "Katayoun Sohrabi" <[email-masked]>
Date: Wed, 19 May 2004 18:23:47 +0200
Subject: [dtn-interest] Fw: inter-region routing - configuration issues
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_06F3_01C43DCE.6D336AA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Keith,

i ended up modifying the route file to include the address familiy =
identifier 'tcp' as well as the port number, so for example on stargate:

# DestRegion   NextHopRegion    NextHopAdmin            ONDEMAND_Region

netgate         netgate         tcp://10.2.106.10:5000   ONDEMAND
bullwinkle      netgate         tcp://10.2.106.10:5000   ONDEMAND

similarly on bullwinkle:

# DestRegion   NextHopRegion    NextHopAdmin            ONDEMAND_Region

netgate         netgate         tcp://10.2.106.10:5000  ONDEMAND
stargate        netgate         tcp://10.2.106.10:5000  ONDEMAND

and netgate:

interestingly, the transfer from stargate -> bullwinkle (across netgate) =
worked (see netgate log 'successful inter-region transfer' below), =
however, bullwinkle -> stargate FAILED starting with the log message

writeThreadDoCLayerCommand(tcp://10.2.106.9:5000/demux) heard from main =
CLwriteThreadDoCLayerCommand(tcp://10.2.106.9:5000/demux) existing =
CLISTINFO(0x8249e08) kicked.

could you please comment on whether the syntax for NextHopAdmin as shown =
above is correct, and how to interpret the message above.

thanks,
Josef

netgate log for successful inter-region transfer:

TCPCL: processIncomingRequest  received connection request (sock(27) =
from 10.2.106.9)
TCPCL: processIncomingRequest  first half of handshake correct =
(TCPCL_VERSION match).
TCPCL: processIncomingRequest  received connection request; =
myState(0x821c2b0).
CLAYE CL_RECEIVE_CONTACT_START
Writing CONTACT problem to bundle daemon
  cmd is 1,  clist is (nil)
processMessageFromCLayer: I know a new receive contact has started.

>>>>Starting thread TCPReceiveContact Thread (id:278542)
TCPReceiveOneBundle(10.2.106.9) BUNDLE RECEIVED (3958 bytes to file =
/tmp/var/spool/bundles//bundleTemp_iMYV9Q)
CLAYE CL_BUNDLE_RECEIVED =
header(/tmp/var/spool/bundles//bundleTemp_iMYV9Q:41) =
bundle(/tmp/var/spool/bundles//bundleTemp_sxP8oL:41)
   BD processMessageFromCLayer: BUNDLE_RECEIVED
   BD processMessageFromCLayer: conv layer told me a bundle is now in =
file >/tmp/var/spool/bundles//bundleTemp_sxP8oL<
db_bundle_store:  about to store updated bundle ID 7
db_bundle_store: About to create/store bundle metadata for bundle ID 6 =
in database
db_bundle_store:  Attempting to store bundle[6]
db_bundle_store: dbp->put of bundle [6] returned
db_bundle_store: successfully stored bundle [6], committing change
db_bundle_store: returning bundle ID 6
putBundleOnContactListHelp: brg:  0x8249ae8, newCLIST:  0x8245cd0
addBRGINFO: sz: 0, cl: state:4, type: -1, bytes: 19774, vol: 0
incrBundleRefCount:  bundleInfo(0x82499b8), current refcount(0)(0), =
increment: 1
   BD processMessageFromCLayer:  bundle 6 on receivedBundles list
processMessageFromCLayer: RECEIVED BUNDLE [id:6] =
(/tmp/var/spool/bundles//bundleTemp_sxP8oL)
BD isForMeHelp: looking for uri =
>bundles://bullwinkle/tcp://10.2.106.220:5000/demux<
db_get_matching_registrations:  bundle_dest (0xbfffecf0)(bullwinkle, =
tcp://10.2.106.220:5000/demux)
   converted to uri >bundles://bullwinkle/tcp://10.2.106.220:5000/demux<

   registration dbase is as follows:
     Registration database contains 0 registrations.
isForMe: NOT for me (seq: 11).
BD isForMeHelp: looking for uri =
>bundles://bullwinkle/tcp://10.2.106.220:5000/demux<
db_get_matching_registrations:  bundle_dest (0xbfffecf0)(bullwinkle, =
tcp://10.2.106.220:5000/demux)
   converted to uri >bundles://bullwinkle/tcp://10.2.106.220:5000/demux<

   registration dbase is as follows:
     Registration database contains 0 registrations.
isForMe: NOT for me (seq: 12).
getInterfaceFromRegion: found (1) matching interfaces for region =
>bullwinkle<
ScheduleBundle:  currentClist:  0x8245cd0, brg: 0x8249ae8, bundleId:  6
putBundleOnContactListHelp: brg:  0x8249ae8, brg->clist:  0x8245cd0
decrBundleRefCount about to lock BUNDLEINFO mutex (0x082499B8)
  current state is: UNLOCKED refcount(1) :: putBundleOnContactListHelp: =
brg:  0x8249ae8, newCLIST:  0x8249b80
addBRGINFO: sz: 0, cl: state:2, type: 1, bytes: 3958, vol: 0
incrBundleRefCount:  bundleInfo(0x82499b8), current refcount(0)(0), =
increment: 1
BD clist (0x8249b80) (1 bundles) to clayer(0x821c1a8)
TCPCL: handleNewClistInfo setting clayerPrivate to 0x8249e08
   BD Received 6: =
bundles://stargate/tcp://10.2.106.9:5000/->bundles://bullwinkle/tcp://10.=
2.106.220:5000/demux f

>>>>Starting thread TCP Write Thread (id:294927)
TCPCL: TCPWriteThread: (tcp://10.2.106.220:5000/demux)starting up
TCPCL Write Thread bundleSendSocket: invoked with dest admin =
>tcp://10.2.106.220:5000/demux<
TCPConnectionHandshake(tcp://10.2.106.220:5000/demux) sending initial =
handshake on socket 36
TCPConnectionHandshake(tcp://10.2.106.220:5000/demux) waiting for =
handshaking response (12 bytes, fd(36))
Sender received handshake with reliable(0)
TCPCL: TCPWriteThread: (tcp://10.2.106.220:5000/demux) no bundles now.  =
Linger(15) on(32)(36).
processMessageFromCLayer: recvd BUNDLE_AWAY (ID:6, =
file:/tmp/var/spool/bundles//bundleTemp_sxP8oL)
decrBundleRefCount about to lock BUNDLEINFO mutex (0x082499B8)
  current state is: UNLOCKED refcount(1) :: db_bundle_remove: commit of =
deleting bundle [6] returned 0
db_bundle_remove: bundle [6] deleted and committed; returning.
logfile_thread about to log_archive.

---

netgate log for failed inter-region transfer:

TCPReceiveOneBundle(10.2.106.220) BUNDLE RECEIVED (3962 bytes to file =
/tmp/var/spool/bundles//bundleTemp_ciA00f)
CLAYE CL_BUNDLE_RECEIVED =
header(/tmp/var/spool/bundles//bundleTemp_ciA00f:41) =
bundle(/tmp/var/spool/bundles//bundleTemp_UTMDMc:41)
   BD processMessageFromCLayer: BUNDLE_RECEIVED
   BD processMessageFromCLayer: conv layer told me a bundle is now in =
file >/tmp/var/spool/bundles//bundleTemp_UTMDMc<
db_bundle_store:  about to store updated bundle ID 13
db_bundle_store: About to create/store bundle metadata for bundle ID 12 =
in database
db_bundle_store:  Attempting to store bundle[12]
db_bundle_store: dbp->put of bundle [12] returned
db_bundle_store: successfully stored bundle [12], committing change
db_bundle_store: returning bundle ID 12
putBundleOnContactListHelp: brg:  0x82499b8, newCLIST:  0x8245cd0
addBRGINFO: sz: 0, cl: state:4, type: -1, bytes: 43538, vol: 0
incrBundleRefCount:  bundleInfo(0x8248cc0), current refcount(0)(0), =
increment: 1
   BD processMessageFromCLayer:  bundle 12 on receivedBundles list
processMessageFromCLayer: RECEIVED BUNDLE [id:12] =
(/tmp/var/spool/bundles//bundleTemp_UTMDMc)
BD isForMeHelp: looking for uri =
>bundles://stargate/tcp://10.2.106.9:5000/demux<
db_get_matching_registrations:  bundle_dest (0xbfffecf0)(stargate, =
tcp://10.2.106.9:5000/demux)
   converted to uri >bundles://stargate/tcp://10.2.106.9:5000/demux<

   registration dbase is as follows:
     Registration database contains 0 registrations.
isForMe: NOT for me (seq: 23).
BD isForMeHelp: looking for uri =
>bundles://stargate/tcp://10.2.106.9:5000/demux<
db_get_matching_registrations:  bundle_dest (0xbfffecf0)(stargate, =
tcp://10.2.106.9:5000/demux)
   converted to uri >bundles://stargate/tcp://10.2.106.9:5000/demux<

   registration dbase is as follows:
     Registration database contains 0 registrations.
isForMe: NOT for me (seq: 24).
getInterfaceFromRegion: found (1) matching interfaces for region =
>stargate<
ScheduleBundle:  currentClist:  0x8245cd0, brg: 0x82499b8, bundleId:  12
putBundleOnContactListHelp: brg:  0x82499b8, brg->clist:  0x8245cd0
decrBundleRefCount about to lock BUNDLEINFO mutex (0x08248CC0)
  current state is: UNLOCKED refcount(1) :: putBundleOnContactListHelp: =
brg:  0x82499b8, newCLIST:  0x8249e08
addBRGINFO: sz: 0, cl: state:2, type: 1, bytes: 15848, vol: 0
incrBundleRefCount:  bundleInfo(0x8248cc0), current refcount(0)(0), =
increment: 1
BD clist (0x8249e08) (1 bundles) to clayer(0x821bfe0)
   BD Received 12: =
bundles://bullwinkle/tcp://10.2.106.220:5000/->bundles://stargate/tcp://1=
0.2.106.9:5000/demux f

writeThreadDoCLayerCommand(tcp://10.2.106.9:5000/demux) heard from main =
CLwriteThreadDoCLayerCommand(tcp://10.2.106.9:5000/demux) existing =
CLISTINFO(0x8249e08) kicked.

TCPCL: TCPWriteThread: (tcp://10.2.106.9:5000/demux) no bundles now.  =
Linger(15) on(32)(36).
processMessageFromCLayer: recvd BUNDLE_AWAY (ID:12, =
file:/tmp/var/spool/bundles//bundleTemp_UTMDMc)
decrBundleRefCount about to lock BUNDLEINFO mutex (0x08248CC0)
  current state is: UNLOCKED refcount(1) :: db_bundle_remove: commit of =
deleting bundle [12] returned 0
db_bundle_remove: bundle [12] deleted and committed; returning.
logfile_thread about to log_archive.
logfile_thread return from log_archive is 0.
sweepOldBundles:  0 records in Expiration database
------=_NextPart_000_06F3_01C43DCE.6D336AA0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Courier New" size=3D2>Hi Keith,</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>i ended up modifying the route =
file to=20
include the address familiy identifier 'tcp' as well as the port number, =
so for=20
example on stargate:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2># DestRegion&nbsp;&nbsp;=20
NextHopRegion&nbsp;&nbsp;&nbsp;=20
NextHopAdmin&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
ONDEMAND_Region</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New"=20
size=3D2>netgate&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
netgate&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
tcp://10.2.106.10:5000&nbsp;&nbsp;=20
ONDEMAND<BR>bullwinkle&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
netgate&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
tcp://10.2.106.10:5000&nbsp;&nbsp; ONDEMAND</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>similarly on =
bullwinkle:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2># DestRegion&nbsp;&nbsp;=20
NextHopRegion&nbsp;&nbsp;&nbsp;=20
NextHopAdmin&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
ONDEMAND_Region</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New"=20
size=3D2>netgate&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
netgate&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
tcp://10.2.106.10:5000&nbsp;=20
ONDEMAND<BR>stargate&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
netgate&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
tcp://10.2.106.10:5000&nbsp; ONDEMAND<BR></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>and netgate:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>interestingly, the transfer =
from stargate=20
-&gt; bullwinkle (across netgate) worked (see netgate log 'successful=20
inter-region transfer' below), however, </FONT><FONT face=3D"Courier =
New"=20
size=3D2><FONT face=3D"Courier New" size=3D2>bullwinkle&nbsp;-&gt; =
stargate FAILED=20
starting with the log message</FONT></DIV></FONT>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV>writeThreadDoCLayerCommand(tcp://10.2.106.9:5000/demux) heard from =
main=20
CLwriteThreadDoCLayerCommand(tcp://10.2.106.9:5000/demux) existing=20
CLISTINFO(0x8249e08) kicked.</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>could you please comment on =
whether the=20
syntax for NextHopAdmin&nbsp;as shown above is correct, and how to =
interpret the=20
message above.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>thanks,</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Josef</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT><BR></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>netgate log for successful =
inter-region=20
transfer:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>TCPCL: =
processIncomingRequest&nbsp;=20
received connection request (sock(27) from 10.2.106.9)<BR>TCPCL:=20
processIncomingRequest&nbsp; first half of handshake correct =
(TCPCL_VERSION=20
match).<BR>TCPCL: processIncomingRequest&nbsp; received connection =
request;=20
myState(0x821c2b0).<BR>CLAYE CL_RECEIVE_CONTACT_START<BR>Writing CONTACT =
problem=20
to bundle daemon<BR>&nbsp; cmd is 1,&nbsp; clist is=20
(nil)<BR>processMessageFromCLayer: I know a new receive contact has=20
started.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&gt;&gt;&gt;&gt;Starting thread =

TCPReceiveContact Thread (id:278542)<BR>TCPReceiveOneBundle(10.2.106.9) =
BUNDLE=20
RECEIVED (3958 bytes to file =
/tmp/var/spool/bundles//bundleTemp_iMYV9Q)<BR>CLAYE=20
CL_BUNDLE_RECEIVED header(/tmp/var/spool/bundles//bundleTemp_iMYV9Q:41)=20
bundle(/tmp/var/spool/bundles//bundleTemp_sxP8oL:41)<BR>&nbsp;&nbsp; BD=20
processMessageFromCLayer: BUNDLE_RECEIVED<BR>&nbsp;&nbsp; BD=20
processMessageFromCLayer: conv layer told me a bundle is now in file=20
&gt;/tmp/var/spool/bundles//bundleTemp_sxP8oL&lt;<BR>db_bundle_store:&nbs=
p;=20
about to store updated bundle ID 7<BR>db_bundle_store: About to =
create/store=20
bundle metadata for bundle ID 6 in database<BR>db_bundle_store:&nbsp; =
Attempting=20
to store bundle[6]<BR>db_bundle_store: dbp-&gt;put of bundle [6]=20
returned<BR>db_bundle_store: successfully stored bundle [6], committing=20
change<BR>db_bundle_store: returning bundle ID =
6<BR>putBundleOnContactListHelp:=20
brg:&nbsp; 0x8249ae8, newCLIST:&nbsp; 0x8245cd0<BR>addBRGINFO: sz: 0, =
cl:=20
state:4, type: -1, bytes: 19774, vol: 0<BR>incrBundleRefCount:&nbsp;=20
bundleInfo(0x82499b8), current refcount(0)(0), increment: =
1<BR>&nbsp;&nbsp; BD=20
processMessageFromCLayer:&nbsp; bundle 6 on receivedBundles=20
list<BR>processMessageFromCLayer: RECEIVED BUNDLE [id:6]=20
(/tmp/var/spool/bundles//bundleTemp_sxP8oL)<BR>BD isForMeHelp: looking =
for uri=20
&gt;bundles://bullwinkle/tcp://10.2.106.220:5000/demux&lt;<BR>db_get_matc=
hing_registrations:&nbsp;=20
bundle_dest (0xbfffecf0)(bullwinkle,=20
tcp://10.2.106.220:5000/demux)<BR>&nbsp;&nbsp; converted to uri=20
&gt;bundles://bullwinkle/tcp://10.2.106.220:5000/demux&lt;</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; registration dbase =
is as=20
follows:<BR>&nbsp;&nbsp;&nbsp;&nbsp; Registration database contains 0=20
registrations.<BR>isForMe: NOT for me (seq: 11).<BR>BD isForMeHelp: =
looking for=20
uri=20
&gt;bundles://bullwinkle/tcp://10.2.106.220:5000/demux&lt;<BR>db_get_matc=
hing_registrations:&nbsp;=20
bundle_dest (0xbfffecf0)(bullwinkle,=20
tcp://10.2.106.220:5000/demux)<BR>&nbsp;&nbsp; converted to uri=20
&gt;bundles://bullwinkle/tcp://10.2.106.220:5000/demux&lt;</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; registration dbase =
is as=20
follows:<BR>&nbsp;&nbsp;&nbsp;&nbsp; Registration database contains 0=20
registrations.<BR>isForMe: NOT for me (seq: =
12).<BR>getInterfaceFromRegion:=20
found (1) matching interfaces for region=20
&gt;bullwinkle&lt;<BR>ScheduleBundle:&nbsp; currentClist:&nbsp; =
0x8245cd0, brg:=20
0x8249ae8, bundleId:&nbsp; 6<BR>putBundleOnContactListHelp: brg:&nbsp;=20
0x8249ae8, brg-&gt;clist:&nbsp; 0x8245cd0<BR>decrBundleRefCount about to =
lock=20
BUNDLEINFO mutex (0x082499B8)<BR>&nbsp; current state is: UNLOCKED =
refcount(1)=20
:: putBundleOnContactListHelp: brg:&nbsp; 0x8249ae8, newCLIST:&nbsp;=20
0x8249b80<BR>addBRGINFO: sz: 0, cl: state:2, type: 1, bytes: 3958, vol:=20
0<BR>incrBundleRefCount:&nbsp; bundleInfo(0x82499b8), current =
refcount(0)(0),=20
increment: 1<BR>BD clist (0x8249b80) (1 bundles) to =
clayer(0x821c1a8)<BR>TCPCL:=20
handleNewClistInfo setting clayerPrivate to 0x8249e08<BR>&nbsp;&nbsp; BD =

Received 6:=20
bundles://stargate/tcp://10.2.106.9:5000/-&gt;bundles://bullwinkle/tcp://=
10.2.106.220:5000/demux=20
f</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&gt;&gt;&gt;&gt;Starting thread =
TCP Write=20
Thread (id:294927)<BR>TCPCL: TCPWriteThread:=20
(tcp://10.2.106.220:5000/demux)starting up<BR>TCPCL Write Thread=20
bundleSendSocket: invoked with dest admin=20
&gt;tcp://10.2.106.220:5000/demux&lt;<BR>TCPConnectionHandshake(tcp://10.=
2.106.220:5000/demux)=20
sending initial handshake on socket=20
36<BR>TCPConnectionHandshake(tcp://10.2.106.220:5000/demux) waiting for=20
handshaking response (12 bytes, fd(36))<BR>Sender received handshake =
with=20
reliable(0)<BR>TCPCL: TCPWriteThread: (tcp://10.2.106.220:5000/demux) no =
bundles=20
now.&nbsp; Linger(15) on(32)(36).<BR>processMessageFromCLayer: recvd =
BUNDLE_AWAY=20
(ID:6, =
file:/tmp/var/spool/bundles//bundleTemp_sxP8oL)<BR>decrBundleRefCount=20
about to lock BUNDLEINFO mutex (0x082499B8)<BR>&nbsp; current state is: =
UNLOCKED=20
refcount(1) :: db_bundle_remove: commit of deleting bundle [6] returned=20
0<BR>db_bundle_remove: bundle [6] deleted and committed;=20
returning.<BR>logfile_thread about to log_archive.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>---</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>netgate log for failed =
inter-region=20
transfer:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" =
size=3D2>TCPReceiveOneBundle(10.2.106.220) BUNDLE=20
RECEIVED (3962 bytes to file =
/tmp/var/spool/bundles//bundleTemp_ciA00f)<BR>CLAYE=20
CL_BUNDLE_RECEIVED header(/tmp/var/spool/bundles//bundleTemp_ciA00f:41)=20
bundle(/tmp/var/spool/bundles//bundleTemp_UTMDMc:41)<BR>&nbsp;&nbsp; BD=20
processMessageFromCLayer: BUNDLE_RECEIVED<BR>&nbsp;&nbsp; BD=20
processMessageFromCLayer: conv layer told me a bundle is now in file=20
&gt;/tmp/var/spool/bundles//bundleTemp_UTMDMc&lt;<BR>db_bundle_store:&nbs=
p;=20
about to store updated bundle ID 13<BR>db_bundle_store: About to =
create/store=20
bundle metadata for bundle ID 12 in database<BR>db_bundle_store:&nbsp;=20
Attempting to store bundle[12]<BR>db_bundle_store: dbp-&gt;put of bundle =
[12]=20
returned<BR>db_bundle_store: successfully stored bundle [12], committing =

change<BR>db_bundle_store: returning bundle ID =
12<BR>putBundleOnContactListHelp:=20
brg:&nbsp; 0x82499b8, newCLIST:&nbsp; 0x8245cd0<BR>addBRGINFO: sz: 0, =
cl:=20
state:4, type: -1, bytes: 43538, vol: 0<BR>incrBundleRefCount:&nbsp;=20
bundleInfo(0x8248cc0), current refcount(0)(0), increment: =
1<BR>&nbsp;&nbsp; BD=20
processMessageFromCLayer:&nbsp; bundle 12 on receivedBundles=20
list<BR>processMessageFromCLayer: RECEIVED BUNDLE [id:12]=20
(/tmp/var/spool/bundles//bundleTemp_UTMDMc)<BR>BD isForMeHelp: looking =
for uri=20
&gt;bundles://stargate/tcp://10.2.106.9:5000/demux&lt;<BR>db_get_matching=
_registrations:&nbsp;=20
bundle_dest (0xbfffecf0)(stargate, =
tcp://10.2.106.9:5000/demux)<BR>&nbsp;&nbsp;=20
converted to uri =
&gt;bundles://stargate/tcp://10.2.106.9:5000/demux&lt;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp; registration dbase is as =
follows:<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
Registration database contains 0 registrations.<BR>isForMe: NOT for me =
(seq:=20
23).<BR>BD isForMeHelp: looking for uri=20
&gt;bundles://stargate/tcp://10.2.106.9:5000/demux&lt;<BR>db_get_matching=
_registrations:&nbsp;=20
bundle_dest (0xbfffecf0)(stargate, =
tcp://10.2.106.9:5000/demux)<BR>&nbsp;&nbsp;=20
converted to uri =
&gt;bundles://stargate/tcp://10.2.106.9:5000/demux&lt;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp; registration dbase is as =
follows:<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
Registration database contains 0 registrations.<BR>isForMe: NOT for me =
(seq:=20
24).<BR>getInterfaceFromRegion: found (1) matching interfaces for region =

&gt;stargate&lt;<BR>ScheduleBundle:&nbsp; currentClist:&nbsp; 0x8245cd0, =
brg:=20
0x82499b8, bundleId:&nbsp; 12<BR>putBundleOnContactListHelp: brg:&nbsp;=20
0x82499b8, brg-&gt;clist:&nbsp; 0x8245cd0<BR>decrBundleRefCount about to =
lock=20
BUNDLEINFO mutex (0x08248CC0)<BR>&nbsp; current state is: UNLOCKED =
refcount(1)=20
:: putBundleOnContactListHelp: brg:&nbsp; 0x82499b8, newCLIST:&nbsp;=20
0x8249e08<BR>addBRGINFO: sz: 0, cl: state:2, type: 1, bytes: 15848, vol: =

0<BR>incrBundleRefCount:&nbsp; bundleInfo(0x8248cc0), current =
refcount(0)(0),=20
increment: 1<BR>BD clist (0x8249e08) (1 bundles) to=20
clayer(0x821bfe0)<BR>&nbsp;&nbsp; BD Received 12:=20
bundles://bullwinkle/tcp://10.2.106.220:5000/-&gt;bundles://stargate/tcp:=
//10.2.106.9:5000/demux=20
f</DIV>
<DIV><BR>writeThreadDoCLayerCommand(tcp://10.2.106.9:5000/demux) heard =
from main=20
CLwriteThreadDoCLayerCommand(tcp://10.2.106.9:5000/demux) existing=20
CLISTINFO(0x8249e08) kicked.</DIV>
<DIV><BR>TCPCL: TCPWriteThread: (tcp://10.2.106.9:5000/demux) no bundles =

now.&nbsp; Linger(15) on(32)(36).<BR>processMessageFromCLayer: recvd =
BUNDLE_AWAY=20
(ID:12, =
file:/tmp/var/spool/bundles//bundleTemp_UTMDMc)<BR>decrBundleRefCount=20
about to lock BUNDLEINFO mutex (0x08248CC0)<BR>&nbsp; current state is: =
UNLOCKED=20
refcount(1) :: db_bundle_remove: commit of deleting bundle [12] returned =

0<BR>db_bundle_remove: bundle [12] deleted and committed;=20
returning.<BR>logfile_thread about to log_archive.<BR>logfile_thread =
return from=20
log_archive is 0.<BR>sweepOldBundles:&nbsp; 0 records in Expiration=20
database</FONT></DIV></BODY></HTML>

------=_NextPart_000_06F3_01C43DCE.6D336AA0--

Date: Wed, 19 May 2004 06:49:53 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Re: LTP limits
Sender: [email-masked]

At 01:10 PM 5/19/2004 +0100, Stephen Farrell wrote:

>>Sorry to be so dense about this; can you explain to me an example where 
>>this is a problem?
>
>- RS lower-bound+claim.offset+claim.length can exceed max-sdnv.
>- DS offset+length can get exceed max-sdnv.
>
>I think that's all.

Okay, maybe we can address these in a simple way in the spec by stating 
somewhere that the size of any single LTP-conveyed data block MUST NOT 
exceed the largest possible numeric value that can be represented in an 
SDNV-8.  In which case I think both of these examples would be violations 
of the protocol, which we already know how to handle.

Scott 

From: "Josef Kriegl" <[email-masked]>
To: <[email-masked]>
Date: Wed, 19 May 2004 14:16:59 +0200
Subject: [dtn-interest] inter-region routing - configuration issues
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_068F_01C43DAB.F2C698E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Keith,

thanks for the clarification on the demux string.

i am trying to get a network of 3 regions (1 node per region) up and =
running, with some problems, the daemon in region 'stargate' crashes in =
the write thread (see below). what stands out in the bundle daemon log =
are the messages

...
TCPCL Write Thread bundleSendSocket: invoked with dest admin =
>10.2.106.10<
TCPCL Write Thread bundleRecvSocket: can't find AF for intf admin =
>10.2.106.10<
...

i located the block of code that assumes the destination admin (from the =
route file) is prefixed with an address family identifier:

    if ((af =3D find_af(admin)) =3D=3D NULL) {
        fprintf(stderr, "%s bundleRecvSocket: can't find AF for intf =
admin >%s<\n",
            myThreadName(), admin);
        return (-1);
    }            =20

in contrast, an intra-region transfer succeeds with the following =
message:

...
TCPCL Write Thread bundleSendSocket: invoked with dest admin =
>tcp://10.2.106.10:5000/demux<
...

do the 'NextHopAdmin' entries in the route file need to be prefixed with =
tcp, or this this is this a bug?

thanks,
Josef

3 regions called stargate, netgate, bullwinkle, initiated transfer =
between stargate (sender) and bullwinkle (receiver). configuration files =
are as follows:

on stargate:

interface bundles://stargate/tcp://10.2.106.9:5000/ ondemand
interface bundles://netgate/tcp://10.2.106.9:5000/ ondemand

# DestRegion   NextHopRegion    NextHopAdmin            ONDEMAND_Region

netgate         netgate         10.2.106.10      ONDEMAND
bullwinkle      netgate         10.2.106.10      ONDEMAND

=20
on netgate:

interface bundles://netgate/tcp://10.2.106.10:5000/ ondemand
interface bundles://stargate/tcp://10.2.106.10:5000/ ondemand
interface bundles://bullwinkle/tcp://10.2.106.10:5000/ ondemand

# DestRegion   NextHopRegion    NextHopAdmin            ONDEMAND_Region

stargate        stargate        10.2.106.9      ONDEMAND
bullwinkle      bullwinkle      10.2.106.220    ONDEMAND

on bullwinkle:

interface bundles://bullwinkle/tcp://10.2.106.220:5000/ ondemand
interface bundles://netgate/tcp://10.2.106.220:5000/ ondemand

# DestRegion   NextHopRegion    NextHopAdmin            ONDEMAND_Region

netgate         netgate         10.2.106.10     ONDEMAND
stargate        netgate         10.2.106.10     ONDEMAND

daemon log on stargate before the crash:

bundleDaemon: starting main loop ...
checkpoint_thread return from checkpoint was 0
makeBRGFromBundleMetadata: using header and payload files on send side.
db_bundle_store:  about to store updated bundle ID 2
db_bundle_store: About to create/store bundle metadata for bundle ID 1 =
in database
db_bundle_store:  Attempting to store bundle[1]
db_bundle_store: dbp->put of bundle [1] returned
db_bundle_store: successfully stored bundle [1], committing change
db_bundle_store: returning bundle ID 1
bundleServerAPI isForMeHelp: looking for uri =
>bundles://bullwinkle/tcp://10.2.106.220:5000/demux<
db_get_matching_registrations:  bundle_dest (0xbe7fed5c)(bullwinkle, =
tcp://10.2.106.220:5000/demux)
   converted to uri >bundles://bullwinkle/tcp://10.2.106.220:5000/demux<

   registration dbase is as follows:
     Registration database contains 0 registrations.
isForMe: NOT for me (seq: 1).
   BD (10) serverAPI: putBundleOnContactListHelp: brg:  0x824a978, =
brg->clist:  (nil)
putBundleOnContactListHelp: brg:  0x824a978, newCLIST:  0x82455c8
addBRGINFO: sz: 0, cl: state:3, type: -1, bytes: 0, vol: 0
incrBundleRefCount:  bundleInfo(0x824a848), current refcount(0)(0), =
increment: 1
getInterfaceFromRegion: found (0) matching interfaces for region =
>bullwinkle<
getInterfaceFromRegion: found (1) matching interfaces for region =
>netgate<
BD findFirstContact: myCLISTINFOs has no contacts available
ScheduleBundle: made an on-demand clist to >10.2.106.10< (0x824aaa0) for =
bundleID [1]
ScheduleBundle:  currentClist:  0x82455c8, brg: 0x824a978, bundleId:  1
putBundleOnContactListHelp: brg:  0x824a978, brg->clist:  0x82455c8
decrBundleRefCount about to lock BUNDLEINFO mutex (0x0824A848)
  current state is: UNLOCKED refcount(1) :: putBundleOnContactListHelp: =
brg:  0x824a978, newCLIST:  0x824aaa0
addBRGINFO: sz: 0, cl: state:2, type: 1, bytes: 0, vol: 0
incrBundleRefCount:  bundleInfo(0x824a848), current refcount(0)(0), =
increment: 1
BD clist (0x824aaa0) (1 bundles) to clayer(0x821c040)
bundle 1 toCL =
bundles://stargate/tcp://10.2.106.9:5000/->bundles://bullwinkle/tcp://10.=
2.106.220:5000/demux
TCPCL: handleNewClistInfo setting clayerPrivate to 0x824ad28
send_bundle_file_svc: SUCCESS -- sent bundle file =
/tmp/var/spool/bundles//brgs/BRG_5VBwxM_PAYLOAD as bundleId 1

>>>>Starting thread TCP Write Thread (id:180236)
TCPCL: TCPWriteThread: (10.2.106.10)starting up

TCPCL Write Thread bundleSendSocket: invoked with dest admin =
>10.2.106.10<
TCPCL Write Thread bundleRecvSocket: can't find AF for intf admin =
>10.2.106.10<

TCPCL: writeThreadShutdown: : write thread shutting down (CONTACT =
BROKEN) (1 bundles).  Telling bundle daemon clist(0x824aaa0).
0 bundles on unassignedBRGs list
TCPCL: writeThreadShutdown: (CONTACT)writeContactinfotoBD: 0x824aaa0
[TCP|UDP]CL: writeThreadDestroy:  writeThreadInfo =3D 0x824ad28
Writing CONTACT problem to bundle daemon
  cmd is 4,  clist is 0x824aaa0
[1] (added by =
putBundleOnContactList)(/tmp/var/spool/bundles//brgs/BRG_5VBwxM_PAYLOAD) =
:: bundleMutex(0x0824A848) is UNLOCKED
BD handleContactProblem: found MYCLISTINFO for lost contact.
rescheduling contact 0x821cd58 (1 bundles) for another try.
Event added time(1084965086.000000) current(1084965081.560863) [0]
curTime(1084965081.560989) nextEvent(1084965086.000000) =
timeout(4.439011)
curTime(1084965086.000214) nextEvent(1084965086.000000) =
timeout(-1.999786)
Event 1000 (Restarted Contact) fires time(1084965086.000000) =
current(1084965086.000255) delta(0.000255)
timerThread clist (0x824aaa0) (1 bundles) to clayer(0x821c040)
MUTEX_TRACKING: Attempting to lock an unknown mutex (0x264): FILE: =
tcpCL.c  LINE: 806
[bt] Execution path:
[bt] [0x8062fa3]
[bt] [0x80634fc]
[bt] [0x80e8020]
[bt] [0x80e7e47]
[bt] [0x806a7c8]
[bt] [0x80e6e79]
[bt] [0x806cbed]
[bt] [0x8114217]
Segmentation fault
[jkriegl@stargate dtn]$=20

----- Original Message -----=20
From: "Keith Scott" <[email-masked]>
To: "'Josef Kriegl'" <[email-masked]>
Sent: Tuesday, May 18, 2004 7:45 PM
Subject: RE: Fw: [dtn-interest] running the sample applications

> I think you're beyond this, but what follows '-s' at the receiver is
> essentially a demux string, roughly equivalent to a port number.  The
> semantics (in this implementation) of the admin part of a DTN =
identifier in
> an internet (TCP/IP) region are host:port/demuxString    '-s foo' at =
the
> receiver sets the demuxString to foo.  You may (though I haven't =
tested it
> in a while) have multiple applications listen on the same demuxString. =
 You
> _might_ (though I never actually tested it, wasn't my code) have an
> application listen on a substring, like 'f'.
>=20
> --keith
>=20
> >-----Original Message-----
> >From: [email-masked]=20
> >[mailto:[email-masked]] On Behalf Of Josef =
Kriegl
> >Sent: Tuesday, May 18, 2004 11:20 AM
> >To: [email-masked]
> >Subject: Re: Fw: [dtn-interest] running the sample applications
> >
> >Hi Keith,
> >
> >thanks (the attachment is missing, though).
> >
> >meanwhile, i was able to run both apps, however, the receiver does =
not
> >report incoming bundles (although the bundle daemon logs look ok, no
> >errors).
> >
> >i am confused about the -s parameter, it's semantics, how it=20
> >influences the
> >interface entries in the bundleNode.conf file, etc. can you=20
> >enlighten me on
> >this?
> >
> >here are the configuration files and command lines i currently=20
> >use on two
> >x86 machines:
> >
> >sender (10.2.106.9):
> >
> >/etc/bundles/bundleNode.conf:
> ># ...
> >interface bundles://internet/tcp://10.2.106.9:5000 ondemand
> >#
> ># for loopback testing:
> ># interface bundles://loopback/tcp://localhost:5000 ondemand
> >
> >/etc/bundles/route:
> >internet internet 10.2.106.220 ONDEMAND
> >
> >/etc/bundles/route:
> >internet internet 10.2.106.220 ONDEMAND
> >
> >./snd_bundle -d5 -Dbundles://internet/tcp://10.2.106.220:5000 -f
> >`pwd`/Makefile
> >
> >
> >receiver (10.2.106.220):
> >
> >/etc/bundles/bundleNode.conf:
> ># ...
> >interface bundles://internet/tcp://10.2.106.220:5000 ondemand
> >
> >./AsyncRcvr/async_rcvr -slocalstuff
> >
> >
> >----- Original Message -----=20
> >From: "Keith Scott" <[email-masked]>
> >To: "Josef Kriegl" <[email-masked]>
> >Cc: <[email-masked]>
> >Sent: Tuesday, May 18, 2004 5:06 PM
> >Subject: Re: Fw: [dtn-interest] running the sample applications
> >
> >
> >> Sorry, some sort of document needs to describe this.
> >>
> >> The most tested applications are SndBundle2 (the command=20
> >line version)
> >> and AsyncRcvr.  Start with these.
> >>
> >> I have attached a .tgz file with script output from starting a =
bundle
> >> daemon, asyncRcvr, and sndBundle2 on the same machine, and=20
> >using the TCP
> >> convergence layer to send a bundle via a fictitious=20
> >'loopback' region.
> >>
> >> When you register with asyncRcvr, then a 's' command at the=20
> >bundleDaemon
> >> should show you one registration.  The format in which the=20
> >registration
> >> is printed is suitable for cutting and pasting as the argument to =
the
> >> '-D' argument to sndBundle2.
> >>
> >>
> >>
> >> On Tue, 2004-05-18 at 10:09, Josef Kriegl wrote:
> >> >
> >> > to further elaborate on my attempts to send a bundle between 2
> >> > processes on the local machine:
> >> >
> >> > when using 'bundles://loopback/tcp://localhost:5000' as the
> >> > destination tuple, the bundleDaemon log looks more promising (see
> >> > below, with sender and receiver command lines further down). the
> >> > message
> >> >
> >> > registration dbase is as follows:
> >> >      Registration database contains 0 registrations
> >> >
> >> > seems to indicate that something's not quite right (the=20
> >receiver has
> >> > not successfully registered to receive bundles?). apart=20
> >from the demux
> >> > string i don't see a parameter that would allow me to register
> >> > interest to receive a particular bundle. what would the common
> >> > identifier be to identify the 'end points' between a 'bundle
> >> > connection' (something that's analogous to a socket in tcp)?
> >> >
> >> > Josef
> >> >
> >> >
> >> > checkpoint_thread return from checkpoint was 0
> >> > logfile_thread about to log_archive.
> >> > logfile_thread return from log_archive is 0.
> >> > sweepOldBundles:  0 records in Expiration database
> >> > checkpoint_thread about to checkpoint.
> >> > checkpoint_thread return from checkpoint was 0
> >> > makeBRGFromBundleMetadata: using header and payload files on send
> >> > side.
> >> > db_bundle_store:  about to store updated bundle ID 2
> >> > db_bundle_store: About to create/store bundle metadata for=20
> >bundle ID 1
> >> > in database
> >> > db_bundle_store:  Attempting to store bundle[1]
> >> > db_bundle_store: dbp->put of bundle [1] returned
> >> > db_bundle_store: successfully stored bundle [1], committing =
change
> >> > db_bundle_store: returning bundle ID 1
> >> > bundleServerAPI isForMeHelp: looking for uri
> >> > >bundles://loopback/tcp://localhost:5000<
> >> > db_get_matching_registrations:  bundle_dest =
(0xbebfed5c)(loopback,
> >> > tcp://localhost:5000)
> >> >    converted to uri >bundles://loopback/tcp://localhost:5000<
> >> >
> >> >    registration dbase is as follows:
> >> >      Registration database contains 0 registrations.
> >> > putBundleOnContactListHelp: brg:  0x824adb8, newCLIST:  0x8247380
> >> > addBRGINFO: sz: 0, cl: state:4, type: -1, bytes: 0, vol: 0
> >> > incrBundleRefCount:  bundleInfo(0x824bf38), current =
refcount(0)(0),
> >> > increment: 1
> >> > send_bundle:  bundle 1 on receivedBundles list
> >> > deliverBundleLocally: RECEIVED BUNDLE FOR LOCAL DELIVERY to
> >> > destination:(loopback,
> >> > tcp://localhost:5000)db_get_matching_registrations:  bundle_dest
> >> > (0xbebfed5c)(loopback, tcp://localhost:5000)
> >> >    converted to uri >bundles://loopback/tcp://localhost:5000<
> >> >
> >> >    registration dbase is as follows:
> >> >      Registration database contains 0 registrations.
> >> > logfile_thread about to log_archive.
> >> > logfile_thread return from log_archive is 0.
> >> > sweepOldBundles:  1 records in Expiration database
> >> > checkpoint_thread about to checkpoint.
> >> > checkpoint_thread return from checkpoint was 0
> >> >
> >> >
> >> > receiver command line:
> >> >
> >> > [jkriegl@stargate myapps]$ ./brecv -n3600 -slocal -d5
> >> > # polling_rcvrrc
> >> > #
> >> > # This file was generaged as the result of a
> >> > #   '-w' argument to polling_rcvr.  Future uses of
> >> > #   '-w' will overwrite this file.
> >> > #
> >> > bahost: localhost
> >> > demuxString: local
> >> > iterator: 0
> >> > debug: 5
> >> > polling_rcvr: ***opening bundle agent on host localhost
> >> >     Bundle agent open.
> >> > creating local tuple...
> >> > ->bundles://loopback/tcp://localhost:5000<- [41, 19]
> >> >                      ^
> >> > polling for tuple:
> >> > ->bundles://loopback/tcp://localhost:5000<- [41, 19]
> >> >                      ^
> >> > Bundle poll iterator set to 0
> >> >
> >> >
> >> > sender command line:
> >> >
> >> > [jkriegl@stargate myapps]$ ./bsend -d5
> >> > -Dbundles://loopback/tcp://localhost:5000 -f Makefile
> >> > # snd_bundlerc
> >> > #
> >> > # This file was generaged as the result of a
> >> > #   '-w' argument to snd_bundle.  Future uses of
> >> > #   '-w' will overwrite this file.
> >> > #
> >> > bahost: localhost
> >> > baport: 0
> >> > bundle_data:
> >> > fname: Makefile
> >> > sourceIntf:
> >> > localstuff:
> >> > destTuple: bundles://loopback/tcp://localhost:5000
> >> > expire: 100
> >> > pollForResponse: 0
> >> > debug: 5
> >> > SND BUNDLE:  ***opening bundle agent on host localhost:0
> >> >     Bundle agent on host localhost open.
> >> > snd_bundle: building local tuple (intf:><, localstuff:><)
> >> > ->bundles://loopback/tcp://localhost:5000<- [41, 19]
> >> >                      ^
> >> > snd_bundle: building destination tuple:
> >> > (bundles://loopback/tcp://localhost:5000)
> >> > ->bundles://loopback/tcp://localhost:5000<- [39, 18]
> >> >                     ^
> >> > sending bundle from file <Makefile>...
> >> >
> >> > ***all done (success)
> >> > [jkriegl@stargate myapps]$
> >> >
> >> >
> >> > ----- Original Message -----=20
> >> > From: Josef Kriegl
> >> > To: [email-masked]
> >> > Sent: Tuesday, May 18, 2004 2:21 PM
> >> > Subject: [dtn-interest] running the sample applications
> >> >
> >> > Hi Keith,
> >> >
> >> > i am trying to run the DTN command line sample=20
> >applications snd_bundle
> >> > and poll_recv (on x86 for now, because we are still having
> >> > difficulties getting the berkeley db to work on xscale and sh4). =
i
> >> > realize that i first need to better understand the various =
concepts
> >> > behind DTN and the meanings of the various command line params. =
can
> >> > you recommend a particular document for this? if you could=20
> >show me a
> >> > few command lines that are know to work for the cases
> >> >
> >> > 1) localhost communication between sender and receiver
> >> > 2) comm between 2 machines on the same lan (1q hop)
> >> >
> >> > i think that would help me a lot to get started.
> >> >
> >> > thanks,
> >> > Josef
> >> >
> >> > p.s. in the case of 2 machines on the same LAN (1 hop, no=20
> >routing) i
> >> > launched the bundle daemon, but don't know if i need to=20
> >run any of the
> >> > other system binaries (contactManager, bundleRelay
> >> > before/concurrently). the command line arguments sourceIntf,
> >> > localstuff, destTuple are not clear to me, neither how the=20
> >demuxString
> >> > relates to any of them on the receiver side.
> >> >
> >> > i tried the following snd_bundle command line trying to send a =
file
> >> > from machine A to B, saw a bundle daemon response on the=20
> >sending host:
> >> >
> >> > ./bsend -d5 -Ihost -lapp -D=20
> >bundles://internet/tcp://10.2.106.220 -f
> >> > Makefile
> >> >
> >> > ...
> >> > bundleServerAPI isForMeHelp: looking for uri
> >> > >bundles://internet/tcp://10.2.106.220<
> >> > isForMeHelp: unable to validate format of admin part
> >> > >tcp://10.2.106.220<
> >> > putBundleOnContactListHelp: brg:  0x8247d58, newCLIST:  0x82451f8
> >> > addBRGINFO: sz: 0, cl: state:4, type: -1, bytes: 43439, vol: 0
> >> > incrBundleRefCount:  bundleInfo(0x8247c28), current =
refcount(0)(0),
> >> > increment: 1
> >> > send_bundle:  bundle 10 on receivedBundles list
> >> > deliverBundleLocally: RECEIVED BUNDLE FOR LOCAL DELIVERY to
> >> > destination:(internet,
> >> > tcp://10.2.106.220)db_get_matching_registrations:  bundle_dest
> >> > (0xbebfed5c)(internet, tcp://10.2.106.220)
> >> >    converted to uri >bundles://internet/tcp://10.2.106.220<
> >> >
> >> >    registration dbase is as follows:
> >> >      Registration database contains 0 registrations.
> >> >
> >> >
> >>
> >> _______________________________________________
> >> dtn-interest mailing list
> >> [email-masked]
> >> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >>
> >
> >
> >_______________________________________________
> >dtn-interest mailing list
> >[email-masked]
> >http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >
>=20
>=20
> 
------=_NextPart_000_068F_01C43DAB.F2C698E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff background=3D"">
<DIV><FONT face=3D"Courier New" size=3D2>Hi Keith,<BR><BR>thanks for the =

clarification on the demux string.<BR><BR>i am trying to get a network =
of 3=20
regions (1 node per region) up and running, with some problems, the =
daemon in=20
region 'stargate' crashes in the write thread (see below). what stands =
out in=20
the bundle daemon log&nbsp;are the messages<BR></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>...<BR>TCPCL Write Thread =
bundleSendSocket:=20
invoked with dest admin &gt;10.2.106.10&lt;<BR>TCPCL Write Thread=20
bundleRecvSocket: can't find AF for intf admin =
&gt;10.2.106.10&lt;</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>...<BR><BR>i located the block =
of code that=20
assumes the destination admin (from the route file) is prefixed with an =
address=20
family identifier:</FONT></DIV><FONT face=3D"Courier New" size=3D2>
<DIV><BR>&nbsp;&nbsp;&nbsp; if ((af =3D find_af(admin)) =3D=3D NULL)=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fprintf(stderr, "%s=20
bundleRecvSocket: can't find AF for intf admin=20
&gt;%s&lt;\n",<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
myThreadName(), admin);<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
return=20
(-1);<BR>&nbsp;&nbsp;&nbsp;=20
}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;<BR><BR>in=20
contrast, an intra-region transfer&nbsp;succeeds with the following=20
message:</DIV>
<DIV>&nbsp;</DIV>
<DIV>...<BR>TCPCL Write Thread bundleSendSocket: invoked with dest admin =

&gt;tcp://10.2.106.10:5000/demux&lt;<BR>...<BR></DIV>
<DIV>do the 'NextHopAdmin' entries in the route file need to be prefixed =
with=20
tcp, or this this is this a bug?</DIV>
<DIV><BR>thanks,<BR>Josef<BR><BR><BR>3 regions called stargate, netgate, =

bullwinkle, initiated transfer between stargate (sender) and bullwinkle=20
(receiver). configuration files are as follows:<BR><BR>on=20
stargate:<BR><BR>interface bundles://stargate/tcp://10.2.106.9:5000/=20
ondemand<BR>interface bundles://netgate/tcp://10.2.106.9:5000/ =
ondemand<BR><BR>#=20
DestRegion&nbsp;&nbsp; NextHopRegion&nbsp;&nbsp;&nbsp;=20
NextHopAdmin&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
ONDEMAND_Region<BR><BR>netgate&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
netgate&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
10.2.106.10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
ONDEMAND<BR>bullwinkle&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
netgate&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
10.2.106.10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ONDEMAND<BR><BR>&nbsp;<BR>on=20
netgate:<BR><BR>interface bundles://netgate/tcp://10.2.106.10:5000/=20
ondemand<BR>interface bundles://stargate/tcp://10.2.106.10:5000/=20
ondemand<BR>interface bundles://bullwinkle/tcp://10.2.106.10:5000/=20
ondemand<BR><BR># DestRegion&nbsp;&nbsp; NextHopRegion&nbsp;&nbsp;&nbsp; =

NextHopAdmin&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
ONDEMAND_Region<BR><BR>stargate&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
stargate&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
10.2.106.9&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
ONDEMAND<BR>bullwinkle&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
bullwinkle&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10.2.106.220&nbsp;&nbsp;&nbsp;=20
ONDEMAND<BR><BR><BR>on bullwinkle:<BR><BR>interface=20
bundles://bullwinkle/tcp://10.2.106.220:5000/ ondemand<BR>interface=20
bundles://netgate/tcp://10.2.106.220:5000/ ondemand<BR><BR>#=20
DestRegion&nbsp;&nbsp; NextHopRegion&nbsp;&nbsp;&nbsp;=20
NextHopAdmin&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
ONDEMAND_Region<BR><BR>netgate&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
netgate&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
10.2.106.10&nbsp;&nbsp;&nbsp;&nbsp;=20
ONDEMAND<BR>stargate&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
netgate&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
10.2.106.10&nbsp;&nbsp;&nbsp;&nbsp; ONDEMAND<BR><BR><BR>daemon log on =
stargate=20
before the crash:<BR><BR>bundleDaemon: starting main loop=20
...<BR>checkpoint_thread return from checkpoint was=20
0<BR>makeBRGFromBundleMetadata: using header and payload files on send=20
side.<BR>db_bundle_store:&nbsp; about to store updated bundle ID=20
2<BR>db_bundle_store: About to create/store bundle metadata for bundle =
ID 1 in=20
database<BR>db_bundle_store:&nbsp; Attempting to store=20
bundle[1]<BR>db_bundle_store: dbp-&gt;put of bundle [1]=20
returned<BR>db_bundle_store: successfully stored bundle [1], committing=20
change<BR>db_bundle_store: returning bundle ID 1<BR>bundleServerAPI =
isForMeHelp:=20
looking for uri=20
&gt;bundles://bullwinkle/tcp://10.2.106.220:5000/demux&lt;<BR>db_get_matc=
hing_registrations:&nbsp;=20
bundle_dest (0xbe7fed5c)(bullwinkle,=20
tcp://10.2.106.220:5000/demux)<BR>&nbsp;&nbsp; converted to uri=20
&gt;bundles://bullwinkle/tcp://10.2.106.220:5000/demux&lt;<BR><BR>&nbsp;&=
nbsp;=20
registration dbase is as follows:<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
Registration=20
database contains 0 registrations.<BR>isForMe: NOT for me (seq:=20
1).<BR>&nbsp;&nbsp; BD (10) serverAPI: putBundleOnContactListHelp: =
brg:&nbsp;=20
0x824a978, brg-&gt;clist:&nbsp; (nil)<BR>putBundleOnContactListHelp: =
brg:&nbsp;=20
0x824a978, newCLIST:&nbsp; 0x82455c8<BR>addBRGINFO: sz: 0, cl: state:3, =
type:=20
-1, bytes: 0, vol: 0<BR>incrBundleRefCount:&nbsp; bundleInfo(0x824a848), =
current=20
refcount(0)(0), increment: 1<BR>getInterfaceFromRegion: found (0) =
matching=20
interfaces for region &gt;bullwinkle&lt;<BR>getInterfaceFromRegion: =
found (1)=20
matching interfaces for region &gt;netgate&lt;<BR>BD findFirstContact:=20
myCLISTINFOs has no contacts available<BR>ScheduleBundle: made an =
on-demand=20
clist to &gt;10.2.106.10&lt; (0x824aaa0) for bundleID=20
[1]<BR>ScheduleBundle:&nbsp; currentClist:&nbsp; 0x82455c8, brg: =
0x824a978,=20
bundleId:&nbsp; 1<BR>putBundleOnContactListHelp: brg:&nbsp; 0x824a978,=20
brg-&gt;clist:&nbsp; 0x82455c8<BR>decrBundleRefCount about to lock =
BUNDLEINFO=20
mutex (0x0824A848)<BR>&nbsp; current state is: UNLOCKED refcount(1) ::=20
putBundleOnContactListHelp: brg:&nbsp; 0x824a978, newCLIST:&nbsp;=20
0x824aaa0<BR>addBRGINFO: sz: 0, cl: state:2, type: 1, bytes: 0, vol:=20
0<BR>incrBundleRefCount:&nbsp; bundleInfo(0x824a848), current =
refcount(0)(0),=20
increment: 1<BR>BD clist (0x824aaa0) (1 bundles) to =
clayer(0x821c040)<BR>bundle=20
1 toCL=20
bundles://stargate/tcp://10.2.106.9:5000/-&gt;bundles://bullwinkle/tcp://=
10.2.106.220:5000/demux<BR>TCPCL:=20
handleNewClistInfo setting clayerPrivate to =
0x824ad28<BR>send_bundle_file_svc:=20
SUCCESS -- sent bundle file =
/tmp/var/spool/bundles//brgs/BRG_5VBwxM_PAYLOAD as=20
bundleId 1<BR><BR>&gt;&gt;&gt;&gt;Starting thread TCP Write Thread=20
(id:180236)<BR>TCPCL: TCPWriteThread: (10.2.106.10)starting =
up<BR><BR><BR>TCPCL=20
Write Thread bundleSendSocket: invoked with dest admin=20
&gt;10.2.106.10&lt;<BR>TCPCL Write Thread bundleRecvSocket: can't find =
AF for=20
intf admin &gt;10.2.106.10&lt;<BR><BR><BR>TCPCL: writeThreadShutdown: : =
write=20
thread shutting down (CONTACT BROKEN) (1 bundles).&nbsp; Telling bundle =
daemon=20
clist(0x824aaa0).<BR>0 bundles on unassignedBRGs list<BR>TCPCL:=20
writeThreadShutdown: (CONTACT)writeContactinfotoBD: =
0x824aaa0<BR>[TCP|UDP]CL:=20
writeThreadDestroy:&nbsp; writeThreadInfo =3D 0x824ad28<BR>Writing =
CONTACT problem=20
to bundle daemon<BR>&nbsp; cmd is 4,&nbsp; clist is 0x824aaa0<BR>[1] =
(added by=20
putBundleOnContactList)(/tmp/var/spool/bundles//brgs/BRG_5VBwxM_PAYLOAD) =
::=20
bundleMutex(0x0824A848) is UNLOCKED<BR>BD handleContactProblem: found=20
MYCLISTINFO for lost contact.<BR>rescheduling contact 0x821cd58 (1 =
bundles) for=20
another try.<BR>Event added time(1084965086.000000) =
current(1084965081.560863)=20
[0]<BR>curTime(1084965081.560989) nextEvent(1084965086.000000)=20
timeout(4.439011)<BR>curTime(1084965086.000214) =
nextEvent(1084965086.000000)=20
timeout(-1.999786)<BR>Event 1000 (Restarted Contact) fires=20
time(1084965086.000000) current(1084965086.000255)=20
delta(0.000255)<BR>timerThread clist (0x824aaa0) (1 bundles) to=20
clayer(0x821c040)<BR>MUTEX_TRACKING: Attempting to lock an unknown mutex =

(0x264): FILE: tcpCL.c&nbsp; LINE: 806<BR>[bt] Execution path:<BR>[bt]=20
[0x8062fa3]<BR>[bt] [0x80634fc]<BR>[bt] [0x80e8020]<BR>[bt] =
[0x80e7e47]<BR>[bt]=20
[0x806a7c8]<BR>[bt] [0x80e6e79]<BR>[bt] [0x806cbed]<BR>[bt]=20
[0x8114217]<BR>Segmentation fault<BR>[jkriegl@stargate dtn]$ =
<BR><BR>-----=20
Original Message ----- <BR>From: "Keith Scott" =
&lt;[email-masked]&gt;<BR>To:=20
"'Josef Kriegl'" &lt;[email-masked]&gt;<BR>Sent: Tuesday, May 18, 2004 =
7:45=20
PM<BR>Subject: RE: Fw: [dtn-interest] running the sample=20
applications<BR><BR><BR>&gt; I think you're beyond this, but what =
follows '-s'=20
at the receiver is<BR>&gt; essentially a demux string, roughly =
equivalent to a=20
port number.&nbsp; The<BR>&gt; semantics (in this implementation) of the =
admin=20
part of a DTN identifier in<BR>&gt; an internet (TCP/IP) region are=20
host:port/demuxString&nbsp;&nbsp;&nbsp; '-s foo' at the<BR>&gt; receiver =
sets=20
the demuxString to foo.&nbsp; You may (though I haven't tested =
it<BR>&gt; in a=20
while) have multiple applications listen on the same demuxString.&nbsp;=20
You<BR>&gt; _might_ (though I never actually tested it, wasn't my code) =
have=20
an<BR>&gt; application listen on a substring, like 'f'.<BR>&gt; <BR>&gt; =

--keith<BR>&gt; <BR>&gt; &gt;-----Original Message-----<BR>&gt; =
&gt;From:=20
[email-masked] <BR>&gt;=20
&gt;[mailto:[email-masked]] On Behalf Of Josef=20
Kriegl<BR>&gt; &gt;Sent: Tuesday, May 18, 2004 11:20 AM<BR>&gt; &gt;To:=20
[email-masked]<BR>&gt; &gt;Subject: Re: Fw: =
[dtn-interest]=20
running the sample applications<BR>&gt; &gt;<BR>&gt; &gt;Hi =
Keith,<BR>&gt;=20
&gt;<BR>&gt; &gt;thanks (the attachment is missing, though).<BR>&gt;=20
&gt;<BR>&gt; &gt;meanwhile, i was able to run both apps, however, the =
receiver=20
does not<BR>&gt; &gt;report incoming bundles (although the bundle daemon =
logs=20
look ok, no<BR>&gt; &gt;errors).<BR>&gt; &gt;<BR>&gt; &gt;i am confused =
about=20
the -s parameter, it's semantics, how it <BR>&gt; &gt;influences =
the<BR>&gt;=20
&gt;interface entries in the bundleNode.conf file, etc. can you <BR>&gt; =

&gt;enlighten me on<BR>&gt; &gt;this?<BR>&gt; &gt;<BR>&gt; &gt;here are =
the=20
configuration files and command lines i currently <BR>&gt; &gt;use on=20
two<BR>&gt; &gt;x86 machines:<BR>&gt; &gt;<BR>&gt; &gt;sender=20
(10.2.106.9):<BR>&gt; &gt;<BR>&gt; =
&gt;/etc/bundles/bundleNode.conf:<BR>&gt;=20
&gt;# ...<BR>&gt; &gt;interface bundles://internet/tcp://10.2.106.9:5000 =

ondemand<BR>&gt; &gt;#<BR>&gt; &gt;# for loopback testing:<BR>&gt; &gt;# =

interface bundles://loopback/tcp://localhost:5000 ondemand<BR>&gt; =
&gt;<BR>&gt;=20
&gt;/etc/bundles/route:<BR>&gt; &gt;internet internet 10.2.106.220=20
ONDEMAND<BR>&gt; &gt;<BR>&gt; &gt;/etc/bundles/route:<BR>&gt; =
&gt;internet=20
internet 10.2.106.220 ONDEMAND<BR>&gt; &gt;<BR>&gt; &gt;./snd_bundle -d5 =

-Dbundles://internet/tcp://10.2.106.220:5000 -f<BR>&gt;=20
&gt;`pwd`/Makefile<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;receiver=20
(10.2.106.220):<BR>&gt; &gt;<BR>&gt; =
&gt;/etc/bundles/bundleNode.conf:<BR>&gt;=20
&gt;# ...<BR>&gt; &gt;interface =
bundles://internet/tcp://10.2.106.220:5000=20
ondemand<BR>&gt; &gt;<BR>&gt; &gt;./AsyncRcvr/async_rcvr =
-slocalstuff<BR>&gt;=20
&gt;<BR>&gt; &gt;<BR>&gt; &gt;----- Original Message ----- <BR>&gt; =
&gt;From:=20
"Keith Scott" &lt;[email-masked]&gt;<BR>&gt; &gt;To: "Josef Kriegl"=20
&lt;[email-masked]&gt;<BR>&gt; &gt;Cc:=20
&lt;[email-masked]&gt;<BR>&gt; &gt;Sent: Tuesday, May =
18, 2004=20
5:06 PM<BR>&gt; &gt;Subject: Re: Fw: [dtn-interest] running the sample=20
applications<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;&gt; Sorry, some sort =
of=20
document needs to describe this.<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; The =
most=20
tested applications are SndBundle2 (the command <BR>&gt; &gt;line=20
version)<BR>&gt; &gt;&gt; and AsyncRcvr.&nbsp; Start with these.<BR>&gt; =

&gt;&gt;<BR>&gt; &gt;&gt; I have attached a .tgz file with script output =
from=20
starting a bundle<BR>&gt; &gt;&gt; daemon, asyncRcvr, and sndBundle2 on =
the same=20
machine, and <BR>&gt; &gt;using the TCP<BR>&gt; &gt;&gt; convergence =
layer to=20
send a bundle via a fictitious <BR>&gt; &gt;'loopback' region.<BR>&gt;=20
&gt;&gt;<BR>&gt; &gt;&gt; When you register with asyncRcvr, then a 's' =
command=20
at the <BR>&gt; &gt;bundleDaemon<BR>&gt; &gt;&gt; should show you one=20
registration.&nbsp; The format in which the <BR>&gt; =
&gt;registration<BR>&gt;=20
&gt;&gt; is printed is suitable for cutting and pasting as the argument =
to=20
the<BR>&gt; &gt;&gt; '-D' argument to sndBundle2.<BR>&gt; =
&gt;&gt;<BR>&gt;=20
&gt;&gt;<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; On Tue, 2004-05-18 at 10:09, =
Josef=20
Kriegl wrote:<BR>&gt; &gt;&gt; &gt;<BR>&gt; &gt;&gt; &gt; to further =
elaborate=20
on my attempts to send a bundle between 2<BR>&gt; &gt;&gt; &gt; =
processes on the=20
local machine:<BR>&gt; &gt;&gt; &gt;<BR>&gt; &gt;&gt; &gt; when using=20
'bundles://loopback/tcp://localhost:5000' as the<BR>&gt; &gt;&gt; &gt;=20
destination tuple, the bundleDaemon log looks more promising =
(see<BR>&gt;=20
&gt;&gt; &gt; below, with sender and receiver command lines further =
down).=20
the<BR>&gt; &gt;&gt; &gt; message<BR>&gt; &gt;&gt; &gt;<BR>&gt; &gt;&gt; =
&gt;=20
registration dbase is as follows:<BR>&gt; &gt;&gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Registration database contains 0=20
registrations<BR>&gt; &gt;&gt; &gt;<BR>&gt; &gt;&gt; &gt; seems to =
indicate that=20
something's not quite right (the <BR>&gt; &gt;receiver has<BR>&gt; =
&gt;&gt; &gt;=20
not successfully registered to receive bundles?). apart <BR>&gt; =
&gt;from the=20
demux<BR>&gt; &gt;&gt; &gt; string i don't see a parameter that would =
allow me=20
to register<BR>&gt; &gt;&gt; &gt; interest to receive a particular =
bundle. what=20
would the common<BR>&gt; &gt;&gt; &gt; identifier be to identify the =
'end=20
points' between a 'bundle<BR>&gt; &gt;&gt; &gt; connection' (something =
that's=20
analogous to a socket in tcp)?<BR>&gt; &gt;&gt; &gt;<BR>&gt; &gt;&gt; =
&gt;=20
Josef<BR>&gt; &gt;&gt; &gt;<BR>&gt; &gt;&gt; &gt;<BR>&gt; &gt;&gt; &gt;=20
checkpoint_thread return from checkpoint was 0<BR>&gt; &gt;&gt; &gt;=20
logfile_thread about to log_archive.<BR>&gt; &gt;&gt; &gt; =
logfile_thread return=20
from log_archive is 0.<BR>&gt; &gt;&gt; &gt; sweepOldBundles:&nbsp; 0 =
records in=20
Expiration database<BR>&gt; &gt;&gt; &gt; checkpoint_thread about to=20
checkpoint.<BR>&gt; &gt;&gt; &gt; checkpoint_thread return from =
checkpoint was=20
0<BR>&gt; &gt;&gt; &gt; makeBRGFromBundleMetadata: using header and =
payload=20
files on send<BR>&gt; &gt;&gt; &gt; side.<BR>&gt; &gt;&gt; &gt;=20
db_bundle_store:&nbsp; about to store updated bundle ID 2<BR>&gt; =
&gt;&gt; &gt;=20
db_bundle_store: About to create/store bundle metadata for <BR>&gt; =
&gt;bundle=20
ID 1<BR>&gt; &gt;&gt; &gt; in database<BR>&gt; &gt;&gt; &gt;=20
db_bundle_store:&nbsp; Attempting to store bundle[1]<BR>&gt; &gt;&gt; =
&gt;=20
db_bundle_store: dbp-&gt;put of bundle [1] returned<BR>&gt; &gt;&gt; =
&gt;=20
db_bundle_store: successfully stored bundle [1], committing =
change<BR>&gt;=20
&gt;&gt; &gt; db_bundle_store: returning bundle ID 1<BR>&gt; &gt;&gt; =
&gt;=20
bundleServerAPI isForMeHelp: looking for uri<BR>&gt; &gt;&gt; &gt;=20
&gt;bundles://loopback/tcp://localhost:5000&lt;<BR>&gt; &gt;&gt; &gt;=20
db_get_matching_registrations:&nbsp; bundle_dest =
(0xbebfed5c)(loopback,<BR>&gt;=20
&gt;&gt; &gt; tcp://localhost:5000)<BR>&gt; &gt;&gt; =
&gt;&nbsp;&nbsp;&nbsp;=20
converted to uri &gt;bundles://loopback/tcp://localhost:5000&lt;<BR>&gt; =

&gt;&gt; &gt;<BR>&gt; &gt;&gt; &gt;&nbsp;&nbsp;&nbsp; registration dbase =
is as=20
follows:<BR>&gt; &gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Registration=20
database contains 0 registrations.<BR>&gt; &gt;&gt; &gt;=20
putBundleOnContactListHelp: brg:&nbsp; 0x824adb8, newCLIST:&nbsp;=20
0x8247380<BR>&gt; &gt;&gt; &gt; addBRGINFO: sz: 0, cl: state:4, type: =
-1, bytes:=20
0, vol: 0<BR>&gt; &gt;&gt; &gt; incrBundleRefCount:&nbsp; =
bundleInfo(0x824bf38),=20
current refcount(0)(0),<BR>&gt; &gt;&gt; &gt; increment: 1<BR>&gt; =
&gt;&gt; &gt;=20
send_bundle:&nbsp; bundle 1 on receivedBundles list<BR>&gt; &gt;&gt; =
&gt;=20
deliverBundleLocally: RECEIVED BUNDLE FOR LOCAL DELIVERY to<BR>&gt; =
&gt;&gt;=20
&gt; destination:(loopback,<BR>&gt; &gt;&gt; &gt;=20
tcp://localhost:5000)db_get_matching_registrations:&nbsp; =
bundle_dest<BR>&gt;=20
&gt;&gt; &gt; (0xbebfed5c)(loopback, tcp://localhost:5000)<BR>&gt; =
&gt;&gt;=20
&gt;&nbsp;&nbsp;&nbsp; converted to uri=20
&gt;bundles://loopback/tcp://localhost:5000&lt;<BR>&gt; &gt;&gt; =
&gt;<BR>&gt;=20
&gt;&gt; &gt;&nbsp;&nbsp;&nbsp; registration dbase is as =
follows:<BR>&gt;=20
&gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Registration database =
contains 0=20
registrations.<BR>&gt; &gt;&gt; &gt; logfile_thread about to=20
log_archive.<BR>&gt; &gt;&gt; &gt; logfile_thread return from =
log_archive is=20
0.<BR>&gt; &gt;&gt; &gt; sweepOldBundles:&nbsp; 1 records in Expiration=20
database<BR>&gt; &gt;&gt; &gt; checkpoint_thread about to =
checkpoint.<BR>&gt;=20
&gt;&gt; &gt; checkpoint_thread return from checkpoint was 0<BR>&gt; =
&gt;&gt;=20
&gt;<BR>&gt; &gt;&gt; &gt;<BR>&gt; &gt;&gt; &gt; receiver command =
line:<BR>&gt;=20
&gt;&gt; &gt;<BR>&gt; &gt;&gt; &gt; [jkriegl@stargate myapps]$ ./brecv =
-n3600=20
-slocal -d5<BR>&gt; &gt;&gt; &gt; # polling_rcvrrc<BR>&gt; &gt;&gt; &gt; =

#<BR>&gt; &gt;&gt; &gt; # This file was generaged as the result of =
a<BR>&gt;=20
&gt;&gt; &gt; #&nbsp;&nbsp; '-w' argument to polling_rcvr.&nbsp; Future =
uses=20
of<BR>&gt; &gt;&gt; &gt; #&nbsp;&nbsp; '-w' will overwrite this =
file.<BR>&gt;=20
&gt;&gt; &gt; #<BR>&gt; &gt;&gt; &gt; bahost: localhost<BR>&gt; &gt;&gt; =
&gt;=20
demuxString: local<BR>&gt; &gt;&gt; &gt; iterator: 0<BR>&gt; &gt;&gt; =
&gt;=20
debug: 5<BR>&gt; &gt;&gt; &gt; polling_rcvr: ***opening bundle agent on =
host=20
localhost<BR>&gt; &gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Bundle agent=20
open.<BR>&gt; &gt;&gt; &gt; creating local tuple...<BR>&gt; &gt;&gt; =
&gt;=20
-&gt;bundles://loopback/tcp://localhost:5000&lt;- [41, 19]<BR>&gt; =
&gt;&gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
^<BR>&gt; &gt;&gt; &gt; polling for tuple:<BR>&gt; &gt;&gt; &gt;=20
-&gt;bundles://loopback/tcp://localhost:5000&lt;- [41, 19]<BR>&gt; =
&gt;&gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
^<BR>&gt; &gt;&gt; &gt; Bundle poll iterator set to 0<BR>&gt; &gt;&gt;=20
&gt;<BR>&gt; &gt;&gt; &gt;<BR>&gt; &gt;&gt; &gt; sender command =
line:<BR>&gt;=20
&gt;&gt; &gt;<BR>&gt; &gt;&gt; &gt; [jkriegl@stargate myapps]$ ./bsend=20
-d5<BR>&gt; &gt;&gt; &gt; -Dbundles://loopback/tcp://localhost:5000 -f=20
Makefile<BR>&gt; &gt;&gt; &gt; # snd_bundlerc<BR>&gt; &gt;&gt; &gt; =
#<BR>&gt;=20
&gt;&gt; &gt; # This file was generaged as the result of a<BR>&gt; =
&gt;&gt; &gt;=20
#&nbsp;&nbsp; '-w' argument to snd_bundle.&nbsp; Future uses of<BR>&gt; =
&gt;&gt;=20
&gt; #&nbsp;&nbsp; '-w' will overwrite this file.<BR>&gt; &gt;&gt; &gt;=20
#<BR>&gt; &gt;&gt; &gt; bahost: localhost<BR>&gt; &gt;&gt; &gt; baport:=20
0<BR>&gt; &gt;&gt; &gt; bundle_data:<BR>&gt; &gt;&gt; &gt; fname:=20
Makefile<BR>&gt; &gt;&gt; &gt; sourceIntf:<BR>&gt; &gt;&gt; &gt;=20
localstuff:<BR>&gt; &gt;&gt; &gt; destTuple:=20
bundles://loopback/tcp://localhost:5000<BR>&gt; &gt;&gt; &gt; expire:=20
100<BR>&gt; &gt;&gt; &gt; pollForResponse: 0<BR>&gt; &gt;&gt; &gt; =
debug:=20
5<BR>&gt; &gt;&gt; &gt; SND BUNDLE:&nbsp; ***opening bundle agent on =
host=20
localhost:0<BR>&gt; &gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Bundle agent =
on host=20
localhost open.<BR>&gt; &gt;&gt; &gt; snd_bundle: building local tuple=20
(intf:&gt;&lt;, localstuff:&gt;&lt;)<BR>&gt; &gt;&gt; &gt;=20
-&gt;bundles://loopback/tcp://localhost:5000&lt;- [41, 19]<BR>&gt; =
&gt;&gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
^<BR>&gt; &gt;&gt; &gt; snd_bundle: building destination tuple:<BR>&gt; =
&gt;&gt;=20
&gt; (bundles://loopback/tcp://localhost:5000)<BR>&gt; &gt;&gt; &gt;=20
-&gt;bundles://loopback/tcp://localhost:5000&lt;- [39, 18]<BR>&gt; =
&gt;&gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
^<BR>&gt; &gt;&gt; &gt; sending bundle from file =
&lt;Makefile&gt;...<BR>&gt;=20
&gt;&gt; &gt;<BR>&gt; &gt;&gt; &gt; ***all done (success)<BR>&gt; =
&gt;&gt; &gt;=20
[jkriegl@stargate myapps]$<BR>&gt; &gt;&gt; &gt;<BR>&gt; &gt;&gt; =
&gt;<BR>&gt;=20
&gt;&gt; &gt; ----- Original Message ----- <BR>&gt; &gt;&gt; &gt; From: =
Josef=20
Kriegl<BR>&gt; &gt;&gt; &gt; To: [email-masked]<BR>&gt; =
&gt;&gt;=20
&gt; Sent: Tuesday, May 18, 2004 2:21 PM<BR>&gt; &gt;&gt; &gt; Subject:=20
[dtn-interest] running the sample applications<BR>&gt; &gt;&gt; =
&gt;<BR>&gt;=20
&gt;&gt; &gt; Hi Keith,<BR>&gt; &gt;&gt; &gt;<BR>&gt; &gt;&gt; &gt; i am =
trying=20
to run the DTN command line sample <BR>&gt; &gt;applications =
snd_bundle<BR>&gt;=20
&gt;&gt; &gt; and poll_recv (on x86 for now, because we are still =
having<BR>&gt;=20
&gt;&gt; &gt; difficulties getting the berkeley db to work on xscale and =
sh4).=20
i<BR>&gt; &gt;&gt; &gt; realize that i first need to better understand =
the=20
various concepts<BR>&gt; &gt;&gt; &gt; behind DTN and the meanings of =
the=20
various command line params. can<BR>&gt; &gt;&gt; &gt; you recommend a=20
particular document for this? if you could <BR>&gt; &gt;show me =
a<BR>&gt;=20
&gt;&gt; &gt; few command lines that are know to work for the =
cases<BR>&gt;=20
&gt;&gt; &gt;<BR>&gt; &gt;&gt; &gt; 1) localhost communication between =
sender=20
and receiver<BR>&gt; &gt;&gt; &gt; 2) comm between 2 machines on the =
same lan=20
(1q hop)<BR>&gt; &gt;&gt; &gt;<BR>&gt; &gt;&gt; &gt; i think that would =
help me=20
a lot to get started.<BR>&gt; &gt;&gt; &gt;<BR>&gt; &gt;&gt; &gt;=20
thanks,<BR>&gt; &gt;&gt; &gt; Josef<BR>&gt; &gt;&gt; &gt;<BR>&gt; =
&gt;&gt; &gt;=20
p.s. in the case of 2 machines on the same LAN (1 hop, no <BR>&gt; =
&gt;routing)=20
i<BR>&gt; &gt;&gt; &gt; launched the bundle daemon, but don't know if i =
need to=20
<BR>&gt; &gt;run any of the<BR>&gt; &gt;&gt; &gt; other system binaries=20
(contactManager, bundleRelay<BR>&gt; &gt;&gt; &gt; before/concurrently). =
the=20
command line arguments sourceIntf,<BR>&gt; &gt;&gt; &gt; localstuff, =
destTuple=20
are not clear to me, neither how the <BR>&gt; &gt;demuxString<BR>&gt; =
&gt;&gt;=20
&gt; relates to any of them on the receiver side.<BR>&gt; &gt;&gt; =
&gt;<BR>&gt;=20
&gt;&gt; &gt; i tried the following snd_bundle command line trying to =
send a=20
file<BR>&gt; &gt;&gt; &gt; from machine A to B, saw a bundle daemon =
response on=20
the <BR>&gt; &gt;sending host:<BR>&gt; &gt;&gt; &gt;<BR>&gt; &gt;&gt; =
&gt;=20
./bsend -d5 -Ihost -lapp -D <BR>&gt; =
&gt;bundles://internet/tcp://10.2.106.220=20
-f<BR>&gt; &gt;&gt; &gt; Makefile<BR>&gt; &gt;&gt; &gt;<BR>&gt; &gt;&gt; =
&gt;=20
...<BR>&gt; &gt;&gt; &gt; bundleServerAPI isForMeHelp: looking for =
uri<BR>&gt;=20
&gt;&gt; &gt; &gt;bundles://internet/tcp://10.2.106.220&lt;<BR>&gt; =
&gt;&gt;=20
&gt; isForMeHelp: unable to validate format of admin part<BR>&gt; =
&gt;&gt; &gt;=20
&gt;tcp://10.2.106.220&lt;<BR>&gt; &gt;&gt; &gt; =
putBundleOnContactListHelp:=20
brg:&nbsp; 0x8247d58, newCLIST:&nbsp; 0x82451f8<BR>&gt; &gt;&gt; &gt;=20
addBRGINFO: sz: 0, cl: state:4, type: -1, bytes: 43439, vol: 0<BR>&gt; =
&gt;&gt;=20
&gt; incrBundleRefCount:&nbsp; bundleInfo(0x8247c28), current=20
refcount(0)(0),<BR>&gt; &gt;&gt; &gt; increment: 1<BR>&gt; &gt;&gt; &gt; =

send_bundle:&nbsp; bundle 10 on receivedBundles list<BR>&gt; &gt;&gt; =
&gt;=20
deliverBundleLocally: RECEIVED BUNDLE FOR LOCAL DELIVERY to<BR>&gt; =
&gt;&gt;=20
&gt; destination:(internet,<BR>&gt; &gt;&gt; &gt;=20
tcp://10.2.106.220)db_get_matching_registrations:&nbsp; =
bundle_dest<BR>&gt;=20
&gt;&gt; &gt; (0xbebfed5c)(internet, tcp://10.2.106.220)<BR>&gt; =
&gt;&gt;=20
&gt;&nbsp;&nbsp;&nbsp; converted to uri=20
&gt;bundles://internet/tcp://10.2.106.220&lt;<BR>&gt; &gt;&gt; =
&gt;<BR>&gt;=20
&gt;&gt; &gt;&nbsp;&nbsp;&nbsp; registration dbase is as =
follows:<BR>&gt;=20
&gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Registration database =
contains 0=20
registrations.<BR>&gt; &gt;&gt; &gt;<BR>&gt; &gt;&gt; &gt;<BR>&gt;=20
&gt;&gt;<BR>&gt; &gt;&gt;=20
_______________________________________________<BR>&gt; &gt;&gt; =
dtn-interest=20
mailing list<BR>&gt; &gt;&gt; [email-masked]<BR>&gt; =
&gt;&gt;=20
http://mailman.dtnrg.org/mailman/listinfo/dtn-interest<BR>&gt; =
&gt;&gt;<BR>&gt;=20
&gt;<BR>&gt; &gt;<BR>&gt;=20
&gt;_______________________________________________<BR>&gt; =
&gt;dtn-interest=20
mailing list<BR>&gt; &gt;[email-masked]<BR>&gt;=20
&gt;http://mailman.dtnrg.org/mailman/listinfo/dtn-interest<BR>&gt; =
&gt;<BR>&gt;=20
<BR>&gt; <BR>&gt; </FONT></DIV></BODY></HTML>

------=_NextPart_000_068F_01C43DAB.F2C698E0--

Date: Wed, 19 May 2004 13:10:56 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Re: LTP limits
Sender: [email-masked]

> Sorry to be so dense about this; can you explain to me an example where 
> this is a problem?

- RS lower-bound+claim.offset+claim.length can exceed max-sdnv.
- DS offset+length can get exceed max-sdnv.

I think that's all.

> [...YOUREKIDDING...]
> Yes, this would certainly be an interoperability issue; when I said it 
> was just an implementation matter I meant (and should have said) that I 
> thought we shouldn't extend the protocol in this way -- that we instead 
> should leave it to the implementation to decide what to do about a data 
> segment length that it can't accommodate.

Tend to agree.

Stephen.

Date: Wed, 19 May 2004 04:49:44 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Re: LTP limits
Sender: [email-masked]

At 10:43 AM 5/19/2004 +0100, Stephen Farrell wrote:

>Scott,
>
>>>[...finite maximum...]
>>I'm still dubious that anything like this is needed in the spec, as I 
>>don't yet see how whatever we say will affect interoperability.  Why 
>>isn't it just an implementation decision?
>
>I think a spec that has a finite size/length field has to tell
>implementers how to handle values that exceed the maximum. While
>it may be improbable that someone has a segment/block that big,
>presumably we do want to allow it or else we'd cange the limits to
>a smaller value. (And then the problem recurs.)
>
>Its an interop issue since both sides' code has to decide whether
>1==max+1 or whatever.
>
>Can't see a way around this one.

Except I don't see how there are going to be values that exceed the 
maximum.  In the case of data segment length, for example, the value that 
the receiver sees can't exceed the maximum because the largest value that 
can be conveyed by the protocol, which is (of course) the maximum; the 
value inserted by the sender is entirely a matter of implementation (and it 
likewise can't exceed the maximum without deviating from compliance with 
the protocol).

Sorry to be so dense about this; can you explain to me an example where 
this is a problem?

>>>Should there be a cancel segment reasoncode (e.g. "YOUREKIDDIING":-)
>>>and maybe a supported-maximum field for that case? Might be no harm
>>>to tell the other guy you only support smaller blocks, though
>>>I guess I could well be opening a rathole here.
> >
>>Yeah, I again think this is just an implementation matter.
>
>Really? If we are allowing the following flow then it has to be
>in the spec (not that I'm convinced we ought to allow it!):
>
>O->R: DS(EOB,session=something,data-length=100k)
>R->O: C(session=something,YOUREKIDDING,1500)
>O->R: CA (session=something)
>O->R: DS(session=something-else,length=1500)
>[...]
>O->R: DS(session=something-else,length=1500)
>R->O: RS...
>
>In that scenario the originator's code has to know how to interpret
>the "1500" value in the C segment. Again, this would be clearly
>an interop issue were we to support it. (The reason I'm not that
>keen to support it is that its a rathole and maybe ought to be
>handled along with naming/addressing/scheduling/etc.)

Yes, this would certainly be an interoperability issue; when I said it was 
just an implementation matter I meant (and should have said) that I thought 
we shouldn't extend the protocol in this way -- that we instead should 
leave it to the implementation to decide what to do about a data segment 
length that it can't accommodate.

Scott 

Date: Wed, 19 May 2004 10:43:27 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: [dtn-interest] Re: LTP limits
Sender: [email-masked]

Scott,

>> [...finite maximum...]
> 
> I'm still dubious that anything like this is needed in the spec, as I 
> don't yet see how whatever we say will affect interoperability.  Why 
> isn't it just an implementation decision?

I think a spec that has a finite size/length field has to tell
implementers how to handle values that exceed the maximum. While
it may be improbable that someone has a segment/block that big,
presumably we do want to allow it or else we'd cange the limits to
a smaller value. (And then the problem recurs.)

Its an interop issue since both sides' code has to decide whether
1==max+1 or whatever.

Can't see a way around this one.

>> Should there be a cancel segment reasoncode (e.g. "YOUREKIDDIING":-)
>> and maybe a supported-maximum field for that case? Might be no harm
>> to tell the other guy you only support smaller blocks, though
>> I guess I could well be opening a rathole here.
 >
> Yeah, I again think this is just an implementation matter.

Really? If we are allowing the following flow then it has to be
in the spec (not that I'm convinced we ought to allow it!):

O->R: DS(EOB,session=something,data-length=100k)
R->O: C(session=something,YOUREKIDDING,1500)
O->R: CA (session=something)
O->R: DS(session=something-else,length=1500)
[...]
O->R: DS(session=something-else,length=1500)
R->O: RS...

In that scenario the originator's code has to know how to interpret
the "1500" value in the C segment. Again, this would be clearly
an interop issue were we to support it. (The reason I'm not that
keen to support it is that its a rathole and maybe ought to be
handled along with naming/addressing/scheduling/etc.)

Stephen.

To: [email-masked]
Date: Tue, 18 May 2004 18:24:37 -0700
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] DTNRG meeting at IETF - save the date
Sender: [email-masked]

I have an initial ok from IETF for holding a DTNRG meeting the last day
of the upcoming IETF meeting in San Diego (http://www.ietf.org/meetings/IETF-60.html).
I am still working out the details (like, paying for a room), but the likelihood
is the afternoon on friday.

thanks,
- K

Date: Tue, 18 May 2004 14:51:28 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: LTP limits (was: Re: [dtn-interest] my comments on LTP)
Sender: [email-masked]

At 01:00 PM 5/18/2004 +0100, Stephen Farrell wrote:

>Scott,
>
>>[...]
>>I would much prefer to avoid enshrining these kinds of limits in the spec 
>>and then writing about what you do when they get violated.
>
>I guess I agree in principle. But, in practice, since there are presumably 
>layers above LTP, not having such enormous block and
>segment sizes in in LTP itself is IMO quite defensible. And of
>course 4GB is still a *lot* of bytes for a single segment/block.
>
>Even if we keep with the current SDNV encodings of those fields,
>we still do have a finite maximum, and still have to analyse and
>document all the corner cases where e.g. an RS lower-bound + offset
>+ length is greater than that maximum (ok, I guess it can't happen
>since you'd not be able to encode the RS's upper-bound field, but
>then we need to say that in the spec, or else define a wrap-around
>scheme as perhaps Kevin was hinting).

I'm still dubious that anything like this is needed in the spec, as I don't 
yet see how whatever we say will affect interoperability.  Why isn't it 
just an implementation decision?

>>If implementation simplicity is the only issue, then just establish the 
>>limits in the implementation.
>
>Actually, its not a problem with the codec (which I initially wrote
>to handle big SDNVs), but more with stuff like malloc - its a real
>PITA to have to write code to handle buffers bigger than sizeof(int)
>just in case we get such a thing! So I didn't:-) My codec will
>properly barf values that are too big. I'll probably also have to
>figure out some smaller limit later on to avoid potential platform
>problems (I won't have anything near 4GB of RAM or even CF!)
>
>Should there be a cancel segment reasoncode (e.g. "YOUREKIDDIING":-)
>and maybe a supported-maximum field for that case? Might be no harm
>to tell the other guy you only support smaller blocks, though
>I guess I could well be opening a rathole here.

Yeah, I again think this is just an implementation matter.

> > [...] For example, you can make offset, length,
> > etc. all 32-bit fields simply by always using SDNVs that are 32 bits
> > long when you create the segments: always set the first octet to
> > 10000010 (indicating 3 bytes of value) and right-justify your value
> > into the next three octets regardless of what it is (up to 16,777,215,
> > which  -- like 2^32 - 1 -- is probably long enough for a lot of
> > applications).  Perfectly compliant, and pretty simple.
>
>Actually, that raises another (v. small) issue I've been wondering
>about:- current SNDV(-16) encoding means that 0x01FF and 0x8101FF
>and even 0x820001FF all represent the same value (0x1FF). I guess
>it'd be no harm to encourage people to use the most terse encoding,
>but would that be a MUST, SHOULD or MAY? (I'd go for SHOULD.)

I agree.

Scott 

Date: Tue, 18 May 2004 14:41:56 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] use of "massively parallel" in ltp draft
Sender: [email-masked]

At 05:10 PM 5/18/2004 +0100, Stephen Farrell wrote:

>Wes,
>
>Sounds reasonable to me (though I wasn't the originator
>of the term),
>
>Ta,
>Stephen.
>
>Wesley Eddy wrote:
>
>>Despite the chapter titled "massively parallel state retention" in the
>>LTP draft, it isn't quite clear why this state retention is massively
>>parallel.  The way it reads, the state information is retained by a
>>single node for many blocks of data, for a possibly long period of time.
>>The term "massively parallel" sort of indicates that the state would be
>>spread amongst multiple nodes, which doesn't seem to be the case here, I
>>think we're talking about keeping state for a lot of blocks at once
>>rather than on a lot of nodes at once.

Right, if the term "parallel" always connotes "parallel processors" then we 
shouldn't use it here.

>>The terminology doesn't seem to be crucial, so I suggest that the
>>concept of "massively parallel state retention" instead be described as
>>"massive simultaneous state retention" or "long-lived simultaneous state
>>retention".  I think those phrases capture the essence of the concept a
>>little better without confusing it with typical notions of computational
>>parallelism.  Or another approach might be to clearly define "parallel"
>>early on in the draft to mean "lots of blocks in flight" or something to
>>that effect.

Maybe we don't even need any particular term for this concept.  We're 
talking about multiple concurrent state machines, one per block, but I 
guess TCP (for example) similarly has multiple concurrent state machines, 
one per connection: although there is simultaneous (or parallel) state 
retention and transition in TCP, there doesn't seem to be any need for a 
term that says so.

Scott 

From: "Keith Scott" <[email-masked]>
To: "'Josef Kriegl'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [dtn-interest] running the sample applications
Date: Tue, 18 May 2004 12:22:59 -0400
Organization: The MITRE Corporation
Sender: [email-masked]

The /etc/bundles/route file was designed for inter-region routing; in fact
I'm pretty sure it won't be consulted if the routing node has an interface
in the destination region.

The implementation as it stands wants to have 'pretty good' connectivity
within a region.  (Dynamic) kernel routing can tell bundling how to get to
the next (configured inter-region) bundle hop, but can't really say much
about what that hop should be.  The latter is the job of the
yet-to-be-developed bundle routing protocol, which I think is where' you're
headed.  We've talked a bit about inter-region bundle routing, but it's not
in the implementation.

Once you get to dynamic routing, you've made it to the bleeding edge of this
implementation.  There is, for example, a 'management UDP port' that can be
used like a routing socket to inject routes into bundling's inter-region
routing table.  The management port is incomplete, undocumented, and not
supported, and there's not yet a routing protocol to do the injection.

		--keith

>-----Original Message-----
>From: Josef Kriegl [mailto:[email-masked]] 
>Sent: Tuesday, May 18, 2004 12:11 PM
>To: Keith Scott
>Subject: Re: [dtn-interest] running the sample applications
>
>thanks, Keith, works now for me. had problems earlier because 
>of a missing /
>separator in the bundleNode.conf file (the last one that 
>separates the demux
>string from the rest).
>
>any comments on how the kernel routing table could be used instead of a
>static routing file?
>
>fyi - i also noticed that the bundle API document is outdated, 
>some of the
>API calls must have changed since the last release (then 
>again, i should not
>consider the source code from the head as an official release ;-)
>
>thanks for your help,
>
>Josef
>
>----- Original Message ----- 
>From: "Keith Scott" <[email-masked]>
>To: "Josef Kriegl" <[email-masked]>
>Cc: <[email-masked]>
>Sent: Tuesday, May 18, 2004 5:30 PM
>Subject: Re: [dtn-interest] running the sample applications
>
>
>> For comms between two machines on the same LAN (actually 
>works between
>> any two routable machines provided the admin part of the 
>receiver can be
>> used at the sender):
>>
>> Put both machines in the same region (I use 'internet' in the example
>> below).  Whatever you use in the admin part at the receiver (e.g.
>> foo1.mitre.org:5000) is what you'll need to supply in the 
>'-D' argument
>> at the sender.  Note that using foo1's IP address at the sender and a
>> hostname at the receiver will NOT work.  There are probably problems
>> running bundle daemons behind NAT boxes.
>>
>> Machine 1 bundleNode.conf
>> # interface bundles://internet/tcp:foo1.mitre.org:5000/ ondemand
>>
>> Machine 2 bundleNode.conf
>> # interface bundles://internet/tcp:foo2.mitre.org:5000/ ondemand
>>
>> Get bundle daemons running on both machines, use asyncRcvr 
>to register a
>> receive tuple and then sndBundle2 at the sending machine.
>>
>> A caveat: the receiver will use the first interface entry to 
>construct
>> the registration unless you specify a substring of the desired entry
>> with the '-I SUBSTRING' option.  If you have an unused 
>interface as the
>> first entry in bundleNode.conf, you'll be needing '-I' at 
>the receiver.
>>
>> --keith
>>
>> ===========================
>>
>>
>> PS: attached are the script files for SINGLE-MACHINE testing 
>(sorry bout
>> that).
>>
>>
>> On Tue, 2004-05-18 at 08:21, Josef Kriegl wrote:
>> > Hi Keith,
>> >
>> > i am trying to run the DTN command line sample 
>applications snd_bundle
>> > and poll_recv (on x86 for now, because we are still having
>> > difficulties getting the berkeley db to work on xscale and sh4). i
>> > realize that i first need to better understand the various concepts
>> > behind DTN and the meanings of the various command line params. can
>> > you recommend a particular document for this? if you could 
>show me a
>> > few command lines that are know to work for the cases
>> >
>> > 1) localhost communication between sender and receiver
>> > 2) comm between 2 machines on the same lan (1q hop)
>> >
>> > i think that would help me a lot to get started.
>> >
>> > thanks,
>> > Josef
>> >
>> > p.s. in the case of 2 machines on the same LAN (1 hop, no 
>routing) i
>> > launched the bundle daemon, but don't know if i need to 
>run any of the
>> > other system binaries (contactManager, bundleRelay
>> > before/concurrently). the command line arguments sourceIntf,
>> > localstuff, destTuple are not clear to me, neither how the 
>demuxString
>> > relates to any of them on the receiver side.
>> >
>> > i tried the following snd_bundle command line trying to send a file
>> > from machine A to B, saw a bundle daemon response on the 
>sending host:
>> >
>> > ./bsend -d5 -Ihost -lapp -D 
>bundles://internet/tcp://10.2.106.220 -f
>> > Makefile
>> >
>> > ...
>> > bundleServerAPI isForMeHelp: looking for uri
>> > >bundles://internet/tcp://10.2.106.220<
>> > isForMeHelp: unable to validate format of admin part
>> > >tcp://10.2.106.220<
>> > putBundleOnContactListHelp: brg:  0x8247d58, newCLIST:  0x82451f8
>> > addBRGINFO: sz: 0, cl: state:4, type: -1, bytes: 43439, vol: 0
>> > incrBundleRefCount:  bundleInfo(0x8247c28), current refcount(0)(0),
>> > increment: 1
>> > send_bundle:  bundle 10 on receivedBundles list
>> > deliverBundleLocally: RECEIVED BUNDLE FOR LOCAL DELIVERY to
>> > destination:(internet,
>> > tcp://10.2.106.220)db_get_matching_registrations:  bundle_dest
>> > (0xbebfed5c)(internet, tcp://10.2.106.220)
>> >    converted to uri >bundles://internet/tcp://10.2.106.220<
>> >
>> >    registration dbase is as follows:
>> >      Registration database contains 0 registrations.
>> >
>> >
>>
>
>
>

From: "Robert C. Durst" <[email-masked]>
To: "'Josef Kriegl'" <[email-masked]>, <[email-masked]>
Subject: RE: [dtn-interest] dynamic routes
Date: Tue, 18 May 2004 12:16:34 -0400
Organization: The MITRE Corporation
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_002B_01C43CD1.F5EEB5F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Josef,
 
I, personally, am just starting to do this.  Am looking at running DTN over
OLSR-based subnetworks.  I'm not yet to implementation, but am planning to
consume the OLSR tables at the DTN layer, and to build some history to try
to identify where good store-and-forward points would be, etc.  Have not yet
thought too deeply about implementation, but plan to let OLSR do its thing,
modifying the kernel routing table, and work DTN routing as an overlay,
where I would pick a next-hop DTN endpoint that is not necessarily a
next-hop OLSR endpoint.  Again, am just starting this.  Sorry it's still
pretty squishy.
 
Regards,
Bob Durst

  _____  

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Josef Kriegl
Sent: Tuesday, May 18, 2004 11:44 AM
To: [email-masked]
Subject: [dtn-interest] dynamic routes

i notice that with the use of the /etc/bundles/route file routes between
inter- and intraregion hosts have to be set up in a static manner.

we are working with manet routers such as olsr and aodv over wireless links,
which essentially employ an on-demand route discovery process to determine
the route between any 2 nodes in the ad hoc network. links are frequently
intermittent, due to node mobility, however, if node density and
distribution are sufficient, the route discovery process may typically pick
one out of multiple possible routes (e.g. based on shortest path, highest
link stability, etc.)

there are application domains (sensor networks) where end to end
connectivity between any two nodes cannot always be guaranteed (due to node
mobility, changing physical channel characteristics, node failure, etc) and
we are thinking that store and forward may help with intermittent end-to-end
routes.

in the current dtn implementation, the file /etc/bundles/route is key in
determining the next hop towards the destination. this does not quite fit
with our scheme where aodv/olsr modify the kernel routing table. my question
is therefore: have there been efforts within the dtn community to allow for
dynamic route updates, or are there estimates what it would take to modify
the bundleDaemon to employ the kernel routing table, rather than rely on a
static set of routes?
 
thanks,
Josef

------=_NextPart_000_002B_01C43CD1.F5EEB5F0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff background=3D"">
<DIV dir=3Dltr align=3Dleft><SPAN class=3D506310816-18052004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Josef,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D506310816-18052004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D506310816-18052004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I, personally, am just starting to do =
this.&nbsp; Am=20
looking at running DTN over OLSR-based subnetworks.&nbsp; I'm not yet to =

implementation, but am planning to consume the OLSR tables at the DTN =
layer, and=20
to build some history to try to identify where good store-and-forward =
points=20
would be, etc.&nbsp; Have not yet thought too deeply about =
implementation, but=20
plan to let OLSR do its thing, modifying the kernel routing table, and =
work DTN=20
routing as an overlay, where I would pick a next-hop DTN endpoint that =
is not=20
necessarily a next-hop OLSR endpoint.&nbsp; Again, am just starting =
this.&nbsp;=20
Sorry it's still pretty squishy.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D506310816-18052004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D506310816-18052004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Regards,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D506310816-18052004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Bob Durst</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> =
[email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of =
</B>Josef=20
  Kriegl<BR><B>Sent:</B> Tuesday, May 18, 2004 11:44 AM<BR><B>To:</B>=20
  [email-masked]<BR><B>Subject:</B> [dtn-interest] =
dynamic=20
  routes<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2></FONT><BR><FONT =
face=3D"Courier New"=20
  size=3D2>i notice that with the use of the /etc/bundles/route file =
routes=20
  between inter- and intraregion hosts have to be set up in a static=20
  manner.<BR><BR>we are working with manet routers such as olsr and aodv =
over=20
  wireless links, which essentially employ an on-demand route discovery =
process=20
  to determine the route between any 2 nodes in the ad hoc network. =
links are=20
  frequently intermittent, due to node mobility, however, if node =
density and=20
  distribution are sufficient, the route discovery process may typically =
pick=20
  one out of multiple possible routes (e.g. based on shortest path, =
highest link=20
  stability, etc.)<BR><BR>there are application domains (sensor =
networks) where=20
  end to end connectivity between any two nodes cannot always be =
guaranteed (due=20
  to node mobility, changing physical channel characteristics, node =
failure,=20
  etc) and we are thinking that store and forward may help with =
intermittent=20
  end-to-end routes.<BR><BR>in the current dtn implementation, the file=20
  /etc/bundles/route is key in determining the next hop towards the =
destination.=20
  this does not quite fit with our scheme where aodv/olsr modify the =
kernel=20
  routing table. my question is therefore: have there been efforts =
within the=20
  dtn community to allow for dynamic route updates, or are there =
estimates what=20
  it would take to modify the bundleDaemon to employ the kernel routing =
table,=20
  rather than rely on a static set of routes?</FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>thanks,</FONT></DIV>
  <DIV><FONT face=3D"Courier New"=20
size=3D2>Josef</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_002B_01C43CD1.F5EEB5F0--

Date: Tue, 18 May 2004 17:10:42 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] use of "massively parallel" in ltp draft
Sender: [email-masked]

Wes,

Sounds reasonable to me (though I wasn't the originator
of the term),

Ta,
Stephen.

Wesley Eddy wrote:

> Despite the chapter titled "massively parallel state retention" in the
> LTP draft, it isn't quite clear why this state retention is massively
> parallel.  The way it reads, the state information is retained by a
> single node for many blocks of data, for a possibly long period of time.
> The term "massively parallel" sort of indicates that the state would be
> spread amongst multiple nodes, which doesn't seem to be the case here, I
> think we're talking about keeping state for a lot of blocks at once
> rather than on a lot of nodes at once.
> 
> The terminology doesn't seem to be crucial, so I suggest that the
> concept of "massively parallel state retention" instead be described as
> "massive simultaneous state retention" or "long-lived simultaneous state
> retention".  I think those phrases capture the essence of the concept a
> little better without confusing it with typical notions of computational
> parallelism.  Or another approach might be to clearly define "parallel"
> early on in the draft to mean "lots of blocks in flight" or something to
> that effect.
> 
> -Wes

From: "Josef Kriegl" <[email-masked]>
To: <[email-masked]>
Date: Tue, 18 May 2004 17:44:27 +0200
Subject: [dtn-interest] dynamic routes
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0433_01C43CFF.C4236EC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

i notice that with the use of the /etc/bundles/route file routes between =
inter- and intraregion hosts have to be set up in a static manner.

we are working with manet routers such as olsr and aodv over wireless =
links, which essentially employ an on-demand route discovery process to =
determine the route between any 2 nodes in the ad hoc network. links are =
frequently intermittent, due to node mobility, however, if node density =
and distribution are sufficient, the route discovery process may =
typically pick one out of multiple possible routes (e.g. based on =
shortest path, highest link stability, etc.)

there are application domains (sensor networks) where end to end =
connectivity between any two nodes cannot always be guaranteed (due to =
node mobility, changing physical channel characteristics, node failure, =
etc) and we are thinking that store and forward may help with =
intermittent end-to-end routes.

in the current dtn implementation, the file /etc/bundles/route is key in =
determining the next hop towards the destination. this does not quite =
fit with our scheme where aodv/olsr modify the kernel routing table. my =
question is therefore: have there been efforts within the dtn community =
to allow for dynamic route updates, or are there estimates what it would =
take to modify the bundleDaemon to employ the kernel routing table, =
rather than rely on a static set of routes?

thanks,
Josef
------=_NextPart_000_0433_01C43CFF.C4236EC0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff background=3D"">
<DIV><FONT face=3D"Courier New" size=3D2></FONT><BR><FONT =
face=3D"Courier New"=20
size=3D2>i notice that with the use of the /etc/bundles/route file =
routes between=20
inter- and intraregion hosts have to be set up in a static =
manner.<BR><BR>we are=20
working with manet routers such as olsr and aodv over wireless links, =
which=20
essentially employ an on-demand route discovery process to determine the =
route=20
between any 2 nodes in the ad hoc network. links are frequently =
intermittent,=20
due to node mobility, however, if node density and distribution are =
sufficient,=20
the route discovery process may typically pick one out of multiple =
possible=20
routes (e.g. based on shortest path, highest link stability, =
etc.)<BR><BR>there=20
are application domains (sensor networks) where end to end connectivity =
between=20
any two nodes cannot always be guaranteed (due to node mobility, =
changing=20
physical channel characteristics, node failure, etc) and we are thinking =
that=20
store and forward may help with intermittent end-to-end =
routes.<BR><BR>in the=20
current dtn implementation, the file /etc/bundles/route is key in =
determining=20
the next hop towards the destination. this does not quite fit with our =
scheme=20
where aodv/olsr modify the kernel routing table. my question is =
therefore: have=20
there been efforts within the dtn community to allow for dynamic route =
updates,=20
or are there estimates what it would take to modify the bundleDaemon to =
employ=20
the kernel routing table, rather than rely on a static set of=20
routes?</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>thanks,</FONT></DIV>
<DIV><FONT face=3D"Courier New" =
size=3D2>Josef</FONT></DIV></BODY></HTML>

------=_NextPart_000_0433_01C43CFF.C4236EC0--

Date: Tue, 18 May 2004 11:32:52 -0400
From: Wesley Eddy <[email-masked]>
To: [email-masked]
Reply-To: [email-masked]
Subject: [dtn-interest] use of "massively parallel" in ltp draft
Sender: [email-masked]

--ikeVEW9yuYc//A+q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Despite the chapter titled "massively parallel state retention" in the
LTP draft, it isn't quite clear why this state retention is massively
parallel.  The way it reads, the state information is retained by a
single node for many blocks of data, for a possibly long period of time.
The term "massively parallel" sort of indicates that the state would be
spread amongst multiple nodes, which doesn't seem to be the case here, I
think we're talking about keeping state for a lot of blocks at once
rather than on a lot of nodes at once.

The terminology doesn't seem to be crucial, so I suggest that the
concept of "massively parallel state retention" instead be described as
"massive simultaneous state retention" or "long-lived simultaneous state
retention".  I think those phrases capture the essence of the concept a
little better without confusing it with typical notions of computational
parallelism.  Or another approach might be to clearly define "parallel"
early on in the draft to mean "lots of blocks in flight" or something to
that effect.

-Wes

--ikeVEW9yuYc//A+q
Content-Type: application/pgp-signature
Content-Disposition: inline

--ikeVEW9yuYc//A+q--

Date: Tue, 18 May 2004 11:30:56 -0400
From: Keith Scott <[email-masked]>
Subject: Re: [dtn-interest] running the sample applications
To: Josef Kriegl <[email-masked]>
Cc: [email-masked]
Organization: The MITRE Corporation
Sender: [email-masked]

--Boundary_(ID_xCc5DxgkDWdi0GAu2T0JQw)
Content-type: text/plain
Content-transfer-encoding: 7BIT

For comms between two machines on the same LAN (actually works between
any two routable machines provided the admin part of the receiver can be
used at the sender):

Put both machines in the same region (I use 'internet' in the example
below).  Whatever you use in the admin part at the receiver (e.g.
foo1.mitre.org:5000) is what you'll need to supply in the '-D' argument
at the sender.  Note that using foo1's IP address at the sender and a
hostname at the receiver will NOT work.  There are probably problems
running bundle daemons behind NAT boxes.

	Machine 1 bundleNode.conf
	# interface bundles://internet/tcp:foo1.mitre.org:5000/ ondemand

	Machine 2 bundleNode.conf
	# interface bundles://internet/tcp:foo2.mitre.org:5000/ ondemand

Get bundle daemons running on both machines, use asyncRcvr to register a
receive tuple and then sndBundle2 at the sending machine.

A caveat: the receiver will use the first interface entry to construct
the registration unless you specify a substring of the desired entry
with the '-I SUBSTRING' option.  If you have an unused interface as the
first entry in bundleNode.conf, you'll be needing '-I' at the receiver.

		--keith

===========================

PS: attached are the script files for SINGLE-MACHINE testing (sorry bout
that).

On Tue, 2004-05-18 at 08:21, Josef Kriegl wrote:
> Hi Keith,
>  
> i am trying to run the DTN command line sample applications snd_bundle
> and poll_recv (on x86 for now, because we are still having
> difficulties getting the berkeley db to work on xscale and sh4). i
> realize that i first need to better understand the various concepts
> behind DTN and the meanings of the various command line params. can
> you recommend a particular document for this? if you could show me a
> few command lines that are know to work for the cases
>  
> 1) localhost communication between sender and receiver
> 2) comm between 2 machines on the same lan (1q hop)
>  
> i think that would help me a lot to get started.
>  
> thanks,
> Josef
>  
> p.s. in the case of 2 machines on the same LAN (1 hop, no routing) i
> launched the bundle daemon, but don't know if i need to run any of the
> other system binaries (contactManager, bundleRelay
> before/concurrently). the command line arguments sourceIntf,
> localstuff, destTuple are not clear to me, neither how the demuxString
> relates to any of them on the receiver side.
>  
> i tried the following snd_bundle command line trying to send a file
> from machine A to B, saw a bundle daemon response on the sending host:
>  
> ./bsend -d5 -Ihost -lapp -D bundles://internet/tcp://10.2.106.220 -f
> Makefile
>  
> ...
> bundleServerAPI isForMeHelp: looking for uri
> >bundles://internet/tcp://10.2.106.220<
> isForMeHelp: unable to validate format of admin part
> >tcp://10.2.106.220<
> putBundleOnContactListHelp: brg:  0x8247d58, newCLIST:  0x82451f8
> addBRGINFO: sz: 0, cl: state:4, type: -1, bytes: 43439, vol: 0
> incrBundleRefCount:  bundleInfo(0x8247c28), current refcount(0)(0),
> increment: 1
> send_bundle:  bundle 10 on receivedBundles list
> deliverBundleLocally: RECEIVED BUNDLE FOR LOCAL DELIVERY to
> destination:(internet,
> tcp://10.2.106.220)db_get_matching_registrations:  bundle_dest
> (0xbebfed5c)(internet, tcp://10.2.106.220)
>    converted to uri >bundles://internet/tcp://10.2.106.220<
>  
>    registration dbase is as follows:
>      Registration database contains 0 registrations.
>  
>  

--Boundary_(ID_xCc5DxgkDWdi0GAu2T0JQw)
Content-type: application/x-compressed-tar; name=bundleDaemon_samples.tgz
Content-transfer-encoding: base64
Content-disposition: attachment; filename=bundleDaemon_samples.tgz

--Boundary_(ID_xCc5DxgkDWdi0GAu2T0JQw)--

From: "Josef Kriegl" <[email-masked]>
To: <[email-masked]>
Subject: Re: Fw: [dtn-interest] running the sample applications
Date: Tue, 18 May 2004 17:19:47 +0200
Sender: [email-masked]

Hi Keith,

thanks (the attachment is missing, though).

meanwhile, i was able to run both apps, however, the receiver does not
report incoming bundles (although the bundle daemon logs look ok, no
errors).

i am confused about the -s parameter, it's semantics, how it influences the
interface entries in the bundleNode.conf file, etc. can you enlighten me on
this?

here are the configuration files and command lines i currently use on two
x86 machines:

sender (10.2.106.9):

/etc/bundles/bundleNode.conf:
# ...
interface bundles://internet/tcp://10.2.106.9:5000 ondemand
#
# for loopback testing:
# interface bundles://loopback/tcp://localhost:5000 ondemand

/etc/bundles/route:
internet internet 10.2.106.220 ONDEMAND

/etc/bundles/route:
internet internet 10.2.106.220 ONDEMAND

./snd_bundle -d5 -Dbundles://internet/tcp://10.2.106.220:5000 -f
`pwd`/Makefile

receiver (10.2.106.220):

/etc/bundles/bundleNode.conf:
# ...
interface bundles://internet/tcp://10.2.106.220:5000 ondemand

./AsyncRcvr/async_rcvr -slocalstuff

----- Original Message ----- 
From: "Keith Scott" <[email-masked]>
To: "Josef Kriegl" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, May 18, 2004 5:06 PM
Subject: Re: Fw: [dtn-interest] running the sample applications

> Sorry, some sort of document needs to describe this.
>
> The most tested applications are SndBundle2 (the command line version)
> and AsyncRcvr.  Start with these.
>
> I have attached a .tgz file with script output from starting a bundle
> daemon, asyncRcvr, and sndBundle2 on the same machine, and using the TCP
> convergence layer to send a bundle via a fictitious 'loopback' region.
>
> When you register with asyncRcvr, then a 's' command at the bundleDaemon
> should show you one registration.  The format in which the registration
> is printed is suitable for cutting and pasting as the argument to the
> '-D' argument to sndBundle2.
>
>
>
> On Tue, 2004-05-18 at 10:09, Josef Kriegl wrote:
> >
> > to further elaborate on my attempts to send a bundle between 2
> > processes on the local machine:
> >
> > when using 'bundles://loopback/tcp://localhost:5000' as the
> > destination tuple, the bundleDaemon log looks more promising (see
> > below, with sender and receiver command lines further down). the
> > message
> >
> > registration dbase is as follows:
> >      Registration database contains 0 registrations
> >
> > seems to indicate that something's not quite right (the receiver has
> > not successfully registered to receive bundles?). apart from the demux
> > string i don't see a parameter that would allow me to register
> > interest to receive a particular bundle. what would the common
> > identifier be to identify the 'end points' between a 'bundle
> > connection' (something that's analogous to a socket in tcp)?
> >
> > Josef
> >
> >
> > checkpoint_thread return from checkpoint was 0
> > logfile_thread about to log_archive.
> > logfile_thread return from log_archive is 0.
> > sweepOldBundles:  0 records in Expiration database
> > checkpoint_thread about to checkpoint.
> > checkpoint_thread return from checkpoint was 0
> > makeBRGFromBundleMetadata: using header and payload files on send
> > side.
> > db_bundle_store:  about to store updated bundle ID 2
> > db_bundle_store: About to create/store bundle metadata for bundle ID 1
> > in database
> > db_bundle_store:  Attempting to store bundle[1]
> > db_bundle_store: dbp->put of bundle [1] returned
> > db_bundle_store: successfully stored bundle [1], committing change
> > db_bundle_store: returning bundle ID 1
> > bundleServerAPI isForMeHelp: looking for uri
> > >bundles://loopback/tcp://localhost:5000<
> > db_get_matching_registrations:  bundle_dest (0xbebfed5c)(loopback,
> > tcp://localhost:5000)
> >    converted to uri >bundles://loopback/tcp://localhost:5000<
> >
> >    registration dbase is as follows:
> >      Registration database contains 0 registrations.
> > putBundleOnContactListHelp: brg:  0x824adb8, newCLIST:  0x8247380
> > addBRGINFO: sz: 0, cl: state:4, type: -1, bytes: 0, vol: 0
> > incrBundleRefCount:  bundleInfo(0x824bf38), current refcount(0)(0),
> > increment: 1
> > send_bundle:  bundle 1 on receivedBundles list
> > deliverBundleLocally: RECEIVED BUNDLE FOR LOCAL DELIVERY to
> > destination:(loopback,
> > tcp://localhost:5000)db_get_matching_registrations:  bundle_dest
> > (0xbebfed5c)(loopback, tcp://localhost:5000)
> >    converted to uri >bundles://loopback/tcp://localhost:5000<
> >
> >    registration dbase is as follows:
> >      Registration database contains 0 registrations.
> > logfile_thread about to log_archive.
> > logfile_thread return from log_archive is 0.
> > sweepOldBundles:  1 records in Expiration database
> > checkpoint_thread about to checkpoint.
> > checkpoint_thread return from checkpoint was 0
> >
> >
> > receiver command line:
> >
> > [jkriegl@stargate myapps]$ ./brecv -n3600 -slocal -d5
> > # polling_rcvrrc
> > #
> > # This file was generaged as the result of a
> > #   '-w' argument to polling_rcvr.  Future uses of
> > #   '-w' will overwrite this file.
> > #
> > bahost: localhost
> > demuxString: local
> > iterator: 0
> > debug: 5
> > polling_rcvr: ***opening bundle agent on host localhost
> >     Bundle agent open.
> > creating local tuple...
> > ->bundles://loopback/tcp://localhost:5000<- [41, 19]
> >                      ^
> > polling for tuple:
> > ->bundles://loopback/tcp://localhost:5000<- [41, 19]
> >                      ^
> > Bundle poll iterator set to 0
> >
> >
> > sender command line:
> >
> > [jkriegl@stargate myapps]$ ./bsend -d5
> > -Dbundles://loopback/tcp://localhost:5000 -f Makefile
> > # snd_bundlerc
> > #
> > # This file was generaged as the result of a
> > #   '-w' argument to snd_bundle.  Future uses of
> > #   '-w' will overwrite this file.
> > #
> > bahost: localhost
> > baport: 0
> > bundle_data:
> > fname: Makefile
> > sourceIntf:
> > localstuff:
> > destTuple: bundles://loopback/tcp://localhost:5000
> > expire: 100
> > pollForResponse: 0
> > debug: 5
> > SND BUNDLE:  ***opening bundle agent on host localhost:0
> >     Bundle agent on host localhost open.
> > snd_bundle: building local tuple (intf:><, localstuff:><)
> > ->bundles://loopback/tcp://localhost:5000<- [41, 19]
> >                      ^
> > snd_bundle: building destination tuple:
> > (bundles://loopback/tcp://localhost:5000)
> > ->bundles://loopback/tcp://localhost:5000<- [39, 18]
> >                     ^
> > sending bundle from file <Makefile>...
> >
> > ***all done (success)
> > [jkriegl@stargate myapps]$
> >
> >
> > ----- Original Message ----- 
> > From: Josef Kriegl
> > To: [email-masked]
> > Sent: Tuesday, May 18, 2004 2:21 PM
> > Subject: [dtn-interest] running the sample applications
> >
> > Hi Keith,
> >
> > i am trying to run the DTN command line sample applications snd_bundle
> > and poll_recv (on x86 for now, because we are still having
> > difficulties getting the berkeley db to work on xscale and sh4). i
> > realize that i first need to better understand the various concepts
> > behind DTN and the meanings of the various command line params. can
> > you recommend a particular document for this? if you could show me a
> > few command lines that are know to work for the cases
> >
> > 1) localhost communication between sender and receiver
> > 2) comm between 2 machines on the same lan (1q hop)
> >
> > i think that would help me a lot to get started.
> >
> > thanks,
> > Josef
> >
> > p.s. in the case of 2 machines on the same LAN (1 hop, no routing) i
> > launched the bundle daemon, but don't know if i need to run any of the
> > other system binaries (contactManager, bundleRelay
> > before/concurrently). the command line arguments sourceIntf,
> > localstuff, destTuple are not clear to me, neither how the demuxString
> > relates to any of them on the receiver side.
> >
> > i tried the following snd_bundle command line trying to send a file
> > from machine A to B, saw a bundle daemon response on the sending host:
> >
> > ./bsend -d5 -Ihost -lapp -D bundles://internet/tcp://10.2.106.220 -f
> > Makefile
> >
> > ...
> > bundleServerAPI isForMeHelp: looking for uri
> > >bundles://internet/tcp://10.2.106.220<
> > isForMeHelp: unable to validate format of admin part
> > >tcp://10.2.106.220<
> > putBundleOnContactListHelp: brg:  0x8247d58, newCLIST:  0x82451f8
> > addBRGINFO: sz: 0, cl: state:4, type: -1, bytes: 43439, vol: 0
> > incrBundleRefCount:  bundleInfo(0x8247c28), current refcount(0)(0),
> > increment: 1
> > send_bundle:  bundle 10 on receivedBundles list
> > deliverBundleLocally: RECEIVED BUNDLE FOR LOCAL DELIVERY to
> > destination:(internet,
> > tcp://10.2.106.220)db_get_matching_registrations:  bundle_dest
> > (0xbebfed5c)(internet, tcp://10.2.106.220)
> >    converted to uri >bundles://internet/tcp://10.2.106.220<
> >
> >    registration dbase is as follows:
> >      Registration database contains 0 registrations.
> >
> >
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Date: Tue, 18 May 2004 11:06:04 -0400
From: Keith Scott <[email-masked]>
Subject: Re: Fw: [dtn-interest] running the sample applications
To: Josef Kriegl <[email-masked]>
Cc: [email-masked]
Organization: The MITRE Corporation
Sender: [email-masked]

Sorry, some sort of document needs to describe this.

The most tested applications are SndBundle2 (the command line version)
and AsyncRcvr.  Start with these.

I have attached a .tgz file with script output from starting a bundle
daemon, asyncRcvr, and sndBundle2 on the same machine, and using the TCP
convergence layer to send a bundle via a fictitious 'loopback' region.

When you register with asyncRcvr, then a 's' command at the bundleDaemon
should show you one registration.  The format in which the registration
is printed is suitable for cutting and pasting as the argument to the
'-D' argument to sndBundle2.

On Tue, 2004-05-18 at 10:09, Josef Kriegl wrote:
>  
> to further elaborate on my attempts to send a bundle between 2
> processes on the local machine:
>  
> when using 'bundles://loopback/tcp://localhost:5000' as the
> destination tuple, the bundleDaemon log looks more promising (see
> below, with sender and receiver command lines further down). the
> message
>  
> registration dbase is as follows:
>      Registration database contains 0 registrations
>  
> seems to indicate that something's not quite right (the receiver has
> not successfully registered to receive bundles?). apart from the demux
> string i don't see a parameter that would allow me to register
> interest to receive a particular bundle. what would the common
> identifier be to identify the 'end points' between a 'bundle
> connection' (something that's analogous to a socket in tcp)?
>  
> Josef
>  
>  
> checkpoint_thread return from checkpoint was 0
> logfile_thread about to log_archive.
> logfile_thread return from log_archive is 0.
> sweepOldBundles:  0 records in Expiration database
> checkpoint_thread about to checkpoint.
> checkpoint_thread return from checkpoint was 0
> makeBRGFromBundleMetadata: using header and payload files on send
> side.
> db_bundle_store:  about to store updated bundle ID 2
> db_bundle_store: About to create/store bundle metadata for bundle ID 1
> in database
> db_bundle_store:  Attempting to store bundle[1]
> db_bundle_store: dbp->put of bundle [1] returned
> db_bundle_store: successfully stored bundle [1], committing change
> db_bundle_store: returning bundle ID 1
> bundleServerAPI isForMeHelp: looking for uri
> >bundles://loopback/tcp://localhost:5000<
> db_get_matching_registrations:  bundle_dest (0xbebfed5c)(loopback,
> tcp://localhost:5000)
>    converted to uri >bundles://loopback/tcp://localhost:5000<
>  
>    registration dbase is as follows:
>      Registration database contains 0 registrations.
> putBundleOnContactListHelp: brg:  0x824adb8, newCLIST:  0x8247380
> addBRGINFO: sz: 0, cl: state:4, type: -1, bytes: 0, vol: 0
> incrBundleRefCount:  bundleInfo(0x824bf38), current refcount(0)(0),
> increment: 1
> send_bundle:  bundle 1 on receivedBundles list
> deliverBundleLocally: RECEIVED BUNDLE FOR LOCAL DELIVERY to
> destination:(loopback,
> tcp://localhost:5000)db_get_matching_registrations:  bundle_dest
> (0xbebfed5c)(loopback, tcp://localhost:5000)
>    converted to uri >bundles://loopback/tcp://localhost:5000<
>  
>    registration dbase is as follows:
>      Registration database contains 0 registrations.
> logfile_thread about to log_archive.
> logfile_thread return from log_archive is 0.
> sweepOldBundles:  1 records in Expiration database
> checkpoint_thread about to checkpoint.
> checkpoint_thread return from checkpoint was 0
>  
>  
> receiver command line:
>  
> [jkriegl@stargate myapps]$ ./brecv -n3600 -slocal -d5
> # polling_rcvrrc
> #
> # This file was generaged as the result of a
> #   '-w' argument to polling_rcvr.  Future uses of
> #   '-w' will overwrite this file.
> #
> bahost: localhost
> demuxString: local
> iterator: 0
> debug: 5
> polling_rcvr: ***opening bundle agent on host localhost
>     Bundle agent open.
> creating local tuple...
> ->bundles://loopback/tcp://localhost:5000<- [41, 19]
>                      ^
> polling for tuple:
> ->bundles://loopback/tcp://localhost:5000<- [41, 19]
>                      ^
> Bundle poll iterator set to 0
>  
>  
> sender command line:
>  
> [jkriegl@stargate myapps]$ ./bsend -d5
> -Dbundles://loopback/tcp://localhost:5000 -f Makefile 
> # snd_bundlerc
> #
> # This file was generaged as the result of a
> #   '-w' argument to snd_bundle.  Future uses of
> #   '-w' will overwrite this file.
> #
> bahost: localhost
> baport: 0
> bundle_data: 
> fname: Makefile
> sourceIntf: 
> localstuff: 
> destTuple: bundles://loopback/tcp://localhost:5000
> expire: 100
> pollForResponse: 0
> debug: 5
> SND BUNDLE:  ***opening bundle agent on host localhost:0
>     Bundle agent on host localhost open.
> snd_bundle: building local tuple (intf:><, localstuff:><)
> ->bundles://loopback/tcp://localhost:5000<- [41, 19]
>                      ^
> snd_bundle: building destination tuple:
> (bundles://loopback/tcp://localhost:5000)
> ->bundles://loopback/tcp://localhost:5000<- [39, 18]
>                     ^
> sending bundle from file <Makefile>...
>  
> ***all done (success)
> [jkriegl@stargate myapps]$ 
>  
>  
> ----- Original Message ----- 
> From: Josef Kriegl
> To: [email-masked]
> Sent: Tuesday, May 18, 2004 2:21 PM
> Subject: [dtn-interest] running the sample applications
> 
> Hi Keith,
>  
> i am trying to run the DTN command line sample applications snd_bundle
> and poll_recv (on x86 for now, because we are still having
> difficulties getting the berkeley db to work on xscale and sh4). i
> realize that i first need to better understand the various concepts
> behind DTN and the meanings of the various command line params. can
> you recommend a particular document for this? if you could show me a
> few command lines that are know to work for the cases
>  
> 1) localhost communication between sender and receiver
> 2) comm between 2 machines on the same lan (1q hop)
>  
> i think that would help me a lot to get started.
>  
> thanks,
> Josef
>  
> p.s. in the case of 2 machines on the same LAN (1 hop, no routing) i
> launched the bundle daemon, but don't know if i need to run any of the
> other system binaries (contactManager, bundleRelay
> before/concurrently). the command line arguments sourceIntf,
> localstuff, destTuple are not clear to me, neither how the demuxString
> relates to any of them on the receiver side.
>  
> i tried the following snd_bundle command line trying to send a file
> from machine A to B, saw a bundle daemon response on the sending host:
>  
> ./bsend -d5 -Ihost -lapp -D bundles://internet/tcp://10.2.106.220 -f
> Makefile
>  
> ...
> bundleServerAPI isForMeHelp: looking for uri
> >bundles://internet/tcp://10.2.106.220<
> isForMeHelp: unable to validate format of admin part
> >tcp://10.2.106.220<
> putBundleOnContactListHelp: brg:  0x8247d58, newCLIST:  0x82451f8
> addBRGINFO: sz: 0, cl: state:4, type: -1, bytes: 43439, vol: 0
> incrBundleRefCount:  bundleInfo(0x8247c28), current refcount(0)(0),
> increment: 1
> send_bundle:  bundle 10 on receivedBundles list
> deliverBundleLocally: RECEIVED BUNDLE FOR LOCAL DELIVERY to
> destination:(internet,
> tcp://10.2.106.220)db_get_matching_registrations:  bundle_dest
> (0xbebfed5c)(internet, tcp://10.2.106.220)
>    converted to uri >bundles://internet/tcp://10.2.106.220<
>  
>    registration dbase is as follows:
>      Registration database contains 0 registrations.
>  
>  

From: "Josef Kriegl" <[email-masked]>
To: <[email-masked]>
Subject: Fw: [dtn-interest] running the sample applications
Date: Tue, 18 May 2004 16:09:59 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0370_01C43CF2.918214B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

to further elaborate on my attempts to send a bundle between 2 processes =
on the local machine:

when using 'bundles://loopback/tcp://localhost:5000' as the destination =
tuple, the bundleDaemon log looks more promising (see below, with sender =
and receiver command lines further down). the message

registration dbase is as follows:
     Registration database contains 0 registrations

seems to indicate that something's not quite right (the receiver has not =
successfully registered to receive bundles?). apart from the demux =
string i don't see a parameter that would allow me to register interest =
to receive a particular bundle. what would the common identifier be to =
identify the 'end points' between a 'bundle connection' (something =
that's analogous to a socket in tcp)?

Josef

checkpoint_thread return from checkpoint was 0
logfile_thread about to log_archive.
logfile_thread return from log_archive is 0.
sweepOldBundles:  0 records in Expiration database
checkpoint_thread about to checkpoint.
checkpoint_thread return from checkpoint was 0
makeBRGFromBundleMetadata: using header and payload files on send side.
db_bundle_store:  about to store updated bundle ID 2
db_bundle_store: About to create/store bundle metadata for bundle ID 1 =
in database
db_bundle_store:  Attempting to store bundle[1]
db_bundle_store: dbp->put of bundle [1] returned
db_bundle_store: successfully stored bundle [1], committing change
db_bundle_store: returning bundle ID 1
bundleServerAPI isForMeHelp: looking for uri =
>bundles://loopback/tcp://localhost:5000<
db_get_matching_registrations:  bundle_dest (0xbebfed5c)(loopback, =
tcp://localhost:5000)
   converted to uri >bundles://loopback/tcp://localhost:5000<

   registration dbase is as follows:
     Registration database contains 0 registrations.
putBundleOnContactListHelp: brg:  0x824adb8, newCLIST:  0x8247380
addBRGINFO: sz: 0, cl: state:4, type: -1, bytes: 0, vol: 0
incrBundleRefCount:  bundleInfo(0x824bf38), current refcount(0)(0), =
increment: 1
send_bundle:  bundle 1 on receivedBundles list
deliverBundleLocally: RECEIVED BUNDLE FOR LOCAL DELIVERY to =
destination:(loopback, =
tcp://localhost:5000)db_get_matching_registrations:  bundle_dest =
(0xbebfed5c)(loopback, tcp://localhost:5000)
   converted to uri >bundles://loopback/tcp://localhost:5000<

   registration dbase is as follows:
     Registration database contains 0 registrations.
logfile_thread about to log_archive.
logfile_thread return from log_archive is 0.
sweepOldBundles:  1 records in Expiration database
checkpoint_thread about to checkpoint.
checkpoint_thread return from checkpoint was 0

receiver command line:

[jkriegl@stargate myapps]$ ./brecv -n3600 -slocal -d5
# polling_rcvrrc
#
# This file was generaged as the result of a
#   '-w' argument to polling_rcvr.  Future uses of
#   '-w' will overwrite this file.
#
bahost: localhost
demuxString: local
iterator: 0
debug: 5
polling_rcvr: ***opening bundle agent on host localhost
    Bundle agent open.
creating local tuple...
->bundles://loopback/tcp://localhost:5000<- [41, 19]
                     ^
polling for tuple:
->bundles://loopback/tcp://localhost:5000<- [41, 19]
                     ^
Bundle poll iterator set to 0

sender command line:

[jkriegl@stargate myapps]$ ./bsend -d5 =
-Dbundles://loopback/tcp://localhost:5000 -f Makefile=20
# snd_bundlerc
#
# This file was generaged as the result of a
#   '-w' argument to snd_bundle.  Future uses of
#   '-w' will overwrite this file.
#
bahost: localhost
baport: 0
bundle_data:=20
fname: Makefile
sourceIntf:=20
localstuff:=20
destTuple: bundles://loopback/tcp://localhost:5000
expire: 100
pollForResponse: 0
debug: 5
SND BUNDLE:  ***opening bundle agent on host localhost:0
    Bundle agent on host localhost open.
snd_bundle: building local tuple (intf:><, localstuff:><)
->bundles://loopback/tcp://localhost:5000<- [41, 19]
                     ^
snd_bundle: building destination tuple: =
(bundles://loopback/tcp://localhost:5000)
->bundles://loopback/tcp://localhost:5000<- [39, 18]
                    ^
sending bundle from file <Makefile>...

***all done (success)
[jkriegl@stargate myapps]$=20

----- Original Message -----=20
From: Josef Kriegl=20
To: [email-masked]=20
Sent: Tuesday, May 18, 2004 2:21 PM
Subject: [dtn-interest] running the sample applications

Hi Keith,

i am trying to run the DTN command line sample applications snd_bundle =
and poll_recv (on x86 for now, because we are still having difficulties =
getting the berkeley db to work on xscale and sh4). i realize that i =
first need to better understand the various concepts behind DTN and the =
meanings of the various command line params. can you recommend a =
particular document for this? if you could show me a few command lines =
that are know to work for the cases

1) localhost communication between sender and receiver
2) comm between 2 machines on the same lan (1q hop)

i think that would help me a lot to get started.

thanks,
Josef

p.s. in the case of 2 machines on the same LAN (1 hop, no routing) i =
launched the bundle daemon, but don't know if i need to run any of the =
other system binaries (contactManager, bundleRelay before/concurrently). =
the command line arguments sourceIntf, localstuff, destTuple are not =
clear to me, neither how the demuxString relates to any of them on the =
receiver side.

i tried the following snd_bundle command line trying to send a file from =
machine A to B, saw a bundle daemon response on the sending host:

./bsend -d5 -Ihost -lapp -D bundles://internet/tcp://10.2.106.220 -f =
Makefile

...
bundleServerAPI isForMeHelp: looking for uri =
>bundles://internet/tcp://10.2.106.220<
isForMeHelp: unable to validate format of admin part =
>tcp://10.2.106.220<
putBundleOnContactListHelp: brg:  0x8247d58, newCLIST:  0x82451f8
addBRGINFO: sz: 0, cl: state:4, type: -1, bytes: 43439, vol: 0
incrBundleRefCount:  bundleInfo(0x8247c28), current refcount(0)(0), =
increment: 1
send_bundle:  bundle 10 on receivedBundles list
deliverBundleLocally: RECEIVED BUNDLE FOR LOCAL DELIVERY to =
destination:(internet, tcp://10.2.106.220)db_get_matching_registrations: =
 bundle_dest (0xbebfed5c)(internet, tcp://10.2.106.220)
   converted to uri >bundles://internet/tcp://10.2.106.220<

   registration dbase is as follows:
     Registration database contains 0 registrations.

------=_NextPart_000_0370_01C43CF2.918214B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>to further elaborate on my =
attempts to send=20
a bundle between 2 processes on the local machine:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>when using=20
'bundles://loopback/tcp://localhost:5000' as the destination tuple, the=20
bundleDaemon log looks more promising (see below, with sender and =
receiver=20
command lines further down).&nbsp;the message</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>registration dbase is as=20
follows:<BR>&nbsp;&nbsp;&nbsp;&nbsp; Registration database contains 0=20
registrations</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>seems to indicate that =
something's not=20
quite right (the receiver has not successfully registered to receive =
bundles?).=20
apart from the demux string i don't see a parameter that would allow me =
to=20
register interest to receive a particular bundle. what would the common=20
identifier be to identify the 'end points' between a 'bundle connection' =

(something that's analogous to a socket in tcp)?</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Josef</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>checkpoint_thread return from =
checkpoint=20
was 0<BR>logfile_thread about to log_archive.<BR>logfile_thread return =
from=20
log_archive is 0.<BR>sweepOldBundles:&nbsp; 0 records in Expiration=20
database<BR>checkpoint_thread about to checkpoint.<BR>checkpoint_thread =
return=20
from checkpoint was 0<BR>makeBRGFromBundleMetadata: using header and =
payload=20
files on send side.<BR>db_bundle_store:&nbsp; about to store updated =
bundle ID=20
2<BR>db_bundle_store: About to create/store bundle metadata for bundle =
ID 1 in=20
database<BR>db_bundle_store:&nbsp; Attempting to store=20
bundle[1]<BR>db_bundle_store: dbp-&gt;put of bundle [1]=20
returned<BR>db_bundle_store: successfully stored bundle [1], committing=20
change<BR>db_bundle_store: returning bundle ID 1<BR>bundleServerAPI =
isForMeHelp:=20
looking for uri=20
&gt;bundles://loopback/tcp://localhost:5000&lt;<BR>db_get_matching_regist=
rations:&nbsp;=20
bundle_dest (0xbebfed5c)(loopback, tcp://localhost:5000)<BR>&nbsp;&nbsp; =

converted to uri =
&gt;bundles://loopback/tcp://localhost:5000&lt;</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; registration dbase =
is as=20
follows:<BR>&nbsp;&nbsp;&nbsp;&nbsp; Registration database contains 0=20
registrations.<BR>putBundleOnContactListHelp: brg:&nbsp; 0x824adb8,=20
newCLIST:&nbsp; 0x8247380<BR>addBRGINFO: sz: 0, cl: state:4, type: -1, =
bytes: 0,=20
vol: 0<BR>incrBundleRefCount:&nbsp; bundleInfo(0x824bf38), current=20
refcount(0)(0), increment: 1<BR>send_bundle:&nbsp; bundle 1 on =
receivedBundles=20
list<BR>deliverBundleLocally: RECEIVED BUNDLE FOR LOCAL DELIVERY to=20
destination:(loopback, =
tcp://localhost:5000)db_get_matching_registrations:&nbsp;=20
bundle_dest (0xbebfed5c)(loopback, tcp://localhost:5000)<BR>&nbsp;&nbsp; =

converted to uri =
&gt;bundles://loopback/tcp://localhost:5000&lt;</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; registration dbase =
is as=20
follows:<BR>&nbsp;&nbsp;&nbsp;&nbsp; Registration database contains 0=20
registrations.<BR>logfile_thread about to log_archive.<BR>logfile_thread =
return=20
from log_archive is 0.<BR>sweepOldBundles:&nbsp; 1 records in Expiration =

database<BR>checkpoint_thread about to checkpoint.<BR>checkpoint_thread =
return=20
from checkpoint was 0</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>receiver command =
line:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>[jkriegl@stargate myapps]$ =
./brecv -n3600=20
-slocal -d5<BR># polling_rcvrrc<BR>#<BR># This file was generaged as the =
result=20
of a<BR>#&nbsp;&nbsp; '-w' argument to polling_rcvr.&nbsp; Future uses=20
of<BR>#&nbsp;&nbsp; '-w' will overwrite this file.<BR>#<BR>bahost:=20
localhost<BR>demuxString: local<BR>iterator: 0<BR>debug: =
5<BR>polling_rcvr:=20
***opening bundle agent on host localhost<BR>&nbsp;&nbsp;&nbsp; Bundle =
agent=20
open.<BR>creating local=20
tuple...<BR>-&gt;bundles://loopback/tcp://localhost:5000&lt;- [41,=20
19]<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
^<BR>polling for =
tuple:<BR>-&gt;bundles://loopback/tcp://localhost:5000&lt;-=20
[41,=20
19]<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
^<BR>Bundle poll iterator set to 0</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>sender command =
line:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>[jkriegl@stargate myapps]$ =
./bsend -d5=20
-Dbundles://loopback/tcp://localhost:5000 -f Makefile <BR>#=20
snd_bundlerc<BR>#<BR># This file was generaged as the result of=20
a<BR>#&nbsp;&nbsp; '-w' argument to snd_bundle.&nbsp; Future uses=20
of<BR>#&nbsp;&nbsp; '-w' will overwrite this file.<BR>#<BR>bahost:=20
localhost<BR>baport: 0<BR>bundle_data: <BR>fname: =
Makefile<BR>sourceIntf:=20
<BR>localstuff: <BR>destTuple:=20
bundles://loopback/tcp://localhost:5000<BR>expire: =
100<BR>pollForResponse:=20
0<BR>debug: 5<BR>SND BUNDLE:&nbsp; ***opening bundle agent on host=20
localhost:0<BR>&nbsp;&nbsp;&nbsp; Bundle agent on host localhost=20
open.<BR>snd_bundle: building local tuple (intf:&gt;&lt;,=20
localstuff:&gt;&lt;)<BR>-&gt;bundles://loopback/tcp://localhost:5000&lt;-=
 [41,=20
19]<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
^<BR>snd_bundle: building destination tuple:=20
(bundles://loopback/tcp://localhost:5000)<BR>-&gt;bundles://loopback/tcp:=
//localhost:5000&lt;-=20
[39,=20
18]<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
^<BR>sending bundle from file &lt;Makefile&gt;...</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>***all done =
(success)<BR>[jkriegl@stargate=20
myapps]$ </FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV style=3D"FONT: 10pt arial">----- Original Message -----=20
<DIV style=3D"BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> <A=20
title=[email-masked] href=3D"mailto:[email-masked]">Josef =
Kriegl</A>=20
</DIV>
<DIV><B>To:</B> <A title=[email-masked]=20
href=3D"mailto:[email-masked]">[email-masked]=
.org</A>=20
</DIV>
<DIV><B>Sent:</B> Tuesday, May 18, 2004 2:21 PM</DIV>
<DIV><B>Subject:</B> [dtn-interest] running the sample =
applications</DIV></DIV>
<DIV><BR></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Hi Keith,</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>i am trying to run the DTN =
command line=20
sample applications snd_bundle and poll_recv (on x86 for now, because we =
are=20
still having difficulties getting the berkeley db to work on xscale and =
sh4).=20
<FONT face=3D"Courier New" size=3D2>i realize that i first need to =
better understand=20
the various concepts behind DTN and the meanings of the various command =
line=20
params. can you recommend a particular document for this? if you could =
show me a=20
few command lines that are know to work for the =
cases</FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><FONT face=3D"Courier New"=20
size=3D2></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><FONT face=3D"Courier New" =
size=3D2>1)=20
localhost communication between sender and receiver</FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><FONT face=3D"Courier New" =
size=3D2>2) comm=20
between 2 machines on the same lan (1q hop)</FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><FONT face=3D"Courier New"=20
size=3D2></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><FONT face=3D"Courier New" =
size=3D2>i think=20
that would help me a lot to get started.</FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>thanks,</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Josef</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>p.s. in the case of 2 machines =
on the same=20
LAN (1 hop, no routing)&nbsp;i launched the bundle daemon, but don't =
know if i=20
need to run any of the other system binaries (contactManager, =
bundleRelay=20
before/concurrently). the command line arguments sourceIntf, localstuff, =

destTuple&nbsp;are not clear&nbsp;to me, neither how the demuxString =
relates to=20
any of them on the receiver side.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>i tried the following =
snd_bundle command=20
line&nbsp;trying to send a file from machine A to B, saw a bundle daemon =

response on the sending host:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>./bsend -d5 -Ihost -lapp -D=20
bundles://internet/tcp://10.2.106.220 -f Makefile</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>...</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>bundleServerAPI isForMeHelp: =
looking for=20
uri &gt;bundles://internet/tcp://10.2.106.220&lt;<BR>isForMeHelp: unable =
to=20
validate format of admin part=20
&gt;tcp://10.2.106.220&lt;<BR>putBundleOnContactListHelp: brg:&nbsp; =
0x8247d58,=20
newCLIST:&nbsp; 0x82451f8<BR>addBRGINFO: sz: 0, cl: state:4, type: -1, =
bytes:=20
43439, vol: 0<BR>incrBundleRefCount:&nbsp; bundleInfo(0x8247c28), =
current=20
refcount(0)(0), increment: 1<BR>send_bundle:&nbsp; bundle 10 on =
receivedBundles=20
list<BR>deliverBundleLocally: RECEIVED BUNDLE FOR LOCAL DELIVERY to=20
destination:(internet, =
tcp://10.2.106.220)db_get_matching_registrations:&nbsp;=20
bundle_dest (0xbebfed5c)(internet, tcp://10.2.106.220)<BR>&nbsp;&nbsp; =
converted=20
to uri &gt;bundles://internet/tcp://10.2.106.220&lt;</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; registration dbase =
is as=20
follows:<BR>&nbsp;&nbsp;&nbsp;&nbsp; Registration database contains 0=20
registrations.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" =
size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0370_01C43CF2.918214B0--

From: "Josef Kriegl" <[email-masked]>
To: <[email-masked]>
Date: Tue, 18 May 2004 14:21:31 +0200
Subject: [dtn-interest] running the sample applications
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_034D_01C43CE3.6AAEF470
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Keith,

i am trying to run the DTN command line sample applications snd_bundle =
and poll_recv (on x86 for now, because we are still having difficulties =
getting the berkeley db to work on xscale and sh4). i realize that i =
first need to better understand the various concepts behind DTN and the =
meanings of the various command line params. can you recommend a =
particular document for this? if you could show me a few command lines =
that are know to work for the cases

1) localhost communication between sender and receiver
2) comm between 2 machines on the same lan (1q hop)

i think that would help me a lot to get started.

thanks,
Josef

p.s. in the case of 2 machines on the same LAN (1 hop, no routing) i =
launched the bundle daemon, but don't know if i need to run any of the =
other system binaries (contactManager, bundleRelay before/concurrently). =
the command line arguments sourceIntf, localstuff, destTuple are not =
clear to me, neither how the demuxString relates to any of them on the =
receiver side.

i tried the following snd_bundle command line trying to send a file from =
machine A to B, saw a bundle daemon response on the sending host:

./bsend -d5 -Ihost -lapp -D bundles://internet/tcp://10.2.106.220 -f =
Makefile

...
bundleServerAPI isForMeHelp: looking for uri =
>bundles://internet/tcp://10.2.106.220<
isForMeHelp: unable to validate format of admin part =
>tcp://10.2.106.220<
putBundleOnContactListHelp: brg:  0x8247d58, newCLIST:  0x82451f8
addBRGINFO: sz: 0, cl: state:4, type: -1, bytes: 43439, vol: 0
incrBundleRefCount:  bundleInfo(0x8247c28), current refcount(0)(0), =
increment: 1
send_bundle:  bundle 10 on receivedBundles list
deliverBundleLocally: RECEIVED BUNDLE FOR LOCAL DELIVERY to =
destination:(internet, tcp://10.2.106.220)db_get_matching_registrations: =
 bundle_dest (0xbebfed5c)(internet, tcp://10.2.106.220)
   converted to uri >bundles://internet/tcp://10.2.106.220<

   registration dbase is as follows:
     Registration database contains 0 registrations.

------=_NextPart_000_034D_01C43CE3.6AAEF470
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Courier New" size=3D2>Hi Keith,</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>i am trying to run the DTN =
command line=20
sample applications snd_bundle and poll_recv (on x86 for now, because we =
are=20
still having difficulties getting the berkeley db to work on xscale and =
sh4).=20
<FONT face=3D"Courier New" size=3D2>i realize that i first need to =
better understand=20
the various concepts behind DTN and the meanings of the various command =
line=20
params. can you recommend a particular document for this? if you could =
show me a=20
few command lines that are know to work for the =
cases</FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><FONT face=3D"Courier New"=20
size=3D2></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><FONT face=3D"Courier New" =
size=3D2>1)=20
localhost communication between sender and receiver</FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><FONT face=3D"Courier New" =
size=3D2>2) comm=20
between 2 machines on the same lan (1q hop)</FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><FONT face=3D"Courier New"=20
size=3D2></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><FONT face=3D"Courier New" =
size=3D2>i think=20
that would help me a lot to get started.</FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>thanks,</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Josef</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>p.s. in the case of 2 machines =
on the same=20
LAN (1 hop, no routing)&nbsp;i launched the bundle daemon, but don't =
know if i=20
need to run any of the other system binaries (contactManager, =
bundleRelay=20
before/concurrently). the command line arguments sourceIntf, localstuff, =

destTuple&nbsp;are not clear&nbsp;to me, neither how the demuxString =
relates to=20
any of them on the receiver side.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>i tried the following =
snd_bundle command=20
line&nbsp;trying to send a file from machine A to B, saw a bundle daemon =

response on the sending host:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>./bsend -d5 -Ihost -lapp -D=20
bundles://internet/tcp://10.2.106.220 -f Makefile</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>...</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>bundleServerAPI isForMeHelp: =
looking for=20
uri &gt;bundles://internet/tcp://10.2.106.220&lt;<BR>isForMeHelp: unable =
to=20
validate format of admin part=20
&gt;tcp://10.2.106.220&lt;<BR>putBundleOnContactListHelp: brg:&nbsp; =
0x8247d58,=20
newCLIST:&nbsp; 0x82451f8<BR>addBRGINFO: sz: 0, cl: state:4, type: -1, =
bytes:=20
43439, vol: 0<BR>incrBundleRefCount:&nbsp; bundleInfo(0x8247c28), =
current=20
refcount(0)(0), increment: 1<BR>send_bundle:&nbsp; bundle 10 on =
receivedBundles=20
list<BR>deliverBundleLocally: RECEIVED BUNDLE FOR LOCAL DELIVERY to=20
destination:(internet, =
tcp://10.2.106.220)db_get_matching_registrations:&nbsp;=20
bundle_dest (0xbebfed5c)(internet, tcp://10.2.106.220)<BR>&nbsp;&nbsp; =
converted=20
to uri &gt;bundles://internet/tcp://10.2.106.220&lt;</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; registration dbase =
is as=20
follows:<BR>&nbsp;&nbsp;&nbsp;&nbsp; Registration database contains 0=20
registrations.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" =
size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_034D_01C43CE3.6AAEF470--

Date: Tue, 18 May 2004 13:00:54 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: LTP limits (was: Re: [dtn-interest] my comments on LTP)
Sender: [email-masked]

Scott,

> [...]
> I would much prefer to avoid enshrining these kinds 
> of limits in the spec and then writing about what you do when they get 
> violated.

I guess I agree in principle. But, in practice, since there are 
presumably layers above LTP, not having such enormous block and
segment sizes in in LTP itself is IMO quite defensible. And of
course 4GB is still a *lot* of bytes for a single segment/block.

Even if we keep with the current SDNV encodings of those fields,
we still do have a finite maximum, and still have to analyse and
document all the corner cases where e.g. an RS lower-bound + offset
+ length is greater than that maximum (ok, I guess it can't happen
since you'd not be able to encode the RS's upper-bound field, but
then we need to say that in the spec, or else define a wrap-around
scheme as perhaps Kevin was hinting).

> If implementation simplicity is the only issue, then just establish the 
> limits in the implementation. 

Actually, its not a problem with the codec (which I initially wrote
to handle big SDNVs), but more with stuff like malloc - its a real
PITA to have to write code to handle buffers bigger than sizeof(int)
just in case we get such a thing! So I didn't:-) My codec will
properly barf values that are too big. I'll probably also have to
figure out some smaller limit later on to avoid potential platform
problems (I won't have anything near 4GB of RAM or even CF!)

Should there be a cancel segment reasoncode (e.g. "YOUREKIDDIING":-)
and maybe a supported-maximum field for that case? Might be no harm
to tell the other guy you only support smaller blocks, though
I guess I could well be opening a rathole here.

 > [...] For example, you can make offset, length,
 > etc. all 32-bit fields simply by always using SDNVs that are 32 bits
 > long when you create the segments: always set the first octet to
 > 10000010 (indicating 3 bytes of value) and right-justify your value
 > into the next three octets regardless of what it is (up to 16,777,215,
 > which  -- like 2^32 - 1 -- is probably long enough for a lot of
 > applications).  Perfectly compliant, and pretty simple.

Actually, that raises another (v. small) issue I've been wondering
about:- current SNDV(-16) encoding means that 0x01FF and 0x8101FF
and even 0x820001FF all represent the same value (0x1FF). I guess
it'd be no harm to encourage people to use the most terse encoding,
but would that be a MUST, SHOULD or MAY? (I'd go for SHOULD.)

Stephen.

Date: Mon, 17 May 2004 13:51:52 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] my comments on LTP
Sender: [email-masked]

At 04:26 PM 5/17/2004 +0100, Stephen Farrell wrote:
>>>I am concerned about the in-order assumption of 3.4.  In a world
>>>with Mars orbiters and other relays, why is it not possible that
>>>re-ordering might happen?
>>Because LTP operates only on a point-to-point link, not over a network of 
>>relays.  Physics assures that data radiated later arrives later.
>
>Yes. But I think Kevin's point is that there are certain kinds of
>re-ordering that we can easily handle, so why place restrictions on
>the lower layer that are trivial to avoid? (E.g. correct handling
>of "inner" segments arriving out of order is free; if we see EOB
>and there is still a gap in the block that's just like a dropped
>segment...).

I wouldn't impose a restriction on the lower layer, but I also wouldn't 
want to increase the complexity of the protocol simply to enable it to 
handle conditions that are possible only in environments other than those 
where it's designed to operate.  The word "trivial" makes me uneasy.  But 
sure, if a pair of data segments happen to arrive out of order without any 
intervening checkpoint, I don't see any particular advantage in requiring 
LTP to panic about it.

>>> > Section 4:
>>> >       how are engine IDs assigned?
>>An open issue.  Maybe the assignment of Ethernet MAC addresses is an analog?
>
>I don't see any need to handle this here. LTP already depends on the
>link state cues, which will have to be engine ID aware (possibly via
>some indirection like a name, but that doesn't matter). Point is, that
>its entirely fair to assume an LTP engine is provided with the other
>engine IDs of those with which it will communicate and that there are
>no collisions. That in turn means that engine ID allocation is an issue
>for another specification and/or for bilateral agreement.

This sounds right to me.

>>> > Page 27: does the handling of the queues and their priority really 
>>> belong in
>>>this discussion of the transport?  Wouldn't it be possible to use LTP 
>>>without this exact queue
>>> > configuration?
>>You're right, we could safely be a lot less explicit and prescriptive 
>>about this; the priority of the "internal operations" segments is all 
>>that's really important for interoperability (because it affects timer 
>>behavior).
>
>Must admit I'd rather that we had no priorities and I could just
>keep a single queue (which is what my current buggy code does FWIW:-).
>What changes to timer behaviour would be needed to get rid of
>priorities?

Report segments, report acknowledgements, and cancel acknowledgements have 
to go out before anything else, rather than get queued up behind outbound 
data segments for other transactions.  This is because accurate timeout 
interval computation relies in part on rough predictability in the length 
of time an acknowledging segment will spend in a queue waiting for 
transmission.

That aside, there's no particular need to prioritize outbound LTP traffic; 
it's just a capability offered to the client service, which might care 
about it.

>>>How is number wrap-around handled?
>>Which numbers?  Most of the numbers are SDNVs, which makes wrap-around 
>>unlikely.
>
>Actually, in my code I've gotten fed up assuming everything can go
>on to the full extent of SNDV (using int counters is nice:-) and
>there doesn't seem to be a compelling need for e.g. the segment
>count in an RS to get bigger than 2^32, so I'd be in favour of
>analysing which fields don't really need the full SDNV and putting
>limits on those (and hence writing about wrap-around).
>
>Fields I currently assume as < 2^32 are: ds.offset, ds.length, rs.ub,
>rs.lb, rs.cc and the claim offsets and lengths. Basically, this means
>that all blocks I handle are < 2^32 bytes long. Since I'm implementing
>a sockets-like api on top of my LTP code, really doing otherwise (as
>opposed to pretending) would be quite tricky.
>
>Is there a use case where this is a real problem?

I don't know of one.  On the other hand, there never used to be a use case 
where the number of endpoints in the Internet address space was greater 
than 2^32.  I would much prefer to avoid enshrining these kinds of limits 
in the spec and then writing about what you do when they get violated.

If implementation simplicity is the only issue, then just establish the 
limits in the implementation.  For example, you can make offset, length, 
etc. all 32-bit fields simply by always using SDNVs that are 32 bits long 
when you create the segments: always set the first octet to 10000010 
(indicating 3 bytes of value) and right-justify your value into the next 
three octets regardless of what it is (up to 16,777,215, which -- like 2^32 
- 1 -- is probably long enough for a lot of applications).  Perfectly 
compliant, and pretty simple.

Scott 

Date: Mon, 17 May 2004 16:26:36 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] my comments on LTP
Sender: [email-masked]

Scott, Kevin,

Some minor additions/quibbles below,

Stephen.

>> > With reference to out-of-order, you probably want to reference SCTP.
>> > More generally, please compare LTP with SCTP; not only TCP.
>> > Please include a discussion of why SCTP is insufficient for your needs.
>
> Good idea.

Yes. I did this some time ago and figured that SCTP [1] always needs to
be connection oriented, at least in the sense that you don't get to
send any data until you've gotten at least one ACK from the peer.
Have I missed/forgotten something or is this just a case of making
the I-D more complete? (A fine thing.)

	[1] http://www.ietf.org/rfc/rfc3257.txt

>> I am concerned about the in-order assumption of 3.4.  In a world
>> with Mars orbiters and other relays, why is it not possible that
>> re-ordering might happen?
> 
> Because LTP operates only on a point-to-point link, not over a network 
> of relays.  Physics assures that data radiated later arrives later.

Yes. But I think Kevin's point is that there are certain kinds of
re-ordering that we can easily handle, so why place restrictions on
the lower layer that are trivial to avoid? (E.g. correct handling
of "inner" segments arriving out of order is free; if we see EOB
and there is still a gap in the block that's just like a dropped
segment...).

>> > Section 4:
>> >       how are engine IDs assigned?
> 
> An open issue.  Maybe the assignment of Ethernet MAC addresses is an 
> analog?

I don't see any need to handle this here. LTP already depends on the
link state cues, which will have to be engine ID aware (possibly via
some indirection like a name, but that doesn't matter). Point is, that
its entirely fair to assume an LTP engine is provided with the other
engine IDs of those with which it will communicate and that there are
no collisions. That in turn means that engine ID allocation is an issue
for another specification and/or for bilateral agreement.

>> Is the maximum segment size dictated only by the underlying 
>> network?  In TCP it is dictated by the receiver and -not- by the 
>> underlying network.
> 
> In LTP the receiver has nothing to say about what gets sent, as there is 
> no negotiation.  

I think that the answer to Kevin's question is a definite "yes" - the
underlying network defines the MTU which defines the max segment size.
The max. block size OTOH, is determined by LTP (currently maxing out at
2^100+ bytes, but see below).

>> > Section 5.2:
>> > Can  you make a statement as to the number of timers that need be 
>> maintained at the
>> > sender/receiver?  (related issue: with TCP, there is -not- a timer 
>> per segment).
> 
> At the sender, one per checkpoint to which there has not yet been a 
> response (nominally one per outbound block, i.e., session).  At the 
> receiver, one per report to which there has not yet been a response 
> (nominally one per inbound block, i.e., session).

I also find it seems a bit complicated, but I'm starting to get to
that bit of code now(-ish) so maybe it'll be ok when I implement it.

>>   It seems that
>> > one is envisioned for every block, and perhaps every report 
>> segment.  Why are so
>> > many required?
> 
> It's not that many; as you noted above, this "massively parallel 
> transmission" may not really be so massive.

Yeah, but there are many different kinds of counter and if more than
one session is in-play in parallel (say in an Earthstation/mule)
then I at least find it a bit confusing.

>> > Page 27: does the handling of the queues and their priority really 
>> belong in
>> this discussion of the transport?  Wouldn't it be possible to use LTP 
>> without this exact queue
>> > configuration?
> 
> You're right, we could safely be a lot less explicit and prescriptive 
> about this; the priority of the "internal operations" segments is all 
> that's really important for interoperability (because it affects timer 
> behavior).

Must admit I'd rather that we had no priorities and I could just
keep a single queue (which is what my current buggy code does FWIW:-).
What changes to timer behaviour would be needed to get rid of
priorities?

>> > In section 9 it appears that a non-understood segment has to be 
>> silently discarded.  Would it
>> > not be useful to provide for some sort of notification back to the 
>> sender that it generated a
>> > badly-formed protocol message?
> 
> Could, but it opens yet another potential DoS attack.
> 
>>   I had thought there was some requirement on lower layers to
>> > do data integrity checks.  If so, then bad msgs would likely be 
>> protocol implementation errors,
>> > and would presumably be something you wish to know about.
> 
> It would likely be helpful; I'm a little worried about potential 
> security and performance impacts.  Let's think about this some more.

There is some stuff in the draft about a MIB. Maybe we should add
something there that records stats about bad segments rx'd? I'm also
reluctant to add new DoS attack points (it they are new that is, but
I think this one would be).

>> How is number wrap-around handled?
> 
> Which numbers?  Most of the numbers are SDNVs, which makes wrap-around 
> unlikely.

Actually, in my code I've gotten fed up assuming everything can go
on to the full extent of SNDV (using int counters is nice:-) and
there doesn't seem to be a compelling need for e.g. the segment
count in an RS to get bigger than 2^32, so I'd be in favour of
analysing which fields don't really need the full SDNV and putting
limits on those (and hence writing about wrap-around).

Fields I currently assume as < 2^32 are: ds.offset, ds.length, rs.ub,
rs.lb, rs.cc and the claim offsets and lengths. Basically, this means
that all blocks I handle are < 2^32 bytes long. Since I'm implementing
a sockets-like api on top of my LTP code, really doing otherwise (as
opposed to pretending) would be quite tricky.

Is there a use case where this is a real problem?

> Stephen, would you like to field these?

Fielded:-)

Date: Mon, 17 May 2004 08:59:31 -0500 (CDT)
From: "Timothy J. Salo" <[email-masked]>
To: [email-masked]
Subject: Re: LTP security considerations (Was: Re: [dtn-interest] my comments on LTP)
Sender: [email-masked]

> From: Stephen Farrell
> Subject: LTP security considerations (Was: Re: [dtn-interest] my comments
>  on LTP)
> Date: Mon, 17 May 2004 14:41:45 +0100
> 	[...]
> Perhaps. But given that a lot of overrun attacks are caused by
> coding sloppiness of this sort, I really do think its worth
> re-stating things like this. ...

Or, perhaps sloppiness in the selection of implementation
language.

-tjs

"Name one Java virus"
		Scott McNealy

Date: Mon, 17 May 2004 06:56:53 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] my comments on LTP
Sender: [email-masked]

At 08:44 AM 5/14/2004 -0700, Kevin Fall wrote:
> >
> > General comments:
> >
> > interesting reading...thanks for putting this together.
> >
> > it says its a convergence layer protocol.  But really, is it a 
> transport layer, right?

It's designed to support Bundling as an underlying protocol; you'd need a 
convergence layer adapter to mate LTP and Bundling together, exactly as you 
need a convergence layer adapter to mate Bundling to TCP/IP.

I don't know that you'd really want to call it a transport layer protocol, 
as it is designed to run directly over a single point-to-point link rather 
than over a network.

> > LTP: the name isn't exactly useful to indicate its capability.  I guess 
> this is really your
> >    decision, but the dedication seems somewhat less useful than a 
> functional description
> >       (e.g. really long delay transport protocol - RLDTP).  Also, see 
> note below
> >       about reliability vs non-reliability and the idea of layering 
> into 2 protocols.

Sure, we might very well collectively come to prefer a more descriptive 
name.  For me this is a low-priority issue.

> > It appears this protocol lacks both flow and congestion 
> control.  Perhaps understandable
> > for this environment, but some explicit statement as to how these 
> issues are dealt with would
> > be helpful.  I believe, based on my reading, that congestion doesn't 
> happen because
> > of admission control by way of the lower-layer queues.  Flow control 
> doesn't appear to
> > be discussed.  I gather that if the sender sends too much stuff for the 
> receiver to consume,
> > any excess just gets dropped on the floor.  Is this right?

Either that or the problem is simply pushed off to the layer above (Bundling).

LTP is designed to run under Bundling in pretty much the same way that 
(say) Ethernet runs under IP.  My understanding is that flow control in 
Ethernet (pause frames) is optional; Cisco edge devices, for example, don't 
implement it at all.  Because LTP never has any expectation of 
contemporaneous bidirectional data flow, the pause frame or source quench 
concept doesn't apply well.

> > Are blocks of arbitrary size?

Yes.

>If they are sort of known ahead of time, would it
> > not be better to state the block size up front, and not have to worry 
> about an
> > explicit EOB?

Right, CFDP does that, but it doesn't do you much good if you happen to 
miss the leading packet that states the size.  The EOB flag seems simpler 
and more efficient.

>Also, it appears that the capability to buffer at least one block
> > (more?) is a requirement on the underlying network.

I don't think so; LTP has to be able to buffer one or more blocks that are 
in progress, but the underlying network shouldn't be affected.

>On a related note, the idea that
> > LTP maintains the queues seems unnecessary.  All that is really appears 
> to want to do
> > is specify the relative priority of its segments.

They're conceptual queues, but maybe there's a clearer way to say that 
without suggesting an implementation.

> > More detailed comments:
> >
> > possible typo in abstract:
> >               "in the interplanetary space" -> "in interplanetary space"

Yes.

> > Also, this protocol isn't just for long RTT's, but for RTT's that you 
> can pretty
> > reliably predict... right?

Not really: you need to know the one-way light time, but you don't need to 
be able to predict the component of RTT that is due to disconnection: you 
apply that on notification via "link state cues" (see 6.3).

> > The idea of "as to simulate half duplex operation" seems sort of 
> strange to me.
> > For example, Ethernet (at least old Ethernet) is half-duplex, but that 
> does not
> > mean it was large rtt.

Yeah, maybe this concept is too weird to introduce here.

> > Section 2.1 - include a Reference[] for DSN

Sure.

> > There is mention of 'Radio contact via the DSN'.  Is it
> > too early to mention optical contact via the dsn?

I think so.  There is currently no such thing, and there aren't even any 
concrete plans to develop it.

> > Why do you choose a reference from Mathis for the TCP
> > equation?  I believe the more 'modern' reference is:
> >
> >       Padhye, Firoiu, Towsley, Kurose, "Modeling TCP Throughput: A 
> Simple Model and its
> >               Empirical Validation" Proc. SIGCOMM 1998

Using a later reference is fine with me; I think the Mathis reference was 
lifted from the DTN architecture I-D.

> > There is a typo where it says (this figure was reported by
> > Paxson.... no closing parenthesis

Good catch.

> > The phrase "link state queues" is used relatively early (section 3).

Cues, rather than queues.

>  At this point
> > in the doc we aren't really sure what those are.  Maybe a forward 
> reference to (e.g. sect 11)
> > would be useful.

You're right, it would.

> > The phrase 'like any reliable transport service, LTP is "stateful"'
> > might be better stated as something such as
> > 'like any reliable transport service employing ARQ, LTP is "stateful"

I agree.

> > Section 3.1:
> > It is trivial and well-understood that stop-and-wait works badly
> > when the RTT gets larger (ie. throughput scales as 1/RTT).  TCP
> > and other window based approaches improve this by adding a window,
> > so at least you get throughput in proportion to (W/RTT).

If including this explanatory text is insulting to the reader then we 
should remove it, at least in the (eventual) RFC.  My thought was that 
there might be some casual readers of the I-D for whom these notes might be 
helpful.

>   Related,
> > I don't see why this is called "massive".  It may not really be
> > so massive...  Actually, the entirety of section 3.1 doesn't really
> > seem that useful to me.

It's just context and tutorial; we've already agreed that most or all of it 
should be removed at some point (and possibly retained in a different 
document, that wouldn't necessarily be an I-D).

> > Section 3.1.1:
> > It is wrong to say "But while TCP permits only a single connection
> > on a given port at any time...".  A TCP "connection" is defined
> > as a 4-tuple (not a 2-tuple) of [ip/port, ip/port].  Thus it is
> > possible to re-use port numbers at one endpoint, provided they are
> > not re-used at the other as well.  Please fix.   This affects
> > your "table" as well, and is not a trivial mistake.  Indeed, this port
> > re-use is foundational to TCP.  It is the thing that allows one server
> > program to service multiple clients simultaneously.

Sure, this needs to be fixed.

>   As a related issue,
> > I don't understand how LTP handles this.

It doesn't have negotiated connections.  Each "session" is a data block 
transmission sequence that is unilaterally initiated by the sender and is 
uniquely identified by sender ID, not by a tuple.

> > What does "one at at time" mean for blocks transmitted for a TCP
> > connection? (page 10)

It's a reference to data delivery in transmission order: all of one block 
of data is delivered before any portion of the next.

> > With reference to out-of-order, you probably want to reference SCTP.
> > More generally, please compare LTP with SCTP; not only TCP.
> > Please include a discussion of why SCTP is insufficient for your needs.

Good idea.

> > Section 3.2 it talks about negotiation.  For most things there
> > is no negotiation whatsoever in TCP.  Ther is -specification-
> > (in particular limits that a receiver tells to the sender).  What
> > particular parameters were you referring to when you talk about
> > negotiation or re-negotiation?  I think maybe the word
> > 'negotiation' is misplaced here.  You can safely say that flow control
> > is accomplished by exchange of data, but that is about it.

Okay.

> > Page 12/Sec 5.4: retransmissions are only induced by arrival of a response.
> >       Cannot timers for checkpointed segments also induce 
> retransmissions?  If not, I believe
> >       you can easily deadlock, or did I miss something?

You mean 3.4 rather than 5.4, yes?  I can't find the text you're referring 
to, but I think I know what you mean.  3.4 defines a "retransmission" as a 
sequence of data segments issued in response to the arrival of a report, 
and that is probably not a wisely chosen term.  It is distinct from the 
timer-initiated retransmission of a checkpoint or report as described in 
section 5.2.

> > I am concerned about the in-order assumption of 3.4.  In a world
> > with Mars orbiters and other relays, why is it not possible that
> > re-ordering might happen?

Because LTP operates only on a point-to-point link, not over a network of 
relays.  Physics assures that data radiated later arrives later.

>   Do you envision this as a transport
> > protocol, or something radically different?

It's a link reliability protocol.  This is obviously something to emphasize 
more strongly in section 1 and in the second paragraph of section 3.4.

>   In any case, re-ordering
> > doesn't seem like it should be a big problem, especially given that
> > you are already supporting selective repeat semantics for retransmission
> > (ie. you already are willing to maintain a buffer).  I am also not really
> > convinced by the "argument" that the concept of rough determinism is
> > violated.  If you are willing to tolerate a couple of extra seconds
> > (related to your setting of the N value), then if you go through a 
> relay that
> > takes you a few extra milliseconds, you should be ok.
> >
> > I do not understand this paragraph:
> >
> >       o The massively parallel nature of LTP changes the granularity at
> >         which timer accuracy is required.  Confirmation of the reception
> >         of one block, or one segment, does not retard transmission of
> >         the next, so timeout values that would be intolerably optimistic
> >         in TCP don't constrain LTP's bandwidth utilization.

Okay, more explanatory text needed.

> > Why is this true:
> >
> >       The round-trip time for transmitted segment N could easily be
> >       orders of magnitude greater than that for segment N-1

Because segment N-1 might be the last segment to which the receiver can 
respond before the current tracking pass ends; the response to segment N 
might have to be transmitted at the beginning of the next tracking pass, 
which might be hours (rather than seconds) later.

> > Section 3.6:
> >
> >       "Link state queues also notify LTP ..."
> >
> >       "also" in addition to what?

(Cues, not queues.)  In addition to which remote LTP engines are known to 
be unable to transmit responses (section 3.5, second paragraph on page 14).

> > Section 4:
> >       how are engine IDs assigned?

An open issue.  Maybe the assignment of Ethernet MAC addresses is an analog?

> >       I think (6) [Scope] makes references to some things that are not 
> yet defined.
> >       e.g. "segment's client service data".

Good point; this is the "content" or "application data" that the data 
segment encapsulates, and we should probably say so here.

>   What unit are upper and lower bounds
> >       measured in?

Bytes (octets) -- worth saying so.

>   What happens when/if they wrap?

I don't understand how they could "wrap".  Lower bound is an offset, upper 
bound is that offset plus a length.

>   The lack of units is also
> >       a problem for other definitions [e.g. checkpoint]

What part of the definition of checkpoint refers to a number for which we 
need to indicate units?

> > Section 5: what is a 'client service instance'?

Right, we should define this somewhere in section 3.

> > Section 5.1:
> >       TCP has a state machine where the states are well-defined and 
> named.  Why don't
> >       you have something similar.  (also, see similar comment below)

Probably because we haven't drafted it yet.  A very reasonable thing to do.

> >       Is the maximum segment size dictated only by the underlying 
> network?  In TCP
> >               it is dictated by the receiver and -not- by the 
> underlying network.

In LTP the receiver has nothing to say about what gets sent, as there is no 
negotiation.  (How can this work in TCP?  I thought you said above that the 
only thing that is accomplished by exchange of data in TCP is flow control.)

> > Section 5.2:
> > Can  you make a statement as to the number of timers that need be 
> maintained at the
> > sender/receiver?  (related issue: with TCP, there is -not- a timer per 
> segment).

At the sender, one per checkpoint to which there has not yet been a 
response (nominally one per outbound block, i.e., session).  At the 
receiver, one per report to which there has not yet been a response 
(nominally one per inbound block, i.e., session).

>   It seems that
> > one is envisioned for every block, and perhaps every report 
> segment.  Why are so
> > many required?

It's not that many; as you noted above, this "massively parallel 
transmission" may not really be so massive.

> >
> > If only the SSR or RSR is closed, does the session ever terminate?

Yes, eventually all sessions terminate because eventually the timers on all 
checkpoints and reports expire.

>   See other comment
> > about general need to discuss how closing vs cancellation 
> works.  (also, if you
> > used close versus reset terminology, it would help to leverage TCP 
> terminology).

Right, we probably shouldn't be using the term "reset" anywhere.

> > Section 5.6:
> > The idea that the same protocol has both a reliable and non-reliable 
> mode seems
> > a bit troubling.  Why not define a non-reliable protocol and then
> > define the reliable protocol on top of it by way of backward reference?

What is troubling about this?

>   Can two
> > LTP speakers reasonably expect to communicate?  (i.e. if one implements 
> the reliability
> > and one doesn't?)

Yes: the receiver knows from the header whether the transmission is 
reliable or not.

> > Also (5.6) it says "but LTP's block segmentation, bandwidth management, 
> ..."
> >       What exactly -is- LTP's bandwidth management?  In particular, in 
> section 6.2
> >       where it talks about bw management it talks about 
> scheduling.  But this
> >       is not really bandwidth management.  Rather, it is a queue 
> servicing discipline.

Okay, we should change the language here.

> > Page 27: does the handling of the queues and their priority really 
> belong in
>this discussion of the transport?  Wouldn't it be possible to use LTP 
>without this exact queue
> > configuration?

You're right, we could safely be a lot less explicit and prescriptive about 
this; the priority of the "internal operations" segments is all that's 
really important for interoperability (because it affects timer behavior).

> > there seems to be the terminology 'reception claims'.  Is this new?

Good catch, it isn't defined until page 34; we should define it much earlier.

> > Section 5.2 discusses a non-zero serial number.  What happens with a 
> zero serial number?

Checkpoints with zero report serial numbers are discretionary checkpoints 
(if any) and the EOB, handled per 5.1 and 5.4 -- and you're right, this 
should be made clear and explicit.

> > Section 5.2.2 appears to address both the retransmission partitioning
> > of responsibility as well as the final close issue (the thing that TCP 
> uses the
> > MSL wait for).  As for the first argument, wouldn't it be the case
> > that a cumulative style ack very easily handles this problem?
> > As for the second part, what is the problem with the TCP-style FIN 
> exchange?
> > You already have all the mechanism to handle that, so it seems to 
> me.  Perhaps I'm
> > failing to appreciate the difference between the proposed design and 
> the TCP like
> > way of doing it.  I think this brings up the point that the whole 
> document appears
> > to lack an explicit discussion of what happens during connection 
> close.  In particular,
> > any distinction between cancellation and closing, as well as what 
> happens when various
> > segments are lost during this phase.  It is instructive to look at the 
> TCP state
> > machine, as almost all the states are related to phases of either 
> connection establishment
> > or normal connection close.

Yes, this is a strong argument for including a state machine diagram in the 
spec.

> > Section 6.3-  the penalty of under-utilization is not mentioned, yet 
> back in 3.2
> >       there is mention of "costly under-utilization of link resources"

There isn't any under-utilization of the link involved here, though; if 
your timeout interval is a few seconds too long, you pay a small penalty in 
delivery latency and excess storage consumption but the link is still 
efficiently utilized.

> >       Radiation time-  this would ordinarily be called transmission 
> delay (I think).  Is there
> >       a special reason to use this new terminology?

"Transmission delay" isn't very specific: there are lots of things that 
contribute to it, right?  I think "radiation time" as defined here is a 
more precise term.

> > I think it would be useful to include a list of requirements LTP places 
> on the underlying
> > link system.  Currently, this appears to be spread across the document 
> and is also sort of
> > aggregated in section 11.  Perhaps moving section 11 earlier and 
> expanding it would suffice.

Yes, we know we need to beef this up.

> > Section 7:
> >
> > how about some ascii art, like other rfcs?

Yes.

> > 7.1.1
> >       This sounds funny: "... that the segment
> >       carries data and is a data segment, while a value of 1 indicates"

Sure, this can be made to sound better.

> > 7.2.1
> >       checkpoint serial number has to increase, evidently without 
> resetting... ever.
> >       Is that really right?

Without resetting, for this session (i.e., for a single block).  You would 
normally have only a single checkpoint for any session, in which case it 
never increases.

>   Does persistent info need to be stored in order to
> >       be compliant?

Not if there's some other way to assure that checkpoint serial numbers are 
unique per session and are monotonically ascending.

>   Is there serial # wrap?

Probably not; it's an SDNV-8, so it can be increased to a very large value.

> > Client service ID:  why do you require the app to perform the 
> demultiplexing?
> >       The seems unfortunate.  It also relates to the discussion of 
> ports [above].

Client service ID is actually a closer analog to protocol number than to 
TCP port number, i.e., client service ID "1" might indicate 
"Bundling".  LTP is a link reliability system rather than a transport 
protocol; the app that we're requiring to do demultiplexing is nominally 
another (higher) layer of protocol, such as Bundling, so I think requiring 
it to do some demultiplexing of its own on tokens that are opaque to LTP is 
reasonable.

> > In TCP the cumulative ACK idea is useful in that it enhances ACK 
> robustness... you can
> > stand to lose one or more if you get another one shortly 
> thereafter.  This was retained with Selective ACKs,
> > but doesn't seem to be in LTP.  Why?

I don't understand why it's needed.  Why doesn't the proposed system work?

> > Please include a finite state machine diagram for LTP engines.  I think 
> this
>would help immensely.

I agree.

> > In section 9 it appears that a non-understood segment has to be 
> silently discarded.  Would it
> > not be useful to provide for some sort of notification back to the 
> sender that it generated a
> > badly-formed protocol message?

Could, but it opens yet another potential DoS attack.

>   I had thought there was some requirement on lower layers to
> > do data integrity checks.  If so, then bad msgs would likely be 
> protocol implementation errors,
> > and would presumably be something you wish to know about.

It would likely be helpful; I'm a little worried about potential security 
and performance impacts.  Let's think about this some more.

> > 9.1:  seems this procedure would go away if the queues were managed 
> below LTP [which strikes
> >       me as a good idea; mentioned above]

The procedure wouldn't go away, but we would describe it differently.

> > Section 9.5 seems to indicate that timers must be count-down.  Similar 
> with 9.7.  Why?

Countdown as opposed to what?  These are interval timers; would that be 
better terminology?

> > How is number wrap-around handled?

Which numbers?  Most of the numbers are SDNVs, which makes wrap-around 
unlikely.

> > I found the existence of section 12.1 to be somewhat out of place.  Is 
> this a protocol or
> > a whole architecture?
> >
> > 12.2 -- couldn't an attacker generate fake ACK segments, thereby 
> causing a sender to discard
> > the data without it necessarily actually reaching the receiver?
> >
> > 12.4 seems largely redundant

Stephen, would you like to field these?

> > section 16: may want to reference the sigcomm 2003 paper in addition or 
> instead of the dtnrg.org web page

Good idea.

Thanks for the close reading, Kevin, you make a lot of very good points.

Scott 

Date: Mon, 17 May 2004 14:41:45 +0100
From: Stephen Farrell <[email-masked]>
To: Kevin Fall <[email-masked]>
Cc: [email-masked]
Subject: LTP security considerations (Was: Re: [dtn-interest] my comments on LTP)
Sender: [email-masked]

Just responding on sections 12.x here.

>I found the existence of section 12.1 to be somewhat out of place.  Is this a
>protocol or a whole architecture?

Its a protocol, not an architecture.

12.1 arose from a discussion about whether we should consider including
any crypto based mechanisms in LTP. I think its useful for now but
similar text may end up better off in a section describing context, i.e.
where we state the requirements LTP places on a lower layer and maybe
what higher layers really ought to be doing above LTP.

Parts of it may remain in section 12 if the idea of an authenticated
headers extension stays in (though that's really just a strawman at this
stage).

>12.2 -- couldn't an attacker generate fake ACK segments, thereby causing a 
 > sender to discard the data without it necessarily actually reaching
 > the receiver?

Ta. Will add that to the list.

>12.4 seems largely redundant

Perhaps. But given that a lot of overrun attacks are caused by
coding sloppiness of this sort, I really do think its worth
re-stating things like this. I could also argue that the use of
SHOULD is stronger than simply describing how SDNV is supposed
to handle lengths, but the main aim is to re-iterate things so
they get noticed during and after coding/testing.

The SNMP mess [1] from a couple of years ago was due to
mishandling simple ASN.1 decoding (scroll down the vendor list
in that advisory and then tell me this kind of thing's
redundant:-)

I'd expect this section to grow as code gets written.

Stephen.

[1] http://www.cert.org/advisories/CA-2002-03.html

Date: Fri, 14 May 2004 14:25:03 -0400
From: Keith Scott <[email-masked]>
Subject: Re: [dtn-interest] Fw: initialize_bundle_dbs - invalid argument
To: Josef Kriegl <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

I'll try to figure out how to enable fast mutexes.  The mutex debugging 
code does effectively patch mutex creation / destruction, so a cheesy 
thing to do if other mutex types are supported but fast ones aren't 
would be to get in there and change the mutex types.  In the meantime, 
I'll be grepping in .config...

       --keith

Josef Kriegl wrote:

>hi keith,
>
>as far as the linux distribution goes - its 2.6.5 from kernel.org.
>
>pthreads are supported. do you know of a way to enable/configure fast
>mutexes? i have read somewhere that 2.6.5 now supports user space (fast)
>mutexes. i can hunt through the kernel configuration (.config), and
>recompile the kernel, if that's of any value.
>
>as far as the
>
>initialize_bundle_dbs: page 0: illegal page type or format
>initialize_bundle_dbs: PANIC: Invalid argument
>
>goes, i ran db_dump on the bundle.db file with the following results:
>
>linux:~/NETPAK-VALIDATED/3party/dtn/Stage #
>/usr/local/BerkeleyDB.4.2-x86/bin/db_stat -d var/bundles/data/bundles.db
>53162   Btree magic number.
>9       Btree version number.
>Flags:  multiple-databases, little-endian
>2       Minimum keys per-page.
>4096    Underlying database page size.
>0       Number of levels in the tree.
>0       Number of unique keys in the tree.
>0       Number of data items in the tree.
>0       Number of tree internal pages.
>0       Number of bytes free in tree internal pages (0% ff).
>0       Number of tree leaf pages.
>0       Number of bytes free in tree leaf pages (0% ff).
>0       Number of tree duplicate pages.
>0       Number of bytes free in tree duplicate pages (0% ff).
>0       Number of tree overflow pages.
>0       Number of bytes free in tree overflow pages (0% ff).
>0       Number of pages on the free list.
>
>thanks,
>josef
>  
>

From: "Josef Kriegl" <[email-masked]>
To: <[email-masked]>
Date: Fri, 14 May 2004 19:46:35 +0200
Subject: [dtn-interest] arm validation - filesystem
Sender: [email-masked]

just out of curiosity - i was wondering what filesystem you guys used to
validate your arm version if DTN on. was it a flash file system (jffs2), or
ext2/3?

thanks,
josef

----- Original Message ----- 
From: "Robert C. Durst" <[email-masked]>
To: "'Josef Kriegl'" <[email-masked]>
Sent: Friday, May 14, 2004 1:15 PM
Subject: RE: [dtn-interest] initialize_bundle_dbs - invalid argument

> Eeek.  THAT doesn't look good.  I don't have any really good ideas here,
> because although I wrote the db code, I'm no berkeley db (or any other db)
> expert.  One thought is to try starting the bundle daemon with the -t
> option, which tells it to blow away any existing database files before
> initializing the databases.  You probably already did that, but it's a
> question.  Are you working on a weird processor architecture?  I see that
> you're from sensoria, and I believe that you folks do embedded
applications.
> Did you try any test programs to see if berkeley db was behaving on your
> platform?  If 4.0.14 was already there (say in a linux distrib), then I'd
> expect that 4.2.52 would work fine, but...  Sorry for rambling.  If I had
a
> *good* idea, I'd have spit it out in the first sentence.
>
> Let me know how it goes.  Thanks, and good luck,
> Bob Durst
>
>
>   _____
>
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Josef Kriegl
> Sent: Thursday, May 13, 2004 6:10 PM
> To: [email-masked]
> Subject: Re: [dtn-interest] initialize_bundle_dbs - invalid argument
>
>
>
> well, an upgrade to the berkeley db version 4.2.52 resulted in the
database
> file being created successfully, however, other types of error messages
now
> show (as far as i can tell these are errors from the db library):
>
> NP-201:/mnt/root/NETPAK-VALIDATED/3party/dtn/Stage# cat
/var/bundles/errors
> initialize_bundle_dbs: page 0: illegal page type or format
> initialize_bundle_dbs: PANIC: Invalid argument
> initialize_bundle_dbs: PANIC: fatal region error detected; run recovery
> initialize_bundle_dbs: PANIC: fatal region error detected; run recovery
> initialize_bundle_dbs: PANIC: fatal region error detected; run recovery
> initialize_bundle_dbs: PANIC: DB_RUNRECOVERY: Fatal error, run database
> recovery
> initialize_bundle_dbs: db->open: bundles: DB_RUNRECOVERY: Fatal error, run
> database recovery
> initialize_bundle_dbs: PANIC: fatal region error detected; run recovery
>
>
> josef
>
>
> ----- Original Message ----- 
> From: Robert C. Durst <mailto:[email-masked]>
> To: Josef Kriegl <mailto:[email-masked]>
> Sent: Thursday, May 13, 2004 5:59 PM
> Subject: Re: [dtn-interest] initialize_bundle_dbs - invalid argument
>
> Josef,
>
> Hi.  Am on travel right now, but off the top of my head, I'd suspect that
> the ./configure script thinks you're using a version of the database other
> than 4.0.14.  Our initial development used that version, and it is valid
> with the configure script (and the code should run), but I'd *strongly*
> recommend a newer version of the berkeley db code (www.sleepycat.com), and
> providing inputs to the configure script appropriately.
>
> Best regards,
> Bob Durst
> [email-masked]
>
> Josef Kriegl wrote:
>
>
> hi,
>
> i downloaded and cross-compiled the DTN code for a linux/hitachi platform
> from the cvs head. i ran into problems trying to open the database
> environment in the function
>
> bundleDB.c:initialize_bundle_dbs()
>
> specifically, the call to bundle_ev->open() in bundleDb.c:line 294 fails
> with
>
> ret = 22 [errno:2] (Invalid argument)
>
> i have to admit am not up to speed with the berkely db API, but was
> wondering why bundle_ev->open() is called with the bundle directory as an
> argument, when further down (bundleDb.c:334) bundle_ev->open() is called
in
> a loop on a file and a number of databases within that file (as i would
> expect if multiple databases were to be opened). i temporarily commented
out
> the section that opens the db environment (bundle_env->open() call on the
> bundle directory) to find that the call to open the individual databases
> (bundleDb.c:334) fails with the same error (Invalid argument).
>
> is this a known problem, or is possible this error has to do with my
> specific directory structure / configuration / db status? is it the
version
> of the berkely db i use (4.0.14)? or should i not be using code from the
> head at this point, but rather a tagged version?
>
> thanks for your help,
> josef
>
>
>
>

From: "Josef Kriegl" <[email-masked]>
To: <[email-masked]>
Subject: Fw: [dtn-interest] initialize_bundle_dbs - invalid argument
Date: Fri, 14 May 2004 18:32:53 +0200
Sender: [email-masked]

Bob, Keith,

FYI - i came across an interesting note in the berkeley db documentation,
which mentions that db files should never be created on an nfs file system,
especially on linux, because they supposedly do not correctly support
mapping files into process memory. this may explain the

initialize_bundle_dbs: page 0: illegal page type or format
initialize_bundle_dbs: PANIC: Invalid argument
initialize_bundle_dbs: PANIC: fatal region error detected; run recovery

errors, and the jffs2 and other fs we have on our platform may fall into the
same category.

btw, i successfully ran the dtn and berkeley db code on an x86 machine
today, at least as far as init/startup of the bundle daemon goes.

Josef

----- Original Message ----- 
From: "Josef Kriegl" <[email-masked]>
To: <[email-masked]>
Sent: Friday, May 14, 2004 5:26 PM
Subject: Re: [dtn-interest] initialize_bundle_dbs - invalid argument

> Hi Bob,
>
> i compiled DTN and the berkeley db 4.2.52 for x86 and it starts up fine,
as
> far as i can tell from the console messages (see log below). hence i am
> really surprised about the
>
> initialize_bundle_dbs: page 0: illegal page type or format
> initialize_bundle_dbs: PANIC: Invalid argument
> initialize_bundle_dbs: PANIC: fatal region error detected; run recovery
>
> errors, because i am running the bundleDaemon across NFS and the bundle.db
> file is also created on an ext2/3 filesystem on the same host the x86
> version just ran. in my opinion this rules out the local flash file system
> on the sh4/linux platform.
>
> any other ideas what might cause the db to bail out?
>
> Josef
>
>
> linux:/usr/local/DTN # ./sbin/bundleDaemon -t -c /etc/bundles/ -D1 -s
> /var/spool/bundles/
> setting debug level to 1
> bundleDaemon: setting bundle recv directory to: /var/spool/bundles/
> Bundle node read 1 interfaces:
> Mutex tracking is ON; doMutexChecking is 1
> Removing contents from bundle recv dir [/var/spool/bundles/]
> rm: cannot remove `brgs': Is a directory
> Removing contents from bundle DB dir [/var/bundles]
> Removing contents from BRG dir [/var/spool/bundles//brgs]
> Sanity check passed
> Memory tracking is ON; doMemoryChecking is 1
> db_update_bundle_id: updated bundle_id [1], committing change
> Bundle ID restore succeeded, bundle ID = 1
> linux bundle_daemon>      Bundle database contains 0 bundles.
> bundleAPIServer:  starting up...
>
> linux bundle_daemon>
>
> ----- Original Message ----- 
> From: "Robert C. Durst" <[email-masked]>
> To: "'Josef Kriegl'" <[email-masked]>
> Sent: Friday, May 14, 2004 1:15 PM
> Subject: RE: [dtn-interest] initialize_bundle_dbs - invalid argument
>
>
> > Eeek.  THAT doesn't look good.  I don't have any really good ideas here,
> > because although I wrote the db code, I'm no berkeley db (or any other
db)
> > expert.  One thought is to try starting the bundle daemon with the -t
> > option, which tells it to blow away any existing database files before
> > initializing the databases.  You probably already did that, but it's a
> > question.  Are you working on a weird processor architecture?  I see
that
> > you're from sensoria, and I believe that you folks do embedded
> applications.
> > Did you try any test programs to see if berkeley db was behaving on your
> > platform?  If 4.0.14 was already there (say in a linux distrib), then
I'd
> > expect that 4.2.52 would work fine, but...  Sorry for rambling.  If I
had
> a
> > *good* idea, I'd have spit it out in the first sentence.
> >
> > Let me know how it goes.  Thanks, and good luck,
> > Bob Durst
> >
> >
> >   _____
> >
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Josef Kriegl
> > Sent: Thursday, May 13, 2004 6:10 PM
> > To: [email-masked]
> > Subject: Re: [dtn-interest] initialize_bundle_dbs - invalid argument
> >
> >
> >
> > well, an upgrade to the berkeley db version 4.2.52 resulted in the
> database
> > file being created successfully, however, other types of error messages
> now
> > show (as far as i can tell these are errors from the db library):
> >
> > NP-201:/mnt/root/NETPAK-VALIDATED/3party/dtn/Stage# cat
> /var/bundles/errors
> > initialize_bundle_dbs: page 0: illegal page type or format
> > initialize_bundle_dbs: PANIC: Invalid argument
> > initialize_bundle_dbs: PANIC: fatal region error detected; run recovery
> > initialize_bundle_dbs: PANIC: fatal region error detected; run recovery
> > initialize_bundle_dbs: PANIC: fatal region error detected; run recovery
> > initialize_bundle_dbs: PANIC: DB_RUNRECOVERY: Fatal error, run database
> > recovery
> > initialize_bundle_dbs: db->open: bundles: DB_RUNRECOVERY: Fatal error,
run
> > database recovery
> > initialize_bundle_dbs: PANIC: fatal region error detected; run recovery
> >
> >
> > josef
> >
> >
> > ----- Original Message ----- 
> > From: Robert C. Durst <mailto:[email-masked]>
> > To: Josef Kriegl <mailto:[email-masked]>
> > Sent: Thursday, May 13, 2004 5:59 PM
> > Subject: Re: [dtn-interest] initialize_bundle_dbs - invalid argument
> >
> > Josef,
> >
> > Hi.  Am on travel right now, but off the top of my head, I'd suspect
that
> > the ./configure script thinks you're using a version of the database
other
> > than 4.0.14.  Our initial development used that version, and it is valid
> > with the configure script (and the code should run), but I'd *strongly*
> > recommend a newer version of the berkeley db code (www.sleepycat.com),
and
> > providing inputs to the configure script appropriately.
> >
> > Best regards,
> > Bob Durst
> > [email-masked]
> >
> > Josef Kriegl wrote:
> >
> >
> > hi,
> >
> > i downloaded and cross-compiled the DTN code for a linux/hitachi
platform
> > from the cvs head. i ran into problems trying to open the database
> > environment in the function
> >
> > bundleDB.c:initialize_bundle_dbs()
> >
> > specifically, the call to bundle_ev->open() in bundleDb.c:line 294 fails
> > with
> >
> > ret = 22 [errno:2] (Invalid argument)
> >
> > i have to admit am not up to speed with the berkely db API, but was
> > wondering why bundle_ev->open() is called with the bundle directory as
an
> > argument, when further down (bundleDb.c:334) bundle_ev->open() is called
> in
> > a loop on a file and a number of databases within that file (as i would
> > expect if multiple databases were to be opened). i temporarily commented
> out
> > the section that opens the db environment (bundle_env->open() call on
the
> > bundle directory) to find that the call to open the individual databases
> > (bundleDb.c:334) fails with the same error (Invalid argument).
> >
> > is this a known problem, or is possible this error has to do with my
> > specific directory structure / configuration / db status? is it the
> version
> > of the berkely db i use (4.0.14)? or should i not be using code from the
> > head at this point, but rather a tagged version?
> >
> > thanks for your help,
> > josef
> >
> >
> >
> >
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>
>

From: "Josef Kriegl" <[email-masked]>
To: <[email-masked]>
Subject: Re: [dtn-interest] Fw: initialize_bundle_dbs - invalid argument
Date: Fri, 14 May 2004 17:49:23 +0200
Sender: [email-masked]

hi keith,

as far as the linux distribution goes - its 2.6.5 from kernel.org.

pthreads are supported. do you know of a way to enable/configure fast
mutexes? i have read somewhere that 2.6.5 now supports user space (fast)
mutexes. i can hunt through the kernel configuration (.config), and
recompile the kernel, if that's of any value.

as far as the

initialize_bundle_dbs: page 0: illegal page type or format
initialize_bundle_dbs: PANIC: Invalid argument

goes, i ran db_dump on the bundle.db file with the following results:

linux:~/NETPAK-VALIDATED/3party/dtn/Stage #
/usr/local/BerkeleyDB.4.2-x86/bin/db_stat -d var/bundles/data/bundles.db
53162   Btree magic number.
9       Btree version number.
Flags:  multiple-databases, little-endian
2       Minimum keys per-page.
4096    Underlying database page size.
0       Number of levels in the tree.
0       Number of unique keys in the tree.
0       Number of data items in the tree.
0       Number of tree internal pages.
0       Number of bytes free in tree internal pages (0% ff).
0       Number of tree leaf pages.
0       Number of bytes free in tree leaf pages (0% ff).
0       Number of tree duplicate pages.
0       Number of bytes free in tree duplicate pages (0% ff).
0       Number of tree overflow pages.
0       Number of bytes free in tree overflow pages (0% ff).
0       Number of pages on the free list.

thanks,
josef

----- Original Message ----- 
From: "Keith Scott" <[email-masked]>
To: "Josef Kriegl" <[email-masked]>
Cc: "Durst,Robert C." <[email-masked]>; <[email-masked]>
Sent: Friday, May 14, 2004 12:53 AM
Subject: Re: [dtn-interest] Fw: initialize_bundle_dbs - invalid argument

> Yes, sorry.  Slight brain malfunction referencing similar problem with
> filesystem that didn't support link creation (vfat).  That was fixable.
>
> In any case, no fast mutexes, eh?  What linux distribution do you have?
> Do you know if mutexes of any kind are supported?  Without some sort of
> mutexes the reference implementation will have difficulty running
> correctly, as it is multi-threaded.  BTW, I don't think this is related
> to the 'new' errors you're getting from the berkeleyDB code, but if we
> can clear that up it's going to the next thing you find.  It would
> probably take a significant effort to rework the DTN code to be
> single-threaded...
>
> I'm not the expert on the database interface, but there is a
> compile-time variable set in the configure script that sets the version
> of BerkeleyDB the code is expecting; make sure that's set right.
> (Suspect it's not your problem, but it should be set right anyway -- try
> './configure --help' at the top level of the code).
>
> If you can tell me the linux distribution we can try to figure out if
> there's some way to add support for mutexes (and I begin to fear that if
> there's no mutex support, it might also lack pthread support, which
> would be an even larger issue).
>
>        --keith
>
> Josef Kriegl wrote:
>
> >Hi Keith,
> >
> >thanks for the response. are you saying that on our platform, which does
not
> >seem to support fast mutexes i might not be able to succeed with running
> >DTN?
> >
> >Josef
> >
> >----- Original Message ----- 
> >From: "Keith Scott" <[email-masked]>
> >To: "Josef Kriegl" <[email-masked]>
> >Sent: Thursday, May 13, 2004 6:45 PM
> >Subject: Re: [dtn-interest] Fw: initialize_bundle_dbs - invalid argument
> >
> >
> >
> >
> >>What file system?  There are other dependancies on fast mutexes outside
> >>the database code that will need a lot of work to get around...
> >>
> >>       --keith
> >>
> >>Josef Kriegl wrote:
> >>
> >>
> >>
> >>>to follows up on my previous problem report - i noticed the message
> >>>'fast mutexes not supported on this platform' in
> >>>/var/bundles/errors). i then disabled DB_THREAD flag, following the
> >>>advice in the berkeley db documenation:
> >>>
> >>>http://www.sleepycat.com/docs/api_c/db_open.html
> >>>
> >>>initialize_bundle_dbs still fails, though, with a new set of error
> >>>messages (in /var/bundles/errors) as follows:
> >>>
> >>>initialize_bundle_dbs: bundles.db: unexpected file type or format
> >>>initialize_bundle_dbs: db->open: bundles: Invalid argument
> >>>initialize_bundle_dbs: Database handles open during environment close
> >>>
> >>>josef
> >>>
> >>>----- Original Message -----
> >>>*From:* Josef Kriegl <mailto:[email-masked]>
> >>>*To:* [email-masked]
> >>><mailto:[email-masked]>
> >>>*Sent:* Thursday, May 13, 2004 10:28 AM
> >>>*Subject:* initialize_bundle_dbs - invalid argument
> >>>
> >>>hi,
> >>>
> >>>i downloaded and cross-compiled the DTN code for a linux/hitachi
> >>>platform from the cvs head. i ran into problems trying to open the
> >>>database environment in the function
> >>>
> >>>bundleDB.c:initialize_bundle_dbs()
> >>>
> >>>specifically, the call to bundle_ev->open() in bundleDb.c:line 294
> >>>fails with
> >>>
> >>>ret = 22 [errno:2] (Invalid argument)
> >>>
> >>>i have to admit am not up to speed with the berkely db API, but was
> >>>wondering why bundle_ev->open() is called with the bundle directory as
> >>>an argument, when further down (bundleDb.c:334) bundle_ev->open() is
> >>>called in a loop on a file and a number of databases within that file
> >>>(as i would expect if multiple databases were to be opened). i
> >>>temporarily commented out the section that opens the db environment
> >>>(bundle_env->open() call on the bundle directory) to find that the
> >>>call to open the individual databases (bundleDb.c:334) fails with the
> >>>same error (Invalid argument).
> >>>
> >>>is this a known problem, or is possible this error has to do with my
> >>>specific directory structure / configuration / db status? is it the
> >>>version of the berkely db i use (4.0.14)? or should i not be using
> >>>code from the head at this point, but rather a tagged version?
> >>>
> >>>thanks for your help,
> >>>josef
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> yw
>
>

To: [email-masked]
Date: Fri, 14 May 2004 08:44:56 -0700
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] my comments on LTP
Sender: [email-masked]

> 
> General comments:
> 
> interesting reading...thanks for putting this together.
> 
> it says its a convergence layer protocol.  But really, is it a transport laye
r, right?
> 
> LTP: the name isn't exactly useful to indicate its capability.  I guess this 
is really your
>    decision, but the dedication seems somewhat less useful than a functional 
description
> 	(e.g. really long delay transport protocol - RLDTP).  Also, see note be
low
> 	about reliability vs non-reliability and the idea of layering into 2 pr
otocols.
> 
> It appears this protocol lacks both flow and congestion control.  Perhaps und
erstandable
> for this environment, but some explicit statement as to how these issues are 
dealt with would
> be helpful.  I believe, based on my reading, that congestion doesn't happen b
ecause
> of admission control by way of the lower-layer queues.  Flow control doesn't 
appear to
> be discussed.  I gather that if the sender sends too much stuff for the recei
ver to consume,
> any excess just gets dropped on the floor.  Is this right?
> 
> Are blocks of arbitrary size?  If they are sort of known ahead of time, would
 it
> not be better to state the block size up front, and not have to worry about a
n
> explicit EOB?  Also, it appears that the capability to buffer at least one bl
ock
> (more?) is a requirement on the underlying network.  On a related note, the i
dea that
> LTP maintains the queues seems un-necessary.  All that is really appears to w
ant to do
> is specify the relative priority of its segments.
> 
> More detailed comments:
> 
> possible typo in abstract:
> 		"in the interplanetary space" -> "in interplanetary space"
> 
> Also, this protocol isn't just for long RTT's, but for RTT's that you can pre
tty
> reliably predict... right?
> 
> The idea of "as to simulate half duplex operation" seems sort of strange to m
e.
> For example, Ethernet (at least old Ethernet) is half-duplex, but that does n
ot
> mean it was large rtt.
> 
> Section 2.1 - include a Reference[] for DSN
> 
> There is mention of 'Radio contact via the DSN'.  Is it
> too early to mention optical contact via the dsn?
> 
> Why do you choose a reference from Mathis for the TCP
> equation?  I believe the more 'modern' reference is:
> 
> 	Padhye, Firoiu, Towsley, Kurose, "Modeling TCP Throughput: A Simple Mod
el and its
> 		Empirical Validation" Proc. SIGCOMM 1998
> 
> There is a typo where it says (this figure was reported by
> Paxson.... no closing parenthesis
> 
> The phrase "link state queues" is used relatively early (section 3).  At this
 point
> in the doc we aren't really sure what those are.  Maybe a forward reference t
o (e.g. sect 11)
> would be useful.
> 
> The phrase 'like any reliable transport service, LTP is "stateful"'
> might be better stated as something such as
> 'like any reliable transport service employing ARQ, LTP is "stateful"
> 
> Section 3.1:
> It is trivial and well-understood that stop-and-wait works badly
> when the RTT gets larger (ie. throughput scales as 1/RTT).  TCP
> and other window based approaches improve this by adding a window,
> so at least you get throughput in proportion to (W/RTT).  Related,
> I don't see why this is called "massive".  It may not really be
> so massive...  Actually, the entirety of section 3.1 doesn't really
> seem that useful to me.
> 
> Section 3.1.1:
> It is wrong to say "But while TCP permits only a single connection
> on a given port at any time...".  A TCP "connection" is defined
> as a 4-tuple (not a 2-tuple) of [ip/port, ip/port].  Thus it is
> possible to re-use port numbers at one endpoint, provided they are
> not re-used at the other as well.  Please fix.   This affects
> your "table" as well, and is not a trivial mistake.  Indeed, this port
> re-use is foundational to TCP.  It is the thing that allows one server
> program to service multiple clients simultaneously.  As a related issue,
> I don't understand how LTP handles this.
> 
> What does "one at at time" mean for blocks transmitted for a TCP
> connection? (page 10)
> 
> With reference to out-of-order, you probably want to reference SCTP.
> More generally, please compare LTP with SCTP; not only TCP.
> Please include a discussion of why SCTP is insufficient for your needs.
> 
> Section 3.2 it talks about negotiation.  For most things there
> is no negotiation whatsoever in TCP.  Ther is -specification-
> (in particular limits that a receiver tells to the sender).  What
> particular parameters were you referring to when you talk about
> negotiation or re-negotiation?  I think maybe the word
> 'negotiation' is misplaced here.  You can safely say that flow control
> is accomplished by exchange of data, but that is about it.
> 
> Page 12/Sec 5.4: retransmissions are only induced by arrival of a response.
> 	Cannot timers for checkpointed segments also induce retransmissions?  I
f not, I believe
> 	you can easily deadlock, or did I miss something?
> 
> I am concerned about the in-order assumption of 3.4.  In a world
> with Mars orbiters and other relays, why is it not possible that
> re-ordering might happen?  Do you envision this as a transport
> protocol, or something radically different?  In any case, re-ordering
> doesn't seem like it should be a big problem, especially given that
> you are already supporting selective repeat semantics for retransmission
> (ie. you already are willing to maintain a buffer).  I am also not really
> convinced by the "argument" that the concept of rough determinism is
> violated.  If you are willing to tolerate a couple of extra seconds
> (related to your setting of the N value), then if you go through a relay that
> takes you a few extra milliseconds, you should be ok.
> 
> I do not understand this paragraph:
> 
>       o The massively parallel nature of LTP changes the granularity at
>         which timer accuracy is required.  Confirmation of the reception
>         of one block, or one segment, does not retard transmission of
>         the next, so timeout values that would be intolerably optimistic
>         in TCP don't constrain LTP's bandwidth utilization.
> 
> Why is this true:
> 
> 	The round-trip time for transmitted segment N could easily be
> 	orders of magnitude greater than that for segment N-1
> 
> 
> Section 3.6:
> 
> 	"Link state queues also notify LTP ..."
> 
> 	"also" in addition to what?
> 
> Section 4:
> 	how are engine IDs assigned?
> 
> 	I think (6) [Scope] makes references to some things that are not yet de
fined.
> 	e.g. "segment's client service data".  What unit are upper and lower bo
unds
> 	measured in?  What happens when/if they wrap?  The lack of units is als
o
> 	a problem for other definitions [e.g. checkpoint]
> 
> Section 5: what is a 'client service instance'?
> 
> Section 5.1:
> 	TCP has a state machine where the states are well-defined and named.  W
hy don't
> 	you have something similar.  (also, see similar comment below)
> 
> 	Is the maximum segment size dictated only by the underlying network?  I
n TCP
> 		it is dictated by the receiver and -not- by the underlying netw
ork.
> 
> Section 5.2:
> Can  you make a statement as to the number of timers that need be maintained 
at the
> sender/receiver?  (related issue: with TCP, there is -not- a timer per segmen
t).  It seems that
> one is envisioned for every block, and perhaps every report segment.  Why are
 so
> many required?
> 
> If only the SSR or RSR is closed, does the session ever terminate?  See other
 comment
> about general need to discuss how closing vs cancellation works.  (also, if y
ou
> used close versus reset terminology, it would help to leverage TCP terminolog
y).
> 
> Section 5.6:
> The idea that the same protocol has both a reliable and non-reliable mode see
ms
> a bit troubling.  Why not define a non-reliable protocol and then
> define the reliable protocol on top of it by way of backward reference?  Can 
two
> LTP speakers reasonably expect to communicate?  (i.e. if one implements the r
eliability
> and one doesn't?)
> 
> Also (5.6) it says "but LTP's block segmentation, bandwidth management, ..."
> 	What exactly -is- LTP's bandwidth management?  In particular, in sectio
n 6.2
> 	where it talks about bw management it talks about scheduling.  But this
> 	is not really bandwidth management.  Rather, it is a que servicing disc
ipline.
> 
> Page 27: does the handling of the queues and their priority really belong in 
this discussion
> of the transport?  Wouldn't it be possible to use LTP without this exact queu
e
> configuration?
> 
> there seems to be the terminology 'reception claims'.  Is this new?
> 
> Section 5.2 discusses a non-zero serial number.  What happens with a zero ser
ial number?
> 
> Section 5.2.2 appears to address both the retransmission partitioning
> of responsibility as well as the final close issue (the thing that TCP uses t
he
> MSL wait for).  As for the first argument, wouldn't it be the case
> that a cumulative style ack very easily handles this problem?
> As for the second part, what is the problem with the TCP-style FIN exchange?
> You already have all the mechanism to handle that, so it seems to me.  Perhap
s I'm
> failing to appreciate the difference between the proposed design and the TCP 
like
> way of doing it.  I think this brings up the point that the whole document ap
pears
> to lack an explicit discussion of what happens during connection close.  In p
articular,
> any distinction between cancellation and closing, as well as what happens whe
n various
> segments are lost during this phase.  It is instructive to look at the TCP st
ate
> machine, as almost all the states are related to phases of either connection 
establishment
> or normal connection close.
> 
> Section 6.3-  the penalty of under-utilization is not mentioned, yet back in 
3.2
> 	there is mention of "costly under-utilization of link resources"
> 
> 	Radiation time-  this would ordinarily be called transmission delay (I 
think).  Is there
> 	a special reason to use this new terminology?
> 
> I think it would be useful to include a list of requirements LTP places on th
e underlying
> link system.  Currently, this appears to be spread across the document and is
 also sort of
> aggregated in section 11.  Perhaps moving section 11 earlier and expanding it
 would suffice.
> 
> Section 7:
> 
> how about some ascii art, like other rfcs?
> 
> 7.1.1
> 	This sounds funny: "... that the segment
> 	carries data and is a data segment, while a value of 1 indicates"
> 
> 7.2.1
> 	checkpoint serial number has to increase, evidently without resetting..
. ever.
> 	Is that really right?  Does persistent info need to be stored in order 
to
> 	be compliant?  Is there serial # wrap?
> 
> 	Client service ID:  why do you require the app to perform the demultipl
exing?
> 	The seems unfortunate.  It also relates to the discussion of ports [abo
ve].
> 
> 
> In TCP the cumulative ACK idea is useful in that it enhances ACK robustness..
. you can
> stand to lose one or more if you get another one shortly thereafter.  This wa
s retained with Selective ACKs,
> but doesn't seem to be in LTP.  Why?
> 
> Please include a finite state machine diagram for LTP engines.  I think this 
would help immensely.
> 
> In section 9 it appears that a non-understood segment has to be silently disc
arded.  Would it
> not be useful to provide for some sort of notification back to the sender tha
t it generated a
> badly-formed protocol message?  I had thought there was some requirement on l
ower layers to
> do data integrity checks.  If so, then bad msgs would likely be protocol impl
ementation errors,
> and would presumably be something you wish to know about.
> 
> 9.1:  seems this procedure would go away if the queues were managed below LTP
 [which strikes
> 	me as a good idea; mentioned above]
> 
> Section 9.5 seems to indicate that timers must be count-down.  Similar with 9
.7.  Why?
> 
> How is number wrap-around handled?
> 
> I found the existence of section 12.1 to be somewhat out of place.  Is this a
 protocol or
> a whole architecture?
> 
> 12.2 -- couldn't an attacker generate fake ACK segments, thereby causing a se
nder to discard
> the data without it necessarily actually reaching the receiver?
> 
> 12.4 seems largely redundant
> 
> section 16: may want to reference the sigcomm 2003 paper in addition or inste
ad of the dtnrg.org web page
> (?)
> 

From: "Josef Kriegl" <[email-masked]>
To: <[email-masked]>
Subject: Re: [dtn-interest] initialize_bundle_dbs - invalid argument
Date: Fri, 14 May 2004 17:26:49 +0200
Sender: [email-masked]

Hi Bob,

i compiled DTN and the berkeley db 4.2.52 for x86 and it starts up fine, as
far as i can tell from the console messages (see log below). hence i am
really surprised about the

initialize_bundle_dbs: page 0: illegal page type or format
initialize_bundle_dbs: PANIC: Invalid argument
initialize_bundle_dbs: PANIC: fatal region error detected; run recovery

errors, because i am running the bundleDaemon across NFS and the bundle.db
file is also created on an ext2/3 filesystem on the same host the x86
version just ran. in my opinion this rules out the local flash file system
on the sh4/linux platform.

any other ideas what might cause the db to bail out?

Josef

linux:/usr/local/DTN # ./sbin/bundleDaemon -t -c /etc/bundles/ -D1 -s
/var/spool/bundles/
setting debug level to 1
bundleDaemon: setting bundle recv directory to: /var/spool/bundles/
Bundle node read 1 interfaces:
Mutex tracking is ON; doMutexChecking is 1
Removing contents from bundle recv dir [/var/spool/bundles/]
rm: cannot remove `brgs': Is a directory
Removing contents from bundle DB dir [/var/bundles]
Removing contents from BRG dir [/var/spool/bundles//brgs]
Sanity check passed
Memory tracking is ON; doMemoryChecking is 1
db_update_bundle_id: updated bundle_id [1], committing change
Bundle ID restore succeeded, bundle ID = 1
linux bundle_daemon>      Bundle database contains 0 bundles.
bundleAPIServer:  starting up...

linux bundle_daemon>

----- Original Message ----- 
From: "Robert C. Durst" <[email-masked]>
To: "'Josef Kriegl'" <[email-masked]>
Sent: Friday, May 14, 2004 1:15 PM
Subject: RE: [dtn-interest] initialize_bundle_dbs - invalid argument

> Eeek.  THAT doesn't look good.  I don't have any really good ideas here,
> because although I wrote the db code, I'm no berkeley db (or any other db)
> expert.  One thought is to try starting the bundle daemon with the -t
> option, which tells it to blow away any existing database files before
> initializing the databases.  You probably already did that, but it's a
> question.  Are you working on a weird processor architecture?  I see that
> you're from sensoria, and I believe that you folks do embedded
applications.
> Did you try any test programs to see if berkeley db was behaving on your
> platform?  If 4.0.14 was already there (say in a linux distrib), then I'd
> expect that 4.2.52 would work fine, but...  Sorry for rambling.  If I had
a
> *good* idea, I'd have spit it out in the first sentence.
>
> Let me know how it goes.  Thanks, and good luck,
> Bob Durst
>
>
>   _____
>
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Josef Kriegl
> Sent: Thursday, May 13, 2004 6:10 PM
> To: [email-masked]
> Subject: Re: [dtn-interest] initialize_bundle_dbs - invalid argument
>
>
>
> well, an upgrade to the berkeley db version 4.2.52 resulted in the
database
> file being created successfully, however, other types of error messages
now
> show (as far as i can tell these are errors from the db library):
>
> NP-201:/mnt/root/NETPAK-VALIDATED/3party/dtn/Stage# cat
/var/bundles/errors
> initialize_bundle_dbs: page 0: illegal page type or format
> initialize_bundle_dbs: PANIC: Invalid argument
> initialize_bundle_dbs: PANIC: fatal region error detected; run recovery
> initialize_bundle_dbs: PANIC: fatal region error detected; run recovery
> initialize_bundle_dbs: PANIC: fatal region error detected; run recovery
> initialize_bundle_dbs: PANIC: DB_RUNRECOVERY: Fatal error, run database
> recovery
> initialize_bundle_dbs: db->open: bundles: DB_RUNRECOVERY: Fatal error, run
> database recovery
> initialize_bundle_dbs: PANIC: fatal region error detected; run recovery
>
>
> josef
>
>
> ----- Original Message ----- 
> From: Robert C. Durst <mailto:[email-masked]>
> To: Josef Kriegl <mailto:[email-masked]>
> Sent: Thursday, May 13, 2004 5:59 PM
> Subject: Re: [dtn-interest] initialize_bundle_dbs - invalid argument
>
> Josef,
>
> Hi.  Am on travel right now, but off the top of my head, I'd suspect that
> the ./configure script thinks you're using a version of the database other
> than 4.0.14.  Our initial development used that version, and it is valid
> with the configure script (and the code should run), but I'd *strongly*
> recommend a newer version of the berkeley db code (www.sleepycat.com), and
> providing inputs to the configure script appropriately.
>
> Best regards,
> Bob Durst
> [email-masked]
>
> Josef Kriegl wrote:
>
>
> hi,
>
> i downloaded and cross-compiled the DTN code for a linux/hitachi platform
> from the cvs head. i ran into problems trying to open the database
> environment in the function
>
> bundleDB.c:initialize_bundle_dbs()
>
> specifically, the call to bundle_ev->open() in bundleDb.c:line 294 fails
> with
>
> ret = 22 [errno:2] (Invalid argument)
>
> i have to admit am not up to speed with the berkely db API, but was
> wondering why bundle_ev->open() is called with the bundle directory as an
> argument, when further down (bundleDb.c:334) bundle_ev->open() is called
in
> a loop on a file and a number of databases within that file (as i would
> expect if multiple databases were to be opened). i temporarily commented
out
> the section that opens the db environment (bundle_env->open() call on the
> bundle directory) to find that the call to open the individual databases
> (bundleDb.c:334) fails with the same error (Invalid argument).
>
> is this a known problem, or is possible this error has to do with my
> specific directory structure / configuration / db status? is it the
version
> of the berkely db i use (4.0.14)? or should i not be using code from the
> head at this point, but rather a tagged version?
>
> thanks for your help,
> josef
>
>
>
>

From: "Josef Kriegl" <[email-masked]>
To: <[email-masked]>
Subject: Re: [dtn-interest] initialize_bundle_dbs - invalid argument
Date: Fri, 14 May 2004 15:26:53 +0200
Sender: [email-masked]

i have been using the -t option in the past..

the platform is hitachi sh4/linux (custom board), but i have tried arm/linux
before with even less luck (stargate platform, in this case dtn crashed
before the db-related code, see below).

i am going to compile dtn (i am using the head revision) and berkeley db
4.2.52 for x86 to be able to rule out any configuration/setup problems.

btw, in the code snipped below from bundleDb.c:initialize_bundle_dbs(),

bundle_env->close(bundle_env, 0);

will cause a segv, probably because close_bundle_dbs(); already closed the
environment. i worked around this by commenting out (void)
bundle_env->close(bundle_env, 0);

josef

  ...
  db_err:close_bundle_dbs();
    (void) bundle_env->close(bundle_env, 0);
    exit(ret);
  ...

on arm/linux:

BundleDaemon: nameList()
BundleDaemon: initPointerList()
BundleDaemon: removeDynamicFiles()
Removing contents from bundle recv dir [/var/spool/bundles/]
rm: brgs: is a directory
.. exec cmd >(cd /var/spool/bundles/ && rm -f *)<
Removing contents from bundle DB dir [/var/bundles]
.. exec cmd >(cd /var/bundles && rm -f log/*)<
Removing contents from BRG dir [/var/spool/bundles//brgs]
.. exec cmd >(cd /var/spool/bundles//brgs && rm -f *)<
BundleDaemon: SanityCheck()
Sanity check passed
BundleDaemon: convergenceLayers()
Memory tracking is ON; doMemoryChecking is 1

>>>>Starting thread TCP Convergence Layer (id:16386)
Killed
----- Original Message ----- 
From: "Robert C. Durst" <[email-masked]>
To: "'Josef Kriegl'" <[email-masked]>
Sent: Friday, May 14, 2004 1:15 PM
Subject: RE: [dtn-interest] initialize_bundle_dbs - invalid argument

> Eeek.  THAT doesn't look good.  I don't have any really good ideas here,
> because although I wrote the db code, I'm no berkeley db (or any other db)
> expert.  One thought is to try starting the bundle daemon with the -t
> option, which tells it to blow away any existing database files before
> initializing the databases.  You probably already did that, but it's a
> question.  Are you working on a weird processor architecture?  I see that
> you're from sensoria, and I believe that you folks do embedded
applications.
> Did you try any test programs to see if berkeley db was behaving on your
> platform?  If 4.0.14 was already there (say in a linux distrib), then I'd
> expect that 4.2.52 would work fine, but...  Sorry for rambling.  If I had
a
> *good* idea, I'd have spit it out in the first sentence.
>
> Let me know how it goes.  Thanks, and good luck,
> Bob Durst
>
>
>   _____
>
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Josef Kriegl
> Sent: Thursday, May 13, 2004 6:10 PM
> To: [email-masked]
> Subject: Re: [dtn-interest] initialize_bundle_dbs - invalid argument
>
>
>
> well, an upgrade to the berkeley db version 4.2.52 resulted in the
database
> file being created successfully, however, other types of error messages
now
> show (as far as i can tell these are errors from the db library):
>
> NP-201:/mnt/root/NETPAK-VALIDATED/3party/dtn/Stage# cat
/var/bundles/errors
> initialize_bundle_dbs: page 0: illegal page type or format
> initialize_bundle_dbs: PANIC: Invalid argument
> initialize_bundle_dbs: PANIC: fatal region error detected; run recovery
> initialize_bundle_dbs: PANIC: fatal region error detected; run recovery
> initialize_bundle_dbs: PANIC: fatal region error detected; run recovery
> initialize_bundle_dbs: PANIC: DB_RUNRECOVERY: Fatal error, run database
> recovery
> initialize_bundle_dbs: db->open: bundles: DB_RUNRECOVERY: Fatal error, run
> database recovery
> initialize_bundle_dbs: PANIC: fatal region error detected; run recovery
>
>
> josef
>
>
> ----- Original Message ----- 
> From: Robert C. Durst <mailto:[email-masked]>
> To: Josef Kriegl <mailto:[email-masked]>
> Sent: Thursday, May 13, 2004 5:59 PM
> Subject: Re: [dtn-interest] initialize_bundle_dbs - invalid argument
>
> Josef,
>
> Hi.  Am on travel right now, but off the top of my head, I'd suspect that
> the ./configure script thinks you're using a version of the database other
> than 4.0.14.  Our initial development used that version, and it is valid
> with the configure script (and the code should run), but I'd *strongly*
> recommend a newer version of the berkeley db code (www.sleepycat.com), and
> providing inputs to the configure script appropriately.
>
> Best regards,
> Bob Durst
> [email-masked]
>
> Josef Kriegl wrote:
>
>
> hi,
>
> i downloaded and cross-compiled the DTN code for a linux/hitachi platform
> from the cvs head. i ran into problems trying to open the database
> environment in the function
>
> bundleDB.c:initialize_bundle_dbs()
>
> specifically, the call to bundle_ev->open() in bundleDb.c:line 294 fails
> with
>
> ret = 22 [errno:2] (Invalid argument)
>
> i have to admit am not up to speed with the berkely db API, but was
> wondering why bundle_ev->open() is called with the bundle directory as an
> argument, when further down (bundleDb.c:334) bundle_ev->open() is called
in
> a loop on a file and a number of databases within that file (as i would
> expect if multiple databases were to be opened). i temporarily commented
out
> the section that opens the db environment (bundle_env->open() call on the
> bundle directory) to find that the call to open the individual databases
> (bundleDb.c:334) fails with the same error (Invalid argument).
>
> is this a known problem, or is possible this error has to do with my
> specific directory structure / configuration / db status? is it the
version
> of the berkely db i use (4.0.14)? or should i not be using code from the
> head at this point, but rather a tagged version?
>
> thanks for your help,
> josef
>
>
>
>

From: "Robert C. Durst" <[email-masked]>
To: <[email-masked]>
Date: Fri, 14 May 2004 07:14:54 -0400
Organization: The MITRE Corporation
Subject: [dtn-interest] FW: I-D ACTION:draft-irtf-dtnrg-ltp-00.txt
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C43983.27F393B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

FYI. 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of 
>[email-masked]
>Sent: Thursday, May 13, 2004 12:59 PM
>To: [email-masked]
>Subject: I-D ACTION:draft-irtf-dtnrg-ltp-00.txt
>
>A New Internet-Draft is available from the on-line 
>Internet-Drafts directories.
>
>
>	Title		: Licklider Transmission Protocol
>	Author(s)	: S. Burleigh, et al.
>	Filename	: draft-irtf-dtnrg-ltp-00.txt
>	Pages		: 58
>	Date		: 2004-5-12
>	
>This document describes the Licklider Transmission Protocol (LTP)
>   designed to provide retransmission-based reliability over links
>   characterized by extremely long message round-trip times (RTTs).
>   These long round-trip times may result from the use of half-duplex
>   channels or from data propagation delays that are so lengthy as to
>   simulate half-duplex transmission.  Such environments are not well
>   served by TCP, which depends on relatively short round-trip 
>times for
>   retransmission buffer management, timely flow control, and
>   negotiation of other connection parameters.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-ltp-00.txt
>
>To remove yourself from the I-D Announcement list, send a message to 
>[email-masked] with the word unsubscribe in the 
>body of the message.  
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
>to change your subscription settings.
>
>
>Internet-Drafts are also available by anonymous FTP. Login 
>with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>	"get draft-irtf-dtnrg-ltp-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html 
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	[email-masked].
>In the body type:
>	"FILE /internet-drafts/draft-irtf-dtnrg-ltp-00.txt".
>	
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant 
>mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>		
>		
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>

------=_NextPart_000_0000_01C43983.27F393B0
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="winmail.dat"

------=_NextPart_000_0000_01C43983.27F393B0--

Date: Fri, 14 May 2004 06:50:07 -0400
From: Keith Scott <[email-masked]>
Subject: Re: [dtn-interest] initialize_bundle_dbs - invalid argument
To: Josef Kriegl <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

You might try blowing off the database files in /var/bundles and/or 
using the '-t' option to the bundleDaemon (which should blow the files 
away at startup) just in case something's corrupted.  However, if 
mutexes aren't supported there's another wall waiting.

       --keith

Josef Kriegl wrote:

>  
> well, an upgrade to the berkeley db version 4.2.52 resulted in the 
> database file being created successfully, however, other types of 
> error messages now show (as far as i can tell these are errors from 
> the db library):
>  
> NP-201:/mnt/root/NETPAK-VALIDATED/3party/dtn/Stage# cat 
> /var/bundles/errors
> initialize_bundle_dbs: page 0: illegal page type or format
> initialize_bundle_dbs: PANIC: Invalid argument
> initialize_bundle_dbs: PANIC: fatal region error detected; run recovery
> initialize_bundle_dbs: PANIC: fatal region error detected; run recovery
> initialize_bundle_dbs: PANIC: fatal region error detected; run recovery
> initialize_bundle_dbs: PANIC: DB_RUNRECOVERY: Fatal error, run 
> database recovery
> initialize_bundle_dbs: db->open: bundles: DB_RUNRECOVERY: Fatal error, 
> run database recovery
> initialize_bundle_dbs: PANIC: fatal region error detected; run recovery
>  
>  
> josef
>  
>
>     ----- Original Message -----
>     *From:* Robert C. Durst <mailto:[email-masked]>
>     *To:* Josef Kriegl <mailto:[email-masked]>
>     *Sent:* Thursday, May 13, 2004 5:59 PM
>     *Subject:* Re: [dtn-interest] initialize_bundle_dbs - invalid argument
>
>     Josef,
>
>     Hi.  Am on travel right now, but off the top of my head, I'd
>     suspect that the ./configure script thinks you're using a version
>     of the database other than 4.0.14.  Our initial development used
>     that version, and it is valid with the configure script (and the
>     code should run), but I'd *strongly* recommend a newer version of
>     the berkeley db code (www.sleepycat.com), and providing inputs to
>     the configure script appropriately.
>
>     Best regards,
>     Bob Durst
>     [email-masked]
>
>     Josef Kriegl wrote:
>
>>     hi,
>>      
>>     i downloaded and cross-compiled the DTN code for a linux/hitachi
>>     platform from the cvs head. i ran into problems trying to open
>>     the database environment in the function
>>      
>>     bundleDB.c:initialize_bundle_dbs()
>>      
>>     specifically, the call to bundle_ev->open() in bundleDb.c:line
>>     294 fails with
>>      
>>     ret = 22 [errno:2] (Invalid argument)
>>      
>>     i have to admit am not up to speed with the berkely db API, but
>>     was wondering why bundle_ev->open() is called with the bundle
>>     directory as an argument, when further down (bundleDb.c:334)
>>     bundle_ev->open() is called in a loop on a file and a number of
>>     databases within that file (as i would expect if multiple
>>     databases were to be opened). i temporarily commented out the
>>     section that opens the db environment (bundle_env->open() call on
>>     the bundle directory) to find that the call to open the
>>     individual databases (bundleDb.c:334) fails with the same error
>>     (Invalid argument).
>>      
>>     is this a known problem, or is possible this error has to do with
>>     my specific directory structure / configuration / db status? is
>>     it the version of the berkely db i use (4.0.14)? or should i not
>>     be using code from the head at this point, but rather a tagged
>>     version?
>>      
>>     thanks for your help,
>>     josef
>>      
>
>

Date: Thu, 13 May 2004 17:29:20 -0700
From: Melissa Ho <[email-masked]>
Reply-To: [email-masked]
To: Josef Kriegl <[email-masked]>
Subject: Re: [dtn-interest] Fw: initialize_bundle_dbs - invalid argument
Cc: [email-masked]
Sender: [email-masked]

I'm not sure if this will be entirely helpful but here goes.

I'm using 4.0.14 as well, without problems. You might check that the
database directory (by default /Bundles) actually exists. I have
always needed to create it by hand, although I believe make install
should create the /Bundles directory for you.

> i have to admit am not up to speed with the 
> berkely db API, but was wondering why bundle_ev->open() is called with the 
> bundle directory as an argument, when further down (bundleDb.c:334) 
> bundle_ev->open() is called in a loop on a file and a number of 
> databases within that file (as i would expect if multiple databases were to be 
> opened). i temporarily commented out the section that opens the db environment 
> (bundle_env->open() call on the bundle directory) to find that the call to 
> open the individual databases (bundleDb.c:334) fails with the same error 
> (Invalid argument).

These are two completely different function calls. The first is
bundle_env->open, which sets up the Bundles directory as the
berkeleydb home for all the databases used by the bundleDaemon.  The
subsequent db_open calls create the individual databases (bundles,
registration, and misc) within the Bundles directory.

By the way, if you need some documentation on the bundleDaemon,
there's a bundleDaemon.texi file in the bundleDaemon directory. Run
texi2pdf. There's not a lot of info on configurating the databases,
but there are some instructions on setting up configuration files for
the bundleDaemon.

Melissa

Date: Thu, 13 May 2004 19:36:08 -0400
From: Manikantan Ramadas <[email-masked]>
To: Josef Kriegl <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] initialize_bundle_dbs - invalid argument
Sender: [email-masked]

Hey,

  I had some such compilation issues last time I tried to install. But
getting Berkeley DB 4.1.25 installed fixed most of them. [This was on a
GNU/Linux platform running on my PIII laptop.]

- Mani.

On Thu, May 13, 2004 at 10:28:54AM +0200, Josef Kriegl wrote:
> hi,
> 
> i downloaded and cross-compiled the DTN code for a linux/hitachi platform from the cvs head. i ran into problems trying to open the database environment in the function
> 
> bundleDB.c:initialize_bundle_dbs()
> 
> specifically, the call to bundle_ev->open() in bundleDb.c:line 294 fails with
> 
> ret = 22 [errno:2] (Invalid argument)
> 
> i have to admit am not up to speed with the berkely db API, but was wondering why bundle_ev->open() is called with the bundle directory as an argument, when further down (bundleDb.c:334) bundle_ev->open() is called in a loop on a file and a number of databases within that file (as i would expect if multiple databases were to be opened). i temporarily commented out the section that opens the db environment (bundle_env->open() call on the bundle directory) to find that the call to open the individual databases (bundleDb.c:334) fails with the same error (Invalid argument).
> 
> is this a known problem, or is possible this error has to do with my specific directory structure / configuration / db status? is it the version of the berkely db i use (4.0.14)? or should i not be using code from the head at this point, but rather a tagged version?
> 
> thanks for your help,
> josef

-- 
"'Beauty is truth, truth beauty,'--that is all
  Ye know on earth, and all ye need to know." - John Keats
____________________________________________________________________
  
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

From: "Josef Kriegl" <[email-masked]>
To: <[email-masked]>
Subject: Re: [dtn-interest] initialize_bundle_dbs - invalid argument
Date: Fri, 14 May 2004 00:09:48 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_03AE_01C43947.C534F560
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

well, an upgrade to the berkeley db version 4.2.52 resulted in the =
database file being created successfully, however, other types of error =
messages now show (as far as i can tell these are errors from the db =
library):

NP-201:/mnt/root/NETPAK-VALIDATED/3party/dtn/Stage# cat =
/var/bundles/errors
initialize_bundle_dbs: page 0: illegal page type or format
initialize_bundle_dbs: PANIC: Invalid argument
initialize_bundle_dbs: PANIC: fatal region error detected; run recovery
initialize_bundle_dbs: PANIC: fatal region error detected; run recovery
initialize_bundle_dbs: PANIC: fatal region error detected; run recovery
initialize_bundle_dbs: PANIC: DB_RUNRECOVERY: Fatal error, run database =
recovery
initialize_bundle_dbs: db->open: bundles: DB_RUNRECOVERY: Fatal error, =
run database recovery
initialize_bundle_dbs: PANIC: fatal region error detected; run recovery

josef

  ----- Original Message -----=20
  From: Robert C. Durst=20
  To: Josef Kriegl=20
  Sent: Thursday, May 13, 2004 5:59 PM
  Subject: Re: [dtn-interest] initialize_bundle_dbs - invalid argument

  Josef,

  Hi.  Am on travel right now, but off the top of my head, I'd suspect =
that the ./configure script thinks you're using a version of the =
database other than 4.0.14.  Our initial development used that version, =
and it is valid with the configure script (and the code should run), but =
I'd *strongly* recommend a newer version of the berkeley db code =
(www.sleepycat.com), and providing inputs to the configure script =
appropriately.

  Best regards,
  Bob Durst
  [email-masked]

  Josef Kriegl wrote:

    hi,

    i downloaded and cross-compiled the DTN code for a linux/hitachi =
platform from the cvs head. i ran into problems trying to open the =
database environment in the function

    bundleDB.c:initialize_bundle_dbs()

    specifically, the call to bundle_ev->open() in bundleDb.c:line 294 =
fails with

    ret =3D 22 [errno:2] (Invalid argument)

    i have to admit am not up to speed with the berkely db API, but was =
wondering why bundle_ev->open() is called with the bundle directory as =
an argument, when further down (bundleDb.c:334) bundle_ev->open() is =
called in a loop on a file and a number of databases within that file =
(as i would expect if multiple databases were to be opened). i =
temporarily commented out the section that opens the db environment =
(bundle_env->open() call on the bundle directory) to find that the call =
to open the individual databases (bundleDb.c:334) fails with the same =
error (Invalid argument).

    is this a known problem, or is possible this error has to do with my =
specific directory structure / configuration / db status? is it the =
version of the berkely db i use (4.0.14)? or should i not be using code =
from the head at this point, but rather a tagged version?

    thanks for your help,
    josef

------=_NextPart_000_03AE_01C43947.C534F560
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>well, an upgrade to the =
berkeley db version=20
4.2.52 resulted in the database file being created successfully, =
however, other=20
types of error messages now show (as far as i can tell these are errors =
from the=20
db library):</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New"=20
size=3D2>NP-201:/mnt/root/NETPAK-VALIDATED/3party/dtn/Stage# cat=20
/var/bundles/errors<BR>initialize_bundle_dbs: page 0: illegal page type =
or=20
format<BR>initialize_bundle_dbs: PANIC: Invalid=20
argument<BR>initialize_bundle_dbs: PANIC: fatal region error detected; =
run=20
recovery<BR>initialize_bundle_dbs: PANIC: fatal region error detected; =
run=20
recovery<BR>initialize_bundle_dbs: PANIC: fatal region error detected; =
run=20
recovery<BR>initialize_bundle_dbs: PANIC: DB_RUNRECOVERY: Fatal error, =
run=20
database recovery<BR>initialize_bundle_dbs: db-&gt;open: bundles:=20
DB_RUNRECOVERY: Fatal error, run database =
recovery<BR>initialize_bundle_dbs:=20
PANIC: fatal region error detected; run recovery</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>josef</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[email-masked] href=3D"mailto:[email-masked]">Robert C. =
Durst</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">Josef Kriegl</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, May 13, 2004 =
5:59=20
PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: [dtn-interest]=20
  initialize_bundle_dbs - invalid argument</DIV>
  <DIV><BR></DIV>Josef,<BR><BR>Hi.&nbsp; Am on travel right now, but off =
the top=20
  of my head, I'd suspect that the ./configure script thinks you're =
using a=20
  version of the database other than 4.0.14.&nbsp; Our initial =
development used=20
  that version, and it is valid with the configure script (and the code =
should=20
  run), but I'd *strongly* recommend a newer version of the berkeley db =
code (<A=20
  class=3Dmoz-txt-link-abbreviated=20
  href=3D"http://www.sleepycat.com">www.sleepycat.com</A>), and =
providing inputs=20
  to the configure script appropriately.<BR><BR>Best regards,<BR>Bob =
Durst<BR><A=20
  class=3Dmoz-txt-link-abbreviated=20
  href=3D"mailto:[email-masked]">[email-masked]</A><BR><BR>Josef =
Kriegl=20
  wrote:<BR>
  <BLOCKQUOTE cite=3Dmid026f01c438c4$54bc7980$a100a8c0@SENSORIA =
type=3D"cite">
    <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
    <STYLE></STYLE>

    <DIV><FONT face=3D"Courier New" size=3D2>hi,</FONT></DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT face=3D"Courier New" size=3D2>i downloaded and =
cross-compiled the DTN=20
    code for a linux/hitachi platform from the cvs head. i&nbsp;ran into =

    problems trying to open the database environment in the=20
function</FONT></DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT face=3D"Courier New"=20
    size=3D2>bundleDB.c:initialize_bundle_dbs()</FONT></DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT face=3D"Courier New" size=3D2>specifically, the call to=20
    bundle_ev-&gt;open() in bundleDb.c:line 294 fails with</FONT></DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT face=3D"Courier New" size=3D2>ret =3D 22 [errno:2] =
(Invalid=20
    argument)</FONT></DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT face=3D"Courier New" size=3D2>i have to admit am not up =
to speed with=20
    the berkely db API, but was wondering why bundle_ev-&gt;open() is =
called=20
    with the bundle directory as an argument, when further down =
(bundleDb.c:334)=20
    bundle_ev-&gt;open() is called in a loop&nbsp;on a file and a number =
of=20
    databases within that file (as i would expect if multiple databases =
were to=20
    be opened). i temporarily commented out the section that opens the =
db=20
    environment (bundle_env-&gt;open() call on the bundle directory) to =
find=20
    that the call to open the individual databases&nbsp;(bundleDb.c:334) =
fails=20
    with the same error (Invalid argument).</FONT></DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT face=3D"Courier New" size=3D2>is this a known problem, =
or&nbsp;is=20
    possible this error has to do with my specific directory structure / =

    configuration / db status? is it the version of =
the&nbsp;</FONT><FONT=20
    face=3D"Courier New" size=3D2>berkely db i use (4.0.14)? or should i =
not be=20
    using code from the head at this point, but rather a tagged=20
    version?</FONT></DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT face=3D"Courier New" size=3D2>thanks for your =
help,</FONT></DIV>
    <DIV><FONT face=3D"Courier New" size=3D2>josef</FONT></DIV>
    <DIV>&nbsp;</DIV></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_03AE_01C43947.C534F560--

From: "Josef Kriegl" <[email-masked]>
To: <[email-masked]>
Date: Thu, 13 May 2004 12:19:44 +0200
Subject: [dtn-interest] Fw: initialize_bundle_dbs - invalid argument
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_029B_01C438E4.9337C0A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

to follows up on my previous problem report - i noticed the message =
'fast mutexes not supported on this platform' in /var/bundles/errors). i =
then disabled DB_THREAD flag, following the advice in the berkeley db =
documenation:

http://www.sleepycat.com/docs/api_c/db_open.html

initialize_bundle_dbs still fails, though, with a new set of error =
messages (in /var/bundles/errors) as follows:

initialize_bundle_dbs: bundles.db: unexpected file type or format
initialize_bundle_dbs: db->open: bundles: Invalid argument
initialize_bundle_dbs: Database handles open during environment close

josef

----- Original Message -----=20
From: Josef Kriegl=20
To: [email-masked]=20
Sent: Thursday, May 13, 2004 10:28 AM
Subject: initialize_bundle_dbs - invalid argument

hi,

i downloaded and cross-compiled the DTN code for a linux/hitachi =
platform from the cvs head. i ran into problems trying to open the =
database environment in the function

bundleDB.c:initialize_bundle_dbs()

specifically, the call to bundle_ev->open() in bundleDb.c:line 294 fails =
with

ret =3D 22 [errno:2] (Invalid argument)

i have to admit am not up to speed with the berkely db API, but was =
wondering why bundle_ev->open() is called with the bundle directory as =
an argument, when further down (bundleDb.c:334) bundle_ev->open() is =
called in a loop on a file and a number of databases within that file =
(as i would expect if multiple databases were to be opened). i =
temporarily commented out the section that opens the db environment =
(bundle_env->open() call on the bundle directory) to find that the call =
to open the individual databases (bundleDb.c:334) fails with the same =
error (Invalid argument).

is this a known problem, or is possible this error has to do with my =
specific directory structure / configuration / db status? is it the =
version of the berkely db i use (4.0.14)? or should i not be using code =
from the head at this point, but rather a tagged version?

thanks for your help,
josef

------=_NextPart_000_029B_01C438E4.9337C0A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Courier New" size=3D2>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>to follows up on my previous =
problem report=20
- i noticed the message 'fast mutexes not supported on this platform' in =

/var/bundles/errors).&nbsp;i then disabled&nbsp;DB_THREAD flag, =
following the=20
advice in the berkeley db documenation:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><A=20
href=3D"http://www.sleepycat.com/docs/api_c/db_open.html">http://www.slee=
pycat.com/docs/api_c/db_open.html</A></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>initialize_bundle_dbs still =
fails, though,=20
with a new set of&nbsp;error messages (in /var/bundles/errors) as=20
follows:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>initialize_bundle_dbs: =
bundles.db:=20
unexpected file type or format<BR>initialize_bundle_dbs: db-&gt;open: =
bundles:=20
Invalid argument<BR>initialize_bundle_dbs: Database handles open during=20
environment close</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>josef</FONT></DIV>
<DIV>&nbsp;</DIV></FONT></DIV>
<DIV style=3D"FONT: 10pt arial">----- Original Message -----=20
<DIV style=3D"BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> <A=20
title=[email-masked] href=3D"mailto:[email-masked]">Josef =
Kriegl</A>=20
</DIV>
<DIV><B>To:</B> <A title=[email-masked]=20
href=3D"mailto:[email-masked]">[email-masked]=
.org</A>=20
</DIV>
<DIV><B>Sent:</B> Thursday, May 13, 2004 10:28 AM</DIV>
<DIV><B>Subject:</B> initialize_bundle_dbs - invalid =
argument</DIV></DIV>
<DIV><BR></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>hi,</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>i downloaded and cross-compiled =
the DTN=20
code for a linux/hitachi platform from the cvs head. i&nbsp;ran into =
problems=20
trying to open the database environment in the function</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New"=20
size=3D2>bundleDB.c:initialize_bundle_dbs()</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>specifically, the call to=20
bundle_ev-&gt;open() in bundleDb.c:line 294 fails with</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>ret =3D 22 [errno:2] (Invalid=20
argument)</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>i have to admit am not up to =
speed with the=20
berkely db API, but was wondering why bundle_ev-&gt;open() is called =
with the=20
bundle directory as an argument, when further down (bundleDb.c:334)=20
bundle_ev-&gt;open() is called in a loop&nbsp;on a file and a number of=20
databases within that file (as i would expect if multiple databases were =
to be=20
opened). i temporarily commented out the section that opens the db =
environment=20
(bundle_env-&gt;open() call on the bundle directory) to find that the =
call to=20
open the individual databases&nbsp;(bundleDb.c:334) fails with the same =
error=20
(Invalid argument).</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>is this a known problem, =
or&nbsp;is=20
possible this error has to do with my specific directory structure /=20
configuration / db status? is it the version of the&nbsp;</FONT><FONT=20
face=3D"Courier New" size=3D2>berkely db i use (4.0.14)? or should i not =
be using=20
code from the head at this point, but rather a tagged =
version?</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>thanks for your =
help,</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>josef</FONT></DIV>
<DIV><FONT face=3D"Courier New" =
size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_029B_01C438E4.9337C0A0--

From: "Josef Kriegl" <[email-masked]>
To: <[email-masked]>
Date: Thu, 13 May 2004 10:28:54 +0200
Subject: [dtn-interest] initialize_bundle_dbs - invalid argument
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_026C_01C438D5.175BACD0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

hi,

i downloaded and cross-compiled the DTN code for a linux/hitachi =
platform from the cvs head. i ran into problems trying to open the =
database environment in the function

bundleDB.c:initialize_bundle_dbs()

specifically, the call to bundle_ev->open() in bundleDb.c:line 294 fails =
with

ret =3D 22 [errno:2] (Invalid argument)

i have to admit am not up to speed with the berkely db API, but was =
wondering why bundle_ev->open() is called with the bundle directory as =
an argument, when further down (bundleDb.c:334) bundle_ev->open() is =
called in a loop on a file and a number of databases within that file =
(as i would expect if multiple databases were to be opened). i =
temporarily commented out the section that opens the db environment =
(bundle_env->open() call on the bundle directory) to find that the call =
to open the individual databases (bundleDb.c:334) fails with the same =
error (Invalid argument).

is this a known problem, or is possible this error has to do with my =
specific directory structure / configuration / db status? is it the =
version of the berkely db i use (4.0.14)? or should i not be using code =
from the head at this point, but rather a tagged version?

thanks for your help,
josef

------=_NextPart_000_026C_01C438D5.175BACD0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Courier New" size=3D2>hi,</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>i downloaded and cross-compiled =
the DTN=20
code for a linux/hitachi platform from the cvs head. i&nbsp;ran into =
problems=20
trying to open the database environment in the function</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New"=20
size=3D2>bundleDB.c:initialize_bundle_dbs()</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>specifically, the call to=20
bundle_ev-&gt;open() in bundleDb.c:line 294 fails with</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>ret =3D 22 [errno:2] (Invalid=20
argument)</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>i have to admit am not up to =
speed with the=20
berkely db API, but was wondering why bundle_ev-&gt;open() is called =
with the=20
bundle directory as an argument, when further down (bundleDb.c:334)=20
bundle_ev-&gt;open() is called in a loop&nbsp;on a file and a number of=20
databases within that file (as i would expect if multiple databases were =
to be=20
opened). i temporarily commented out the section that opens the db =
environment=20
(bundle_env-&gt;open() call on the bundle directory) to find that the =
call to=20
open the individual databases&nbsp;(bundleDb.c:334) fails with the same =
error=20
(Invalid argument).</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>is this a known problem, =
or&nbsp;is=20
possible this error has to do with my specific directory structure /=20
configuration / db status? is it the version of the&nbsp;</FONT><FONT=20
face=3D"Courier New" size=3D2>berkely db i use (4.0.14)? or should i not =
be using=20
code from the head at this point, but rather a tagged =
version?</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>thanks for your =
help,</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>josef</FONT></DIV>
<DIV><FONT face=3D"Courier New" =
size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_026C_01C438D5.175BACD0--

To: [email-masked]
Date: Wed, 05 May 2004 23:40:40 -0700
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] CCR Issue on Network Design + SIGCOMM/FDNA 04 revised deadline reminder
Sender: [email-masked]

This may be of interest below, if you have not seen it already.

Also (reminder) that the FDNA 04 workshop revised deadline
is this friday (see http://fdna04.watsmore.net/).  

cheers,
- K

------- Forwarded Message

>
> From:  Taieb Znati <[email-masked]>
> To:    Taieb Znati <[email-masked]>
> Subject: CCR Net Science of Design : Final Reminder
> Date:  Wed, 05 May 2004 18:02:29 EDT
>
> Hello,
> 
> This is a reminder that the deadline for the
> ACM SIGCOMM Computer Communication Review
> Special Issue on Science of Networking Design
> is approaching. 
> 
> Due to numerous requests, extensions of the paper submission deadline to 
> Friday, May 14th, 2004 will be granted, on request to the issue editor by the
> original deadline of Friday, May 7th.
> 
> Additional information can be found at http://www.acm.org/sigcomm/CCR/NetSoD/
. 
> Please, submit your paper directly to [email-masked].
> 
> I am also attaching a copy of the CFP to this message.
> 
> If you do not plan to submit a paper and would like to participate
> in the review process, please, let us know by sending an email
> message directly to [email-masked] with "NetSoD Reviewer" as a subject
> topic. 
> 
> Thank you very much.
> 
> Prof. Ty Znati
> Computer Science Department
> University of Pittsburgh
> Senior Program Director
> CNS/NSF
> 
> --------------------------------------------------------------------------
> 
> Call for Papers
> ACM SIGCOMM Computer Communication Review
> Special Issue on Science of Networking Design
> 
> Synopsis
> 
> The need to deal with the complexity and ramifications of large scale 
> systems is intensifying the interest in the science of system design 
> - fundamental principles, accurate models, rigorous and repeatable 
> design methodologies, and systematic evaluation frameworks. 
> Leveraging many disciplines, the design of complex 
> systems is on the verge of becoming a scientific field of study in 
> its own right. The focus of this special issue is on the Science of 
> Networking Design. We seek original research results, visionary 
> approaches, future research directions to advance the state of the 
> art of designing, robust, large-scale, heterogeneous networks. The 
> scope of topics included in the call is broad, covering theories, 
> principles, models, tools, and empirical studies to advance 
> our understanding of the science of networks and their design.
> 
> Scope
> 
> The Internet design philosophy has mostly been driven by rough 
> guidelines and principles that have proven to be of enduring value in 
> building high-performance and robust distributed systems. Now, 
> however, the increasing importance of highly heterogeneous, 
> large-scale networks with complex behaviors and unpredictable 
> dynamics, together with a growing understanding of the fundamental 
> principles and laws of such systems, motivate a search for new design 
> principles and methods that reach beyond today's levels of 
> performance, robustness, and efficiency.  One source of difficulty in 
> achieving this goal arises from the non-linear interactions among the 
> system's components, which can lead to unanticipated emergent 
> behavior. A second form of complexity arises from the pervasive and 
> ubiquitous nature of next generation networking systems. A third 
> source of difficulty stems from the need to incorporate in the design 
> human, social and economical values, while accommodating different 
> organizational structures and diverse societal expectations. To 
> address these issues, there is a need to go beyond current reliance 
> on intuitive principles and develop a scientific and engineering 
> foundation to guide and advance the task of designing robust, 
> large-scale heterogeneous networks.
> 
> This call solicits papers for ACM SIGCOMM Communication Review's 
> July, 2004 special section on Science of Networking Design. We seek  
> novel contributions, with a focus on a specific 
> discipline or stimulated by the synergistic interaction of diverse 
> disciplines, are encouraged. Topics of interest include, but are not 
> limited to:
> 
>   - Mathematical frameworks and formal models to assess the limits of 
> current Internet design principles and their applicability to the 
> design of large-scale, heterogeneous networks in the absence of 
> complete and correct specifications
> 
>   - Theories underlying effective design, development and evolution of 
> complex network systems. The emphasis should be on scalability, 
> heterogeneity and decentralized authority and planning.
> 
>   - Theories and tools to explain, predict and control desired and 
> emergent properties and behaviors in large-scale, heterogeneous 
> networks.
> 
>   - Novel architectures and tools for predictable network design under 
> condition of uncertainty and incomplete information.
> 
>   - New frameworks and architectures that rely on aggregate reasoning 
> about overall behavior of a complex network system, rather than exact 
> behavior of its components, to quantify specific properties of the 
> system.
> 
>   - Modeling and simulation frameworks, tools and methodologies for 
> large-scale, heterogeneous networks, which deal explicitly with the 
> presence of human-induced uncertainty in systems.
> 
>   - Methods, tools and metrics to evaluate design alternatives of 
> extreme scope, scale and complexity, offering guidance on design 
> selection.
> 
> Submission and Review Process:
> 
> The special issue seeks for review original 
> contributions that have not been previously published and are not 
> currently under review by another conference or journal. Two types of 
> submissions will be considered for this issue:
> 
>   - Regular papers presenting new research works related to the theory 
> or practice of Science of Networking Design.
> 
>   - Challenge papers articulating future research directions, 
> challenges, visionary approaches and novel frameworks in the field of 
> Science of Networking Design. Papers in this category must be forward 
> looking, thought provoking and stimulating, with potential for 
> opening new research venues in the field.
> 
> The length of the paper must not exceed 20 pages (US "Letter" size, 
> 8.5 x 11 inches) including text, figures and references, in 
> single-column, single-space format, with a font size of at least 10 
> points.
> 
> All types of papers will be externally reviewed for their 
> intellectual merits and relevance to the special issue.
> 
> Please see the long-form CFP at 
> http://www.acm.org/sigcomm/CCR/NetSOD/ for additional information and 
> submission instructions. Questions about the issue or submission 
> process should be directed to <[email-masked]>.
> 
> To submit a paper, please refer to the paper submission link at the 
> special issue website, http://www.acm.org/sigcomm/CCR/NetSoD/. 
> Questions about the submission process should be directed to 
> <[email-masked] >.
> 
> KEY DATES:
> 
> Paper submission: 		May 7, 2004 (Friday Deadline)
> Acceptance notification: 	June 7, 2004 (Monday Deadline)
> Camera-ready copy: 		July 7, 2004  (Wednesday Deadline)
> Expected Publication date:	July 30, 2004
> 
> 
> Issue Editor: 			Prof. Ty Znati
> 				University of Pittsburgh and NSF
> 
> 
> 

------- End of Forwarded Message

Date: Wed, 05 May 2004 10:23:33 -0500
From: Matt Bradbury <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Dynamic packet resizing increases Wifi throughput 100%
Sender: [email-masked]

Interesting article for everyone looking into ways of predicting and 
dealing with congestion. 

http://developers.slashdot.org/developers/04/05/04/2240234.shtml?tid=126&tid=137&tid=193

-Matt