Subject: Re: [dtn-users] sketch question
From: "ryan m" <[email-masked]>
To: "飞影" <[email-masked]>, "dtn-users mailing list" <[email-masked]>
Date: Sat, 29 Mar 2008 12:35:15 -0400
List-Id: dtn-users mailing list <dtn-users.mailman.dtnrg.org>

If you click on the "to do" link you'll see that the sketch is one of
the items on the todo list "write the arch.html page, which will draw
heavily on Mike's (and other people's) paper."  So I'm guessing that
the sketch does not exist.

On Sat, Mar 29, 2008 at 8:19 AM, 飞影 <[email-masked]> wrote:
> http://www.dtnrg.org/docs/code/DTN2/doc/manual/arch.html
>  In this page, we should find a sketch of how the whole thing fits together. But I found nothing but the following words:
>  "Architecture of DTN2
>  In this page, you would find a sketch of how the whole thing fits together. Please see the to do list for information on how you can help."
>  Now I need the sketch. Where can I get it?
>  Thanks
>
>  _______________________________________________
>  dtn-users mailing list
>  [email-masked]
>  http://maillists.intel-research.net/mailman/listinfo/dtn-users
>

To: [email-masked]
From: "=?GB2312?B?t8nTsA==?=" <[email-masked]>
Date: Sat, 29 Mar 2008 20:19:31 +0800 (CST) 
Subject: [dtn-users] sketch question
Reply-To: =?GB2312?B?t8nTsA==?= <[email-masked]>, dtn-users mailing list <[email-masked]>

http://www.dtnrg.org/docs/code/DTN2/doc/manual/arch.html 
In this page, we should find a sketch of how the whole thing fits together. But I found nothing but the following words: 
"Architecture of DTN2 
In this page, you would find a sketch of how the whole thing fits together. Please see the to do list for information on how you can help." 
Now I need the sketch. Where can I get it? 
Thanks

Date: Wed, 26 Mar 2008 23:56:55 -0700
From: Anuj Agarwal <[email-masked]>
To: dtn-users mailing list <[email-masked]>, [email-masked]
Priority: normal
Subject: Re: [dtn-users] dtnperf does not send more than one bundle
Reply-To: dtn-users mailing list <[email-masked]>

Hi,

Resolved. It was a clock synch issue. My acks were getting scheduled for immediate expiration since my server clock was not in synch. Had to resync both my client and server clocks with NTP to get it working.

Thanks,
-Anuj.

----- Original Message -----
From: Anuj Agarwal <[email-masked]>
Date: Wednesday, March 26, 2008 6:11 pm
Subject: [dtn-users] dtnperf does not send more than one bundle
To: [email-masked], [email-masked]

> Hi,
> 
> I have a 2 node dtn and I am trying to use the dtnperf application. 
> However, now matter what I try to do (timed mode/data mode/varying 
> bundle sizes etc.), My client sends just one bundle and waits. 
> I cant seem to figure out whats going wrong despite using the debug 
> and verbose options
> 
> For example:
> 
> Client: (detroit.localdomain.dtn)
> Server: (michigan.localdomain.dtn)
> 
> On the client:
> [anuj@detroit dtnperf]# ./dtnperf-client -d 
> dtn://michigan.localdomain.dtn -t 5- p 20K
> 
> With the -v option I can see:
> 
> Requested 5 second(s) of transmission
> payload of each bundle = 20480 byte(s)
> 
> 
> Source     : dtn://detroit.localdomain.dtn/dtnperf:/src
> Destination: dtn://michigan.localdomain.dtn/dtnperf:/dest
> Reply-to   : dtn://detroit.localdomain.dtn/dtnperf:/src
> 
> Working in Time_Mode
> requested 5 second(s) of transmission
> transmitting data using memory
> 
> With the -d option:
> 
> [debug] parsed command-line options
> [debug] checking command-line options... done
> Opening connection to local DTN daemon... done
> [debug] memset for bundle_spec... done
> [debug] setting replyto = source... done
> [debug] setting the DTN options: DELIVERY_RCPT option(s) set
> [debug] memset for reginfo... done
> [debug] copying bundle_spec.replyto to reginfo.endpoint... done
> [debug] setting up reginfo... done
> [debug] registering to local daemon... done: regid 0x43
> [debug] bundle_payload < 50000 bytes
> [debug] reset data_qty and bundles_sent... done
> [debug] malloc for the buffer... done
> [debug] initialize the buffer with a pattern... done
> [debug] bufferLen = 20480
> [debug] memset for payload... done
> [debug] filling payload... done
> [debug] initializing timer... start.tv_sec = 1206579664 sec
> [debug] calculating end-time... end.tv_sec = 1206579669 sec
> [debug] entering loop...
>        [debug] now.tv_sec = 1206579664 sec of 1206579669
>        [debug] sending the bundle... bundle sent
>        [debug] now bundles_sent is 1
>        [debug] now data_qty is 20480
>        [debug] memset for reply_spec... done
>        [debug] memset for reply_payload... done
> 
> 
> The dtn daemon shows:
> 
> [1206579664.898019 /dtn/bundle/expiration warning] scheduling 
> IMMEDIATE expiration for bundle id 445: [expiration 3600, creation 
> time 259884364.235, offset 946684800, now 1206579664.898007]
> 
> I am not sure why I get the above message.
> 
> 
> On the DTN  Perf Server:
> 
> If run the server without any command line options:
> 
> Wed Mar 26 18:06:04 2008
> : 20480 bytes from dtn://detroit.localdomain.dtn/dtnp
> 
> With the -D option:
> 
> Wed Mar 26 18:11:12 2008
> : 20480 bytes from dtn://detroit.localdomain.dtn/dtnperf:/src
> [debug] copying source eid... done:
>        source_eid = dtn://detroit.localdomain.dtn/dtnperf:/src
> 
> [debug] copying dest eid... done:
>        dest_eid = dtn://michigan.localdomain.dtn/dtnperf:/dest
> 
> [debug] filepath = mkdir -p /var/dtn/dtnperf
> [debug] filepath = /var/dtn/dtnperf/dtnbuffer.rcv
> ======================================
> Bundle received at Wed Mar 26 18:11:12 2008
> 
>  source: dtn://detroit.localdomain.dtn/dtnperf:/src
>  saved into    : /var/dtn/dtnperf/dtnbuffer.rcv
> --------------------------------------
> [debug] renaming file /tmp/bundlePayload_y4hoUh -> 
> /var/dtn/dtnperf/dtnbuffer.rcv...
> 
> Any help would be appreciated,
> 
> Thanks and Regards,
> -Anuj.
> 
> 
> 
> 
> 
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users
> 

Date: Wed, 26 Mar 2008 18:09:07 -0700
From: Anuj Agarwal <[email-masked]>
To: [email-masked], [email-masked]
Priority: normal
Subject: [dtn-users] dtnperf does not send more than one bundle
Reply-To: dtn-users mailing list <[email-masked]>

Hi,

I have a 2 node dtn and I am trying to use the dtnperf application. However, now matter what I try to do (timed mode/data mode/varying bundle sizes etc.), My client sends just one bundle and waits. 
I cant seem to figure out whats going wrong despite using the debug and verbose options

For example:

Client: (detroit.localdomain.dtn)
Server: (michigan.localdomain.dtn)

On the client:
[anuj@detroit dtnperf]# ./dtnperf-client -d dtn://michigan.localdomain.dtn -t 5- p 20K

With the -v option I can see:

Requested 5 second(s) of transmission
 payload of each bundle = 20480 byte(s)

Source     : dtn://detroit.localdomain.dtn/dtnperf:/src
Destination: dtn://michigan.localdomain.dtn/dtnperf:/dest
Reply-to   : dtn://detroit.localdomain.dtn/dtnperf:/src

Working in Time_Mode
requested 5 second(s) of transmission
 transmitting data using memory

With the -d option:

[debug] parsed command-line options
[debug] checking command-line options... done
Opening connection to local DTN daemon... done
[debug] memset for bundle_spec... done
[debug] setting replyto = source... done
[debug] setting the DTN options: DELIVERY_RCPT option(s) set
[debug] memset for reginfo... done
[debug] copying bundle_spec.replyto to reginfo.endpoint... done
[debug] setting up reginfo... done
[debug] registering to local daemon... done: regid 0x43
[debug] bundle_payload < 50000 bytes
[debug] reset data_qty and bundles_sent... done
[debug] malloc for the buffer... done
[debug] initialize the buffer with a pattern... done
[debug] bufferLen = 20480
[debug] memset for payload... done
[debug] filling payload... done
[debug] initializing timer... start.tv_sec = 1206579664 sec
[debug] calculating end-time... end.tv_sec = 1206579669 sec
[debug] entering loop...
        [debug] now.tv_sec = 1206579664 sec of 1206579669
        [debug] sending the bundle... bundle sent
        [debug] now bundles_sent is 1
        [debug] now data_qty is 20480
        [debug] memset for reply_spec... done
        [debug] memset for reply_payload... done

The dtn daemon shows:

[1206579664.898019 /dtn/bundle/expiration warning] scheduling IMMEDIATE expiration for bundle id 445: [expiration 3600, creation time 259884364.235, offset 946684800, now 1206579664.898007]

I am not sure why I get the above message.

On the DTN  Perf Server:

If run the server without any command line options:

Wed Mar 26 18:06:04 2008
 : 20480 bytes from dtn://detroit.localdomain.dtn/dtnp

With the -D option:

Wed Mar 26 18:11:12 2008
 : 20480 bytes from dtn://detroit.localdomain.dtn/dtnperf:/src
[debug] copying source eid... done:
        source_eid = dtn://detroit.localdomain.dtn/dtnperf:/src

[debug] copying dest eid... done:
        dest_eid = dtn://michigan.localdomain.dtn/dtnperf:/dest

[debug] filepath = mkdir -p /var/dtn/dtnperf
[debug] filepath = /var/dtn/dtnperf/dtnbuffer.rcv
======================================
 Bundle received at Wed Mar 26 18:11:12 2008

  source: dtn://detroit.localdomain.dtn/dtnperf:/src
  saved into    : /var/dtn/dtnperf/dtnbuffer.rcv
--------------------------------------
[debug] renaming file /tmp/bundlePayload_y4hoUh -> /var/dtn/dtnperf/dtnbuffer.rcv...

Any help would be appreciated,

Thanks and Regards,
-Anuj.

From: Michael Demmer <[email-masked]>
To: dtn-users mailing list <[email-masked]>
Date: Tue, 25 Mar 2008 23:25:12 -0700
Subject: Re: [dtn-users] Problem with Bundle Forwarding
Reply-To: dtn-users mailing list <[email-masked]>

Hi Brian,

This is a bug in the forwarding logic implemented in the static router.

Basically what happens is that the routing code has made a decision to  
forward the bundle to D4 -- that's what the TRANSMIT_PENDING  
forwarding log entry means -- so it doesn't reroute it properly and  
realize that it should actually forward it to D2. You could fix the  
situation by stopping and starting the DTN daemon, which would cause  
it to forcably reroute the bundle.

Also, the development version of DTN2 that's in the mercurial  
repository contains some reworked forwarding logic that should address  
this problem. You could try that and see if it works better. However,  
you should be warned that I haven't had much chance to do deep testing  
so there may be other bugs lurking in there.

If you do try it out and still run into problems, please email me.

-mike

On Mar 25, 2008, at 5:47 PM, Smith, Brian J wrote:

> I have a four node DTN Network -- laptops with hostnames D2, D3, D4,  
> and D5.  All of the nodes have a DTN Daemon running on them.  Three  
> of the nodes - D2, D3, and D4 - have two network interface cards  
> installed.  I am modifying the DTN routes and links at runtime via a  
> socket connection to the DTN Daemon.  I have the DTN routes and  
> links set up on all the nodes so that my begining network looks like  
> this:
>
> D5 <--> D4 <--> D2 <--> D3
>
> If I do a "route dump" command on the D2 DTN Daemon:
>
>
>
> Route table for static router:
>
> destination        source COS    next hop         fwd    route  
> [custody timeout]
> endpoint id         eid   BNE    link/eid        action   prio  
> [min   pct   max]
> --------------------------------------------------------------------------------
> ----------
> dtn://d3.dtn/* *:*    111 -> link_dtn... [0] FORWARD     0 [1800    
> 25     0]
> dtn://d4.dtn/* *:*    111 -> link_dtn... [1] FORWARD     0 [1800    
> 25     0]
> dtn://d5.dtn/* *:*    111 -> link_dtn... [1] FORWARD     0 [1800    
> 25     0]
> dtn://d3.dtn/* *:*    111 -> opportunistic-0 FORWARD     0 [1800    
> 25     0]
> dtn://d4.dtn/* *:*    111 -> opportunistic-1 FORWARD     0 [1800    
> 25     0]
>
> Long EIDs/Links referenced above:
>        [0]: link_dtn://d3.dtn192.168.0.17
>        [1]: link_dtn://d4.dtn10.0.0.9
>
>
> Class of Service (COS) bits:
>        B: Bulk  N: Normal  E: Expedited
>
> Links:
> null [/dev/null dtn:none ALWAYSON null state=OPEN]
> opportunistic-0 [192.168.0.17:42209 dtn://d3.dtn OPPORTUNISTIC tcp  
> state=OPEN]
> link_dtn://d3.dtn192.168.0.17 [192.168.0.17:4556 dtn:none ONDEMAND  
> tcp state=AVAILABLE]
> link_dtn://d4.dtn10.0.0.9 [10.0.0.9:4556 dtn:none ONDEMAND tcp  
> state=AVAILABLE]
> opportunistic-1 [10.0.0.9:37717 dtn://d4.dtn OPPORTUNISTIC tcp  
> state=OPEN]
>
>
>
> I am able to send bundles to and from each of the nodes without any  
> problems.  I then physically disconnect the link between D2 and D4,  
> but there is delay before the routes and links in the DTN Daemon are  
> changed to reflect the network topology change.  Before the routes  
> and links programmed in the DTN Daemon are updated to reflect the  
> changed network topology, I send a bundle from D3 to D5.  The bundle  
> is forwarded to D2, but since the physical link between D2 and D4  
> has been broken, the bundle stays on D2.  I then physically connect  
> D3 to D4 and update the routes and links on the DTN Daemons  
> accordingly.  So my network now looks like this (D2 and D3 have  
> essentially swapped positions in the network):
>
> D5 <--> D4 <--> D3 <--> D2
>
> If I again do a "route dump" command on the D2 DTN Daemon:
>
>
>
> Route table for static router:
>
> destination        source COS    next hop         fwd    route  
> [custody timeout]
> endpoint id         eid   BNE    link/eid        action   prio  
> [min   pct   max]
> --------------------------------------------------------------------------------
> ----------
> dtn://d3.dtn/* *:*    111 -> link_dtn... [0] FORWARD     0 [1800    
> 25     0]
> dtn://d4.dtn/* *:*    111 -> link_dtn... [0] FORWARD     0 [1800    
> 25     0]
> dtn://d5.dtn/* *:*    111 -> link_dtn... [0] FORWARD     0 [1800    
> 25     0]
>
> Long EIDs/Links referenced above:
>        [0]: link_dtn://d3.dtn192.168.0.17
>
>
> Class of Service (COS) bits:
>        B: Bulk  N: Normal  E: Expedited
>
> Links:
> null [/dev/null dtn:none ALWAYSON null state=OPEN]
> opportunistic-0 [192.168.0.17:42209 dtn://d3.dtn OPPORTUNISTIC tcp  
> state=OPEN]
> link_dtn://d3.dtn192.168.0.17 [192.168.0.17:4556 dtn:none ONDEMAND  
> tcp state=AVAILABLE]
> link_dtn://d4.dtn10.0.0.9 [10.0.0.9:4556 dtn:none ONDEMAND tcp  
> state=UNAVAILABLE]
> opportunistic-1 [10.0.0.9:37717 dtn://d4.dtn OPPORTUNISTIC tcp  
> state=UNAVAILABLE]
>
>
>
> At this point I would expect the bundle on D2 to be forwarded back  
> to D3 (the bundle source), then to D4, and finally be delivered to  
> its destination on D5.  However, the bundle never leaves D2 and  
> eventually expires.
>
> The bundle information:
>
>
>
> bundle id 4382:
>            source: dtn://d3.dtn/dtncp/send?source=43
>              dest: dtn://d5.dtn/dtncp/recv?file=/dtncp.temp87
>         custodian: dtn:none
>           replyto: dtn:none
>           prevhop: dtn://d3.dtn
>    payload_length: 619
>          priority: 2
> custody_requested: false
>     local_custody: false
>    singleton_dest: true
>      receive_rcpt: false
>      custody_rcpt: false
>      forward_rcpt: false
>     delivery_rcpt: true
>     deletion_rcpt: false
>    app_acked_rcpt: false
>       creation_ts: 259801915.3080
>        expiration: 900
>       is_fragment: false
>          is_admin: false
>   do_not_fragment: false
>       orig_length: 0
>       frag_offset: 0
>
> forwarding log:
>        TRANSMIT_PENDING -> link_dtn://d4.dtn10.0.0.9 [dtn:none]  
> FORWARD at 1206486492.242425 [custody min 1800 pct 25 max 0]
>
> queued on 1 lists:
>        pending_bundles
>
>
>
> Is this expected behavior?  I appreciate your help.
>
> Thanks,
> Brian
>
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users

Content-class: urn:content-classes:message
Date: Tue, 25 Mar 2008 17:47:05 -0700
From: "Smith, Brian J" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-users] Problem with Bundle Forwarding
Reply-To: dtn-users mailing list <[email-masked]>

I have a four node DTN Network -- laptops with hostnames D2, D3, D4, and D5.  All of the nodes have a DTN Daemon running on them.  Three of the nodes - D2, D3, and D4 - have two network interface cards installed.  I am modifying the DTN routes and links at runtime via a socket connection to the DTN Daemon.  I have the DTN routes and links set up on all the nodes so that my begining network looks like this: 

D5 <--> D4 <--> D2 <--> D3

If I do a "route dump" command on the D2 DTN Daemon:

Route table for static router:

destination        source COS    next hop         fwd    route [custody timeout]
endpoint id         eid   BNE    link/eid        action   prio [min   pct   max]
--------------------------------------------------------------------------------
----------
dtn://d3.dtn/* *:*    111 -> link_dtn... [0] FORWARD     0 [1800   25     0]
dtn://d4.dtn/* *:*    111 -> link_dtn... [1] FORWARD     0 [1800   25     0]
dtn://d5.dtn/* *:*    111 -> link_dtn... [1] FORWARD     0 [1800   25     0]
dtn://d3.dtn/* *:*    111 -> opportunistic-0 FORWARD     0 [1800   25     0]
dtn://d4.dtn/* *:*    111 -> opportunistic-1 FORWARD     0 [1800   25     0]

Long EIDs/Links referenced above:
        [0]: link_dtn://d3.dtn192.168.0.17
        [1]: link_dtn://d4.dtn10.0.0.9

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

Links:
null [/dev/null dtn:none ALWAYSON null state=OPEN]
opportunistic-0 [192.168.0.17:42209 dtn://d3.dtn OPPORTUNISTIC tcp state=OPEN]
link_dtn://d3.dtn192.168.0.17 [192.168.0.17:4556 dtn:none ONDEMAND tcp state=AVAILABLE]
link_dtn://d4.dtn10.0.0.9 [10.0.0.9:4556 dtn:none ONDEMAND tcp state=AVAILABLE]
opportunistic-1 [10.0.0.9:37717 dtn://d4.dtn OPPORTUNISTIC tcp state=OPEN]

I am able to send bundles to and from each of the nodes without any problems.  I then physically disconnect the link between D2 and D4, but there is delay before the routes and links in the DTN Daemon are changed to reflect the network topology change.  Before the routes and links programmed in the DTN Daemon are updated to reflect the changed network topology, I send a bundle from D3 to D5.  The bundle is forwarded to D2, but since the physical link between D2 and D4 has been broken, the bundle stays on D2.  I then physically connect D3 to D4 and update the routes and links on the DTN Daemons accordingly.  So my network now looks like this (D2 and D3 have essentially swapped positions in the network):

D5 <--> D4 <--> D3 <--> D2

If I again do a "route dump" command on the D2 DTN Daemon:

Route table for static router:

destination        source COS    next hop         fwd    route [custody timeout]
endpoint id         eid   BNE    link/eid        action   prio [min   pct   max]
--------------------------------------------------------------------------------
----------
dtn://d3.dtn/* *:*    111 -> link_dtn... [0] FORWARD     0 [1800   25     0]
dtn://d4.dtn/* *:*    111 -> link_dtn... [0] FORWARD     0 [1800   25     0]
dtn://d5.dtn/* *:*    111 -> link_dtn... [0] FORWARD     0 [1800   25     0]

Long EIDs/Links referenced above:
        [0]: link_dtn://d3.dtn192.168.0.17

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

Links:
null [/dev/null dtn:none ALWAYSON null state=OPEN]
opportunistic-0 [192.168.0.17:42209 dtn://d3.dtn OPPORTUNISTIC tcp state=OPEN]
link_dtn://d3.dtn192.168.0.17 [192.168.0.17:4556 dtn:none ONDEMAND tcp state=AVAILABLE]
link_dtn://d4.dtn10.0.0.9 [10.0.0.9:4556 dtn:none ONDEMAND tcp state=UNAVAILABLE]
opportunistic-1 [10.0.0.9:37717 dtn://d4.dtn OPPORTUNISTIC tcp state=UNAVAILABLE]

At this point I would expect the bundle on D2 to be forwarded back to D3 (the bundle source), then to D4, and finally be delivered to its destination on D5.  However, the bundle never leaves D2 and eventually expires.  

The bundle information:

bundle id 4382:
            source: dtn://d3.dtn/dtncp/send?source=43
              dest: dtn://d5.dtn/dtncp/recv?file=/dtncp.temp87
         custodian: dtn:none
           replyto: dtn:none
           prevhop: dtn://d3.dtn
    payload_length: 619
          priority: 2
 custody_requested: false
     local_custody: false
    singleton_dest: true
      receive_rcpt: false
      custody_rcpt: false
      forward_rcpt: false
     delivery_rcpt: true
     deletion_rcpt: false
    app_acked_rcpt: false
       creation_ts: 259801915.3080
        expiration: 900
       is_fragment: false
          is_admin: false
   do_not_fragment: false
       orig_length: 0
       frag_offset: 0

forwarding log:
        TRANSMIT_PENDING -> link_dtn://d4.dtn10.0.0.9 [dtn:none] FORWARD at 1206486492.242425 [custody min 1800 pct 25 max 0]

queued on 1 lists:
        pending_bundles

Is this expected behavior?  I appreciate your help.

Thanks,
Brian

From: Michael Demmer <[email-masked]>
To: dtn-users mailing list <[email-masked]>
Date: Mon, 24 Mar 2008 08:28:17 -0700
Subject: Re: [dtn-users] dtnrecv fails for larger files ?
Reply-To: dtn-users mailing list <[email-masked]>

Hi Gautam,

Oops -- I inadvertently broke in-memory delivery with that change.

I just committed and uploaded a fix to the mercurial repository. If  
you update and rebuild things should work better now.

-mike

On Mar 23, 2008, at 8:19 PM, Gautam Thaker wrote:
> Michael Demmer wrote:
>> I also just uploaded a patch to the mercurial repository that removes
>> this limitation, so there's now no maximum on the size of bundles  
>> that
>> can be returned in memory from dtn_recv.
>>
>> Note that the RPC protocol will still pass data from dtnd to the
>> application using files, it's just that the API implementation will
>> detect this situation and read the file data into memory before
>> returning to the application.
>>
>> -mike
>
> Hello Mike:
>
> I just built from "mercurial" repos (my first time but I think it  
> has all
> built ok.) My test now seems to run ok, but i get an error message:
>
> in recv window:
>
>
>
> b> dtnrecv -n 10 -q dtn://b.dtn/dest
> dtnrecv (pid 2781) starting up -- count 10
> find registration succeeded, regid 0
> register succeeded, regid 12
> looping to receive 10 bundles
> dtnrecv (pid 2781) exiting: 10 bundles received, 655360 total bytes
>
>
> in sending window:
>
> a> dtnsend -D  -w -n 10  -s dtn://a.dtn/stag2 -d dtn://b.dtn/dest -t  
> f -p
> file.65536
> DTN API internal error opening payload file: Bad address
> got 31 byte report from [dtn://b.dtn]: time=24.0 ms
> DTN API internal error opening payload file: Bad address
> got 31 byte report from [dtn://b.dtn]: time=50.7 ms
> DTN API internal error opening payload file: Bad address
> got 31 byte report from [dtn://b.dtn]: time=21.1 ms
> DTN API internal error opening payload file: Bad address
> got 31 byte report from [dtn://b.dtn]: time=66.3 ms
> DTN API internal error opening payload file: Bad address
> got 31 byte report from [dtn://b.dtn]: time=23.8 ms
> DTN API internal error opening payload file: Bad address
> got 31 byte report from [dtn://b.dtn]: time=36.0 ms
> DTN API internal error opening payload file: Bad address
> got 31 byte report from [dtn://b.dtn]: time=41.9 ms
> DTN API internal error opening payload file: Bad address
> got 31 byte report from [dtn://b.dtn]: time=60.0 ms
> DTN API internal error opening payload file: Bad address
> got 31 byte report from [dtn://b.dtn]: time=48.0 ms
> DTN API internal error opening payload file: Bad address
> got 31 byte report from [dtn://b.dtn]: time=35.9 ms
>
>
> ANY HINTS?
>
> Thanks.
>
> Gautam
>
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users

Date: Sun, 23 Mar 2008 23:19:10 -0400
From: Gautam Thaker <[email-masked]>
To: dtn-users mailing list <[email-masked]>
Subject: Re: [dtn-users] dtnrecv fails for larger files ?
Reply-To: dtn-users mailing list <[email-masked]>

Michael Demmer wrote:
> I also just uploaded a patch to the mercurial repository that removes  
> this limitation, so there's now no maximum on the size of bundles that  
> can be returned in memory from dtn_recv.
> 
> Note that the RPC protocol will still pass data from dtnd to the  
> application using files, it's just that the API implementation will  
> detect this situation and read the file data into memory before  
> returning to the application.
> 
> -mike

Hello Mike:

I just built from "mercurial" repos (my first time but I think it has all 
built ok.) My test now seems to run ok, but i get an error message:

in recv window:

b> dtnrecv -n 10 -q dtn://b.dtn/dest
dtnrecv (pid 2781) starting up -- count 10
find registration succeeded, regid 0
register succeeded, regid 12
looping to receive 10 bundles
dtnrecv (pid 2781) exiting: 10 bundles received, 655360 total bytes

in sending window:

a> dtnsend -D  -w -n 10  -s dtn://a.dtn/stag2 -d dtn://b.dtn/dest -t f -p 
file.65536
DTN API internal error opening payload file: Bad address
got 31 byte report from [dtn://b.dtn]: time=24.0 ms
DTN API internal error opening payload file: Bad address
got 31 byte report from [dtn://b.dtn]: time=50.7 ms
DTN API internal error opening payload file: Bad address
got 31 byte report from [dtn://b.dtn]: time=21.1 ms
DTN API internal error opening payload file: Bad address
got 31 byte report from [dtn://b.dtn]: time=66.3 ms
DTN API internal error opening payload file: Bad address
got 31 byte report from [dtn://b.dtn]: time=23.8 ms
DTN API internal error opening payload file: Bad address
got 31 byte report from [dtn://b.dtn]: time=36.0 ms
DTN API internal error opening payload file: Bad address
got 31 byte report from [dtn://b.dtn]: time=41.9 ms
DTN API internal error opening payload file: Bad address
got 31 byte report from [dtn://b.dtn]: time=60.0 ms
DTN API internal error opening payload file: Bad address
got 31 byte report from [dtn://b.dtn]: time=48.0 ms
DTN API internal error opening payload file: Bad address
got 31 byte report from [dtn://b.dtn]: time=35.9 ms

ANY HINTS?

Thanks.

Gautam

Date: Wed, 19 Mar 2008 16:29:48 -0700
From: Anuj Agarwal <[email-masked]>
To: dtn-users mailing list <[email-masked]>
Priority: normal
Subject: Re: [dtn-users] dtnrecv fails for larger files ?
Reply-To: dtn-users mailing list <[email-masked]>

Thanks a lot Jason and Mike for the prompt replies,

Thanks,
-Anuj.

----- Original Message -----
From: Michael Demmer <[email-masked]>
Date: Wednesday, March 19, 2008 3:39 pm
Subject: Re: [dtn-users] dtnrecv fails for larger files ?
To: dtn-users mailing list <[email-masked]>

> 
> I also just uploaded a patch to the mercurial repository that 
> removes  
> this limitation, so there's now no maximum on the size of bundles 
> that  
> can be returned in memory from dtn_recv.
> 
> Note that the RPC protocol will still pass data from dtnd to the  
> application using files, it's just that the API implementation will 
> 
> detect this situation and read the file data into memory before  
> returning to the application.
> 
> -mike
> 
> 
> On Mar 19, 2008, at 1:32 PM, Andresen, Jason R. wrote:
> > Try using the -o option to dtnrecv.  dtnrecv defaults to memory mode
> > transfers, which cannot be larger than 50k.  -o switches the API 
> into> using file mode transfers.
> >
> > A better solution is to use dtncp and dtncpd to transfer files  
> > instead.
> >
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of Anuj  
> >> Agarwal
> >> Sent: Tuesday, March 18, 2008 10:44 PM
> >> To: [email-masked]
> >> Subject: [dtn-users] dtnrecv fails for larger files ?
> >>
> >> Hi,
> >>
> >> Im quite new to dtn, and I was going through the tutorials. I
> >> tried the dtnsend and dtnrecv applications
> >> for a large file (on a dtn comprising of a single node) and I
> >> get the following error message on doing a dtn recv:
> >>
> >> ./dtnrecv dtn://localhost6.localdomain6.dtn/testing
> >> dtnrecv (pid 16457) starting up
> >> find registration succeeded, regid 0
> >> register succeeded, regid 18
> >> looping forever to receive bundles
> >> dtn_recv [dtn://localhost6.localdomain6.dtn/testing]...
> >> error getting recv reply: -1 (error in xdr routines)
> >>
> >> The dtnd window throws the following error:
> >>
> >> localhost6 dtn% [1205892054.736532 /dtn/apiclient/26 error]
> >> internal error in xdr: xdr_dtn_bundle_payload_t
> >>
> >> On doing a bundle list where dtnd is running, I can see the
> >> following pending bundle:
> >>
> >> Currently Pending Bundles (1):
> >>       31 : dtn://localhost6.localdomain6.dtn/me ->
> >> dtn://localhost6.localdomain6.dtn/testing length 7498588
> >>
> >> ---
> >>
> >> Am I missing something ? The apps seem to work fine for smaller 
> files>> Im not sure but is this  because of the DTN_MAX_BUNDLE_MEM 
> limit?>>
> >> Please advise,
> >> Thanks ,
> >> -Anuj.
> >> _______________________________________________
> >> dtn-users mailing list
> >> [email-masked]
> >> http://maillists.intel-research.net/mailman/listinfo/dtn-users
> >>
> >
> > _______________________________________________
> > dtn-users mailing list
> > [email-masked]
> > http://maillists.intel-research.net/mailman/listinfo/dtn-users
> 
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users
> 

From: Michael Demmer <[email-masked]>
To: dtn-users mailing list <[email-masked]>
Date: Wed, 19 Mar 2008 15:37:14 -0700
Subject: Re: [dtn-users] dtnrecv fails for larger files ?
Reply-To: dtn-users mailing list <[email-masked]>

I also just uploaded a patch to the mercurial repository that removes  
this limitation, so there's now no maximum on the size of bundles that  
can be returned in memory from dtn_recv.

Note that the RPC protocol will still pass data from dtnd to the  
application using files, it's just that the API implementation will  
detect this situation and read the file data into memory before  
returning to the application.

-mike

On Mar 19, 2008, at 1:32 PM, Andresen, Jason R. wrote:
> Try using the -o option to dtnrecv.  dtnrecv defaults to memory mode
> transfers, which cannot be larger than 50k.  -o switches the API into
> using file mode transfers.
>
> A better solution is to use dtncp and dtncpd to transfer files  
> instead.
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Anuj  
>> Agarwal
>> Sent: Tuesday, March 18, 2008 10:44 PM
>> To: [email-masked]
>> Subject: [dtn-users] dtnrecv fails for larger files ?
>>
>> Hi,
>>
>> Im quite new to dtn, and I was going through the tutorials. I
>> tried the dtnsend and dtnrecv applications
>> for a large file (on a dtn comprising of a single node) and I
>> get the following error message on doing a dtn recv:
>>
>> ./dtnrecv dtn://localhost6.localdomain6.dtn/testing
>> dtnrecv (pid 16457) starting up
>> find registration succeeded, regid 0
>> register succeeded, regid 18
>> looping forever to receive bundles
>> dtn_recv [dtn://localhost6.localdomain6.dtn/testing]...
>> error getting recv reply: -1 (error in xdr routines)
>>
>> The dtnd window throws the following error:
>>
>> localhost6 dtn% [1205892054.736532 /dtn/apiclient/26 error]
>> internal error in xdr: xdr_dtn_bundle_payload_t
>>
>> On doing a bundle list where dtnd is running, I can see the
>> following pending bundle:
>>
>> Currently Pending Bundles (1):
>>       31 : dtn://localhost6.localdomain6.dtn/me ->
>> dtn://localhost6.localdomain6.dtn/testing length 7498588
>>
>> ---
>>
>> Am I missing something ? The apps seem to work fine for smaller files
>> Im not sure but is this  because of the DTN_MAX_BUNDLE_MEM limit?
>>
>> Please advise,
>> Thanks ,
>> -Anuj.
>> _______________________________________________
>> dtn-users mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>>
>
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users

Content-class: urn:content-classes:message
Date: Wed, 19 Mar 2008 16:32:59 -0400
From: "Andresen, Jason R." <[email-masked]>
To: "dtn-users mailing list" <[email-masked]>
Subject: Re: [dtn-users] dtnrecv fails for larger files ?
Reply-To: dtn-users mailing list <[email-masked]>

Try using the -o option to dtnrecv.  dtnrecv defaults to memory mode
transfers, which cannot be larger than 50k.  -o switches the API into
using file mode transfers.  

A better solution is to use dtncp and dtncpd to transfer files instead.

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Anuj Agarwal
>Sent: Tuesday, March 18, 2008 10:44 PM
>To: [email-masked]
>Subject: [dtn-users] dtnrecv fails for larger files ?
>
>Hi,
>
>Im quite new to dtn, and I was going through the tutorials. I 
>tried the dtnsend and dtnrecv applications 
>for a large file (on a dtn comprising of a single node) and I 
>get the following error message on doing a dtn recv:
>
>./dtnrecv dtn://localhost6.localdomain6.dtn/testing
>dtnrecv (pid 16457) starting up
>find registration succeeded, regid 0
>register succeeded, regid 18
>looping forever to receive bundles
>dtn_recv [dtn://localhost6.localdomain6.dtn/testing]...
>error getting recv reply: -1 (error in xdr routines)
>
>The dtnd window throws the following error:
>
>localhost6 dtn% [1205892054.736532 /dtn/apiclient/26 error] 
>internal error in xdr: xdr_dtn_bundle_payload_t
>
>On doing a bundle list where dtnd is running, I can see the 
>following pending bundle:
>
>Currently Pending Bundles (1): 
>        31 : dtn://localhost6.localdomain6.dtn/me -> 
>dtn://localhost6.localdomain6.dtn/testing length 7498588
>
>--- 
>
>Am I missing something ? The apps seem to work fine for smaller files
>Im not sure but is this  because of the DTN_MAX_BUNDLE_MEM limit?
>
>Please advise,
>Thanks ,
>-Anuj.
>_______________________________________________
>dtn-users mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-users
>

Date: Tue, 18 Mar 2008 23:41:47 -0400
From: Gautam Thaker <[email-masked]>
To: [email-masked]
Cc: "'Gautam H Thaker \(LM ATL\)'" <[email-masked]>
Subject: [dtn-users] having trouble sending 64Kbyte file bundles on Fedora 8 system w/ Berkeley DB
Reply-To: dtn-users mailing list <[email-masked]>

Hi:

I am new to DTN and have been playing w/ the code by running few samples. I 
have been following the tutorials. I am up to sending and receiving bundles 
using "dtnsend" and "dtnrecv". Everything has worked well for me up to this 
point. I am able to send files of 256 bytes ok, and I am able to send 4096 
bytes files OK, but I am unable to send 64Kbyte files.

dtnsend -D -w -n 10 -s dtn://a.dtn/src -d dtn://b.dtn/dest -t f -p file.256
# works ok.

dtnsend -D  -w -n 10 -s dtn://a.dtn/src -d dtn://b.dtn/dest -t f -p file.4096
# works ok.

dtnsend -D  -w -n 10 -s dtn://a.dtn/src -d dtn://b.dtn/dest -t f -p file.65536
# Does not finish. I see in the window where I am running "dtnrecv":

# when 256 byte file was sent, worked ok:
b> ./dtnrecv -n 10 -q dtn://b.dtn/dest
dtnrecv (pid 9861) starting up -- count 10
find registration succeeded, regid 11
binding to regid 11
looping to receive 10 bundles
dtnrecv (pid 9861) exiting: 10 bundles received, 2560 total bytes

# when 1024 byte file was sent, worked ok:
b> ./dtnrecv -n 10 -q dtn://b.dtn/dest
dtnrecv (pid 9863) starting up -- count 10
find registration succeeded, regid 11
binding to regid 11
looping to receive 10 bundles
dtnrecv (pid 9863) exiting: 10 bundles received, 40960 total bytes

# when 64Kbyte file was sent, it died w/ this error:
b> ./dtnrecv -n 10 -q dtn://b.dtn/dest
dtnrecv (pid 9865) starting up -- count 10
find registration succeeded, regid 0
register succeeded, regid 12
looping to receive 10 bundles
error getting recv reply: -1 (error in xdr routines)

doing a "bundle list" on node "b" one sees:
b dtn% bundle list
Currently Pending Bundles (1):
         80 : dtn://a.dtn/src -> dtn://b.dtn/dest length 65536

When the error occurs, the node "b" (the receiver node)'s dtnd says:
b dtn% [1205897780.072995 /dtn/apiclient/19 error] internal error in xdr: 
xdr_dtn_bundle_payload_t

It appears one bundle, the last one, did not come thru. If I expire this by 
manually i can again send bundles of 256bytes and 4K bytes, but  sending 
64Kbytes fails again. I even wiped up /var/dtn (where databases are) and 
started again, same thing.

Any hints or pointers welcome. Thanks.

Gautam Thaker
[email-masked]

Date: Tue, 18 Mar 2008 19:43:55 -0700
From: Anuj Agarwal <[email-masked]>
To: [email-masked]
Priority: normal
Subject: [dtn-users] dtnrecv fails for larger files ?
Reply-To: dtn-users mailing list <[email-masked]>

Hi,

Im quite new to dtn, and I was going through the tutorials. I tried the dtnsend and dtnrecv applications 
for a large file (on a dtn comprising of a single node) and I get the following error message on doing a dtn recv:

./dtnrecv dtn://localhost6.localdomain6.dtn/testing
dtnrecv (pid 16457) starting up
find registration succeeded, regid 0
register succeeded, regid 18
looping forever to receive bundles
dtn_recv [dtn://localhost6.localdomain6.dtn/testing]...
error getting recv reply: -1 (error in xdr routines)

The dtnd window throws the following error:

localhost6 dtn% [1205892054.736532 /dtn/apiclient/26 error] internal error in xdr: xdr_dtn_bundle_payload_t

On doing a bundle list where dtnd is running, I can see the following pending bundle:

Currently Pending Bundles (1): 
        31 : dtn://localhost6.localdomain6.dtn/me -> dtn://localhost6.localdomain6.dtn/testing length 7498588

--- 

Am I missing something ? The apps seem to work fine for smaller files
Im not sure but is this  because of the DTN_MAX_BUNDLE_MEM limit?

Please advise,
Thanks ,
-Anuj.

From: Michael Demmer <[email-masked]>
To: dtn-users mailing list <[email-masked]>
Date: Mon, 17 Mar 2008 07:28:42 -0700
Subject: Re: [dtn-users] issues on Prophet
Reply-To: dtn-users mailing list <[email-masked]>

Just as a heads up, Lindgren and Doria recently published an updated  
Internet Draft under the auspices of the DTNRG:

http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-prophet-00.txt

For those of you who are close to the implementation, it would be good  
if you could go through the draft and make sure both that the  
implementation matches the spec, as well as forwarding any necessary  
changes to the spec to those authors.

-mike

On Mar 16, 2008, at 12:26 PM, Jeff Wilson wrote:

> Peng,
>
> Thanks for all the effort that went into this debug.  And many thanks
> for sharing your findings!!  I'm curious to see more details on #3 and
> #6.
>
> As for #5, since it is a departure from the algorithm as published in
> the March 2006 Prophet draft, make sure to contact Lindgren and Doria
> so they can update future versions of their draft with the corrected
> algorithm as well.
>
>    Regards,
>    Jeff
>
> On Thu, Mar 13, 2008 at 11:14 PM, Peng Yang <[email-masked]> wrote:
>> Hi Jeff,
>>
>> We have been using Prophet for some time.  Certain issues have been  
>> found,
>> and their possible solutions are as follows.  Any comments are  
>> welcomed.  We
>> are developing a patch to the most recent DTNRG release.
>>
>> 1. servlib/prophet/AckList.cc
>>
>> Problem: the prophet router processing is trapped within the loop of
>> checking the acknowlegement list because the forward loop pointer  
>> is not
>> incremented. I noticed that this bug has been fixed in the latest  
>> DTNRG
>> release.
>>
>> Solution:
>>
>> In prophet::AckList::is_ackd()
>>
>>  // all parameters match?
>>
>>         if ((*i)->cts() == cts && (*i)->seq() == seq)
>>
>>             return true;
>>
>>       i++; // this line added to break the loop
>>
>>     }
>>
>>     // not found, therefore must not be Ack'd
>>
>>     return false;
>>
>>
>>
>> 2. servlib/prophet/Decider.cc
>>
>> Problem: for control bundles, there is a service tag at the end of  
>> the
>> destination eid(e.g. dtn://hostname.dtn/prophet where "/prophet" is  
>> the
>> service tag). The current software cannot parse this so the
>> p_value(dest_eid) will always return 0.
>>
>> Solution: we invoke get_route() routine to remove the service tag  
>> in the
>> eid(e.g. change dtn://hostname.dtn/prophet to dtn://hostname.dtn).
>>
>>
>>
>> in bool  FwdDeciderGRTR::operator()(const Bundle* b) const
>>
>>    std::string dest_eid=core_->get_route(b->destination_id()); //  
>> this line
>> is added to fix the problem
>>
>>     // forward if remote's predictability is greater that local's
>>
>>     // if (local_->p_value(b) < remote_->p_value(b)) // this line is
>> removed
>>
>>  if (local_->p_value(dest_eid) < remote_->p_value(dest_eid)) //  
>> this line
>> is added
>>
>>     {
>>
>>         LOG("ok to fwd: %s is better route for bundle %s %u:%u "
>>
>>             "(%.2f > %.2f)",
>> next_hop_->remote_eid(),b->destination_id().c_str(),
>>
>> 3. File transfer doesn't work with the original prophet because of  
>> the
>> presence of the service tag after "?" mark in the destination eid.  
>> The bug
>> is removed by a routine similar to get_route() routine to remove  
>> the service
>> tag "?".
>>
>>
>> 4.Considering a simple network consisting of three hosts: A, B and  
>> C, the
>> topology is A--B--C.
>> Since node C is node B's direct neighbor, initially node B includes  
>> P(B,C)
>> in prophet bundle and sends it out to A. Node A updates P(A,C) on  
>> receiving
>> P(B,C) from node B. After that, node A includes P(A,C) in the  
>> prophet bundle
>> and sends it out to node B. When node B receives the prophet bundle  
>> from A
>> which includes P(A,C), it updates P(B,C) as follows:
>> P(B,C) = P(B,C)_old + (1 - P(B,C)_old) * P(B,A) * P(A,C) * beta
>> A loop(C--B--A--B) exists in the delivery predictability  
>> calculation, the
>> loop keeps on reducing the value of P(B,C) and P(A,C).
>>
>>
>> Solution: To prevent looping, B will not update P(B,C) transitively  
>> unless
>> P(B,C) < P(A,C).
>>
>> servlib/prophet/Node.cc
>> in Node::update_transitive()
>> void Node::update_transitive(double ab, double bc)
>>
>> {
>>
>>    // validate before proceeding
>>
>>    if (!(p_value_ >= 0.0 && p_value_ <= 1.0)) return;
>>
>>    if (!(ab >= 0.0 && ab <= 1.0)) return;
>>
>>    if (!(bc >= 0.0 && bc <= 1.0)) return;
>>
>>    if (params_ == NULL) return;
>>
>>    if(p_value_>bc)  return; // this line is added
>>
>>
>> 5. Problem: the transitivity equation is not quite correct and can  
>> cause the
>> Prophet to pick a non-optimal route and sometimes even a route that  
>> can
>> cause a loop. Considering a simple network consisting of three  
>> hosts: A, B
>> and C, the topology is A--B--C. P(A,C) will be close to 1 after the  
>> route
>> A--B--C lasts for a certain time. Then, if the link B--C is broken
>> temporally, P(B,C) will age and P(A,C) will also decrease when it  
>> updates
>> transitively. But P(A,C) will decrease much slower than P(B,C)  
>> since the
>> transitivity equation gives more weight to the old P(A,C) value. As a
>> result, P(A,C) will be greater than P(B,C) and node B will choose  
>> node A as
>> the next hop to node C.
>>
>> Solution: servlib/prophet/Node.cc
>>
>> in Node::update_transitive()
>>
>>     // new p_value_ is P_(A,C), previous p_value is P_(A,C)_old
>>
>>     // params_->beta_ is beta
>>
>>     // A is the local node
>>
>>     // B is the node just encountered (originator of RIB)
>>
>>     // C is the node represented by this ProphetNode instance
>>
>>      p_value_ = p_value_ + (1.0 - p_value_) * ab * bc * params_- 
>> >beta_; //
>> this line is removed
>>
>>   p_value_=p_value_*params_->beta_+(1-params_->beta_)*ab*bc*
>> params_->encounter_; // this line is added
>>
>> 6. Current prophet router can handle pending application bundles  
>> but not
>> pending routing control bundles. Once the control bundle gets stuck  
>> at the
>> prophet router, the prophet router doesn't work. New functions are  
>> added to
>> handle pending control bundles as well as pending application  
>> bundles.
>>
>>
>>
>> 7.  in servlib/cmd/ProphetCommand.cc
>>
>>
>> Assign value to ProphetRouter::params_.fs_ after calling
>> p.parse(argc,argv,&invalid) to read the configuration.
>>
>>
>> Int ProphetCommand::exec(int argc, const char** argv, Tcl_Interp*  
>> interp)
>> {
>>
>> if (! p.parse(argc,argv,&invalid))
>>
>>        {
>>
>>            resultf("bad parameter for fwd_strategy: %s",invalid);
>>
>>            return TCL_ERROR;
>>
>>        }
>>
>>       ProphetRouter::params_.fs_ =
>>
>>            (prophet::FwdStrategy::fwd_strategy_t)fs_pass;
>>
>> }
>> Peng
>> _______________________________________________
>> dtn-users mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>>
>>
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users

Date: Sun, 16 Mar 2008 14:26:02 -0500
From: "Jeff Wilson" <[email-masked]>
Sender: [email-masked]
To: "dtn-users mailing list" <[email-masked]>
Subject: Re: [dtn-users] issues on Prophet
Reply-To: dtn-users mailing list <[email-masked]>

Peng,

Thanks for all the effort that went into this debug.  And many thanks
for sharing your findings!!  I'm curious to see more details on #3 and
#6.

As for #5, since it is a departure from the algorithm as published in
the March 2006 Prophet draft, make sure to contact Lindgren and Doria
so they can update future versions of their draft with the corrected
algorithm as well.

    Regards,
    Jeff

On Thu, Mar 13, 2008 at 11:14 PM, Peng Yang <[email-masked]> wrote:
> Hi Jeff,
>
> We have been using Prophet for some time.  Certain issues have been found,
> and their possible solutions are as follows.  Any comments are welcomed.  We
> are developing a patch to the most recent DTNRG release.
>
>  1. servlib/prophet/AckList.cc
>
> Problem: the prophet router processing is trapped within the loop of
> checking the acknowlegement list because the forward loop pointer is not
> incremented. I noticed that this bug has been fixed in the latest DTNRG
> release.
>
>  Solution:
>
> In prophet::AckList::is_ackd()
>
>   // all parameters match?
>
>          if ((*i)->cts() == cts && (*i)->seq() == seq)
>
>              return true;
>
>        i++; // this line added to break the loop
>
>      }
>
>      // not found, therefore must not be Ack'd
>
>      return false;
>
>
>
> 2. servlib/prophet/Decider.cc
>
> Problem: for control bundles, there is a service tag at the end of the
> destination eid(e.g. dtn://hostname.dtn/prophet where "/prophet" is the
> service tag). The current software cannot parse this so the
> p_value(dest_eid) will always return 0.
>
> Solution: we invoke get_route() routine to remove the service tag in the
> eid(e.g. change dtn://hostname.dtn/prophet to dtn://hostname.dtn).
>
>
>
> in bool  FwdDeciderGRTR::operator()(const Bundle* b) const
>
>     std::string dest_eid=core_->get_route(b->destination_id()); // this line
> is added to fix the problem
>
>      // forward if remote's predictability is greater that local's
>
>      // if (local_->p_value(b) < remote_->p_value(b)) // this line is
> removed
>
>   if (local_->p_value(dest_eid) < remote_->p_value(dest_eid)) // this line
> is added
>
>      {
>
>          LOG("ok to fwd: %s is better route for bundle %s %u:%u "
>
>              "(%.2f > %.2f)",
> next_hop_->remote_eid(),b->destination_id().c_str(),
>
> 3. File transfer doesn't work with the original prophet because of the
> presence of the service tag after "?" mark in the destination eid. The bug
> is removed by a routine similar to get_route() routine to remove the service
> tag "?".
>
>
> 4.Considering a simple network consisting of three hosts: A, B and C, the
> topology is A--B--C.
> Since node C is node B's direct neighbor, initially node B includes P(B,C)
> in prophet bundle and sends it out to A. Node A updates P(A,C) on receiving
> P(B,C) from node B. After that, node A includes P(A,C) in the prophet bundle
> and sends it out to node B. When node B receives the prophet bundle from A
> which includes P(A,C), it updates P(B,C) as follows:
> P(B,C) = P(B,C)_old + (1 - P(B,C)_old) * P(B,A) * P(A,C) * beta
> A loop(C--B--A--B) exists in the delivery predictability calculation, the
> loop keeps on reducing the value of P(B,C) and P(A,C).
>
>
> Solution: To prevent looping, B will not update P(B,C) transitively unless
> P(B,C) < P(A,C).
>
> servlib/prophet/Node.cc
> in Node::update_transitive()
> void Node::update_transitive(double ab, double bc)
>
> {
>
>     // validate before proceeding
>
>     if (!(p_value_ >= 0.0 && p_value_ <= 1.0)) return;
>
>     if (!(ab >= 0.0 && ab <= 1.0)) return;
>
>     if (!(bc >= 0.0 && bc <= 1.0)) return;
>
>     if (params_ == NULL) return;
>
>     if(p_value_>bc)  return; // this line is added
>
>
> 5. Problem: the transitivity equation is not quite correct and can cause the
> Prophet to pick a non-optimal route and sometimes even a route that can
> cause a loop. Considering a simple network consisting of three hosts: A, B
> and C, the topology is A--B--C. P(A,C) will be close to 1 after the route
> A--B--C lasts for a certain time. Then, if the link B--C is broken
> temporally, P(B,C) will age and P(A,C) will also decrease when it updates
> transitively. But P(A,C) will decrease much slower than P(B,C) since the
> transitivity equation gives more weight to the old P(A,C) value. As a
> result, P(A,C) will be greater than P(B,C) and node B will choose node A as
> the next hop to node C.
>
> Solution: servlib/prophet/Node.cc
>
> in Node::update_transitive()
>
>      // new p_value_ is P_(A,C), previous p_value is P_(A,C)_old
>
>      // params_->beta_ is beta
>
>      // A is the local node
>
>      // B is the node just encountered (originator of RIB)
>
>      // C is the node represented by this ProphetNode instance
>
>       p_value_ = p_value_ + (1.0 - p_value_) * ab * bc * params_->beta_; //
> this line is removed
>
>    p_value_=p_value_*params_->beta_+(1-params_->beta_)*ab*bc*
> params_->encounter_; // this line is added
>
> 6. Current prophet router can handle pending application bundles but not
> pending routing control bundles. Once the control bundle gets stuck at the
> prophet router, the prophet router doesn't work. New functions are added to
> handle pending control bundles as well as pending application bundles.
>
>
>
> 7.  in servlib/cmd/ProphetCommand.cc
>
>
> Assign value to ProphetRouter::params_.fs_ after calling
> p.parse(argc,argv,&invalid) to read the configuration.
>
>
> Int ProphetCommand::exec(int argc, const char** argv, Tcl_Interp* interp)
> {
>
>  if (! p.parse(argc,argv,&invalid))
>
>         {
>
>             resultf("bad parameter for fwd_strategy: %s",invalid);
>
>             return TCL_ERROR;
>
>         }
>
>        ProphetRouter::params_.fs_ =
>
>             (prophet::FwdStrategy::fwd_strategy_t)fs_pass;
>
> }
> Peng
> _______________________________________________
>  dtn-users mailing list
>  [email-masked]
>  http://maillists.intel-research.net/mailman/listinfo/dtn-users
>
>

From: Michael Demmer <[email-masked]>
To: dtn-users mailing list <[email-masked]>
Date: Sat, 15 Mar 2008 10:19:25 -0700
Subject: Re: [dtn-users] hg commit descriptions
Reply-To: dtn-users mailing list <[email-masked]>

Unfortunately not.

Mercurial changesets are uniquely identified by a hash of the diff and  
checkin metadata, so they can't be changed after they've been committed.

If you've just done the commit, you can back it out using 'hg  
rollback', but that's only usable for a single operation.

If that's not an option, save a copy of all your code, and use the 'hg  
strip' command to get rid of the changeset(s) and do it all again.

To do this, you may need to enable the 'mercurial queues' extension by  
putting the following into your ~/.hgrc:

[extensions]
hgext.mq=

Then you can run 'hg strip <revision>' which will remove the revision  
and all following revisions on the same branch (i.e. ones that depend  
on what you've just cut out).

Then reapply the diffs and re-do the checkin with the updated change  
log.

-mike

On Mar 15, 2008, at 9:59 AM, ryan m wrote:

> Is there a way to change the description you given for a particular
> commit that was a couple commits ago in hg?
>
> Thank you,
> Ryan
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users

Date: Sat, 15 Mar 2008 12:59:28 -0400
From: "ryan m" <[email-masked]>
To: "dtn-users mailing list" <[email-masked]>
Subject: [dtn-users] hg commit descriptions
Reply-To: dtn-users mailing list <[email-masked]>

Is there a way to change the description you given for a particular
commit that was a couple commits ago in hg?

Thank you,
Ryan

Date: Sat, 15 Mar 2008 12:59:21 -0400
From: "ryan m" <[email-masked]>
To: "dtn-users mailing list" <[email-masked]>
Subject: [dtn-users] hg commit descriptions
Reply-To: dtn-users mailing list <[email-masked]>

Is there a way to change the description you given for a particular
commit that was a couple commits ago in hg?

Thank you,
Ryan

Date: Fri, 14 Mar 2008 00:14:26 -0400
From: "Peng Yang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [dtn-users] issues on Prophet
Reply-To: dtn-users mailing list <[email-masked]>

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

Hi Jeff,

We have been using Prophet for some time.  Certain issues have been found,
and their possible solutions are as follows.  Any comments are welcomed.  We
are developing a patch to the most recent DTNRG release.

1. servlib/prophet/AckList.cc

Problem: the prophet router processing is trapped within the loop of
checking the acknowlegement list because the forward loop pointer is not
incremented. I noticed that this bug has been fixed in the latest DTNRG
release.

 Solution:

In prophet::AckList::is_ackd()

  // all parameters match?

         if ((*i)->cts() == cts && (*i)->seq() == seq)

             return true;

*       i++; // this line added to break the loop*

     }

     // not found, therefore must not be Ack'd

     return false;

2. servlib/prophet/Decider.cc

Problem: for control bundles, there is a service tag at the end of the
destination eid(e.g. dtn://hostname.dtn/prophet where "/prophet" is the
service tag). The current software cannot parse this so the
p_value(dest_eid) will always return 0.

Solution: we invoke get_route() routine to remove the service tag in the
eid(e.g. change dtn://hostname.dtn/prophet to dtn://hostname.dtn).

in bool  FwdDeciderGRTR::operator()(const Bundle* b) const

    *std::string dest_eid=core_->get_route(b->destination_id()); *// this
line is added to fix the problem

     // forward if remote's predictability is greater that local's

     // if (local_->p_value(b) < remote_->p_value(b)) // this line is
removed

*  if (local_->p_value(dest_eid) < remote_->p_value(dest_eid)) *// this line
is added

     {

         LOG("ok to fwd: %s is better route for bundle %s %u:%u "

             "(%.2f > %.2f)",
next_hop_->remote_eid(),b->destination_id().c_str(),

3. File transfer doesn't work with the original prophet because of the
presence of the service tag after "?" mark in the destination eid. The bug
is removed by a routine similar to get_route() routine to remove the service
tag "?".

4.Considering a simple network consisting of three hosts: A, B and C, the
topology is A--B--C.
Since node C is node B's direct neighbor, initially node B includes P(B,C)
in prophet bundle and sends it out to A. Node A updates P(A,C) on receiving
P(B,C) from node B. After that, node A includes P(A,C) in the prophet bundle
and sends it out to node B. When node B receives the prophet bundle from A
which includes P(A,C), it updates P(B,C) as follows:
P(B,C) = P(B,C)_old + (1 - P(B,C)_old) * P(B,A) * P(A,C) * beta
A loop(C--B--A--B) exists in the delivery predictability calculation, the
loop keeps on reducing the value of P(B,C) and P(A,C).

Solution: To prevent looping, B will not update P(B,C) transitively unless
P(B,C) < P(A,C).

servlib/prophet/Node.cc
in Node::update_transitive()
void Node::update_transitive(double ab, double bc)

{

    // validate before proceeding

    if (!(p_value_ >= 0.0 && p_value_ <= 1.0)) return;

    if (!(ab >= 0.0 && ab <= 1.0)) return;

    if (!(bc >= 0.0 && bc <= 1.0)) return;

    if (params_ == NULL) return;

*    if(p_value_>bc)  return; *// this line is added

5. Problem: the transitivity equation is not quite correct and can cause the
Prophet to pick a non-optimal route and sometimes even a route that can
cause a loop. Considering a simple network consisting of three hosts: A, B
and C, the topology is A--B--C. P(A,C) will be close to 1 after the route
A--B--C lasts for a certain time. Then, if the link B--C is broken
temporally, P(B,C) will age and P(A,C) will also decrease when it updates
transitively. But P(A,C) will decrease much slower than P(B,C) since the
transitivity equation gives more weight to the old P(A,C) value. As a
result, P(A,C) will be greater than P(B,C) and node B will choose node A as
the next hop to node C.

Solution: servlib/prophet/Node.cc

in Node::update_transitive()

     // new p_value_ is P_(A,C), previous p_value is P_(A,C)_old

     // params_->beta_ is beta

     // A is the local node

     // B is the node just encountered (originator of RIB)

     // C is the node represented by this ProphetNode instance

      p_value_ = p_value_ + (1.0 - p_value_) * ab * bc * params_->beta_; //
this line is removed

   *p_value_=p_value_*params_->beta_+(1-params_->beta_)*ab*bc*
params_->encounter_;* // this line is added

6. Current prophet router can handle pending application bundles but not
pending routing control bundles. Once the control bundle gets stuck at the
prophet router, the prophet router doesn't work. New functions are added to
handle pending control bundles as well as pending application bundles.

7.  in servlib/cmd/ProphetCommand.cc

Assign value to ProphetRouter::params_.fs_ *after *calling
p.parse(argc,argv,&invalid)
to read the configuration.

Int ProphetCommand::exec(int argc, const char** argv, Tcl_Interp* interp)
{

 if (! p.parse(argc,argv,&invalid))

        {

            resultf("bad parameter for fwd_strategy: %s",invalid);

            return TCL_ERROR;

        }

       ProphetRouter::params_.fs_ =

            (prophet::FwdStrategy::fwd_strategy_t)fs_pass;

}

Peng

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

Hi Jeff,<br><br>We have been using Prophet for some time. &nbsp;Certain issues have been found, and their possible solutions are as follows. &nbsp;Any comments are welcomed. &nbsp;We are developing a patch to the most recent DTNRG release.<p>

1. servlib/prophet/AckList.cc</p>

<p>Problem: the prophet router processing is trapped within the
loop of checking the acknowlegement list because the forward loop pointer is
not incremented. I noticed that this bug has been fixed in the latest DTNRG
release.</p>

<p>&nbsp;Solution:</p>

<p>In prophet::AckList::is_ackd()</p>

<p>&nbsp;<span> </span>// all parameters
match?</p>

<p><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>if
((*i)-&gt;cts() == cts &amp;&amp; (*i)-&gt;seq() == seq)</p>

<p><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>return
true;</p>

<p><b><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span>i++;</span>
// this line added to break the loop</b></p>

<p><span>&nbsp;&nbsp;&nbsp;&nbsp; </span>}</p>

<p><span>&nbsp;&nbsp;&nbsp;&nbsp; </span>// not found,
therefore must not be Ack&#39;d</p>

<p><span>&nbsp;&nbsp;&nbsp;&nbsp; </span>return false;</p>

<p>&nbsp;</p>

<p>2. servlib/prophet/Decider.cc</p>

<p>Problem: for control bundles, there is a service tag at the
end of the destination eid(e.g. dtn://hostname.dtn/prophet where &quot;/prophet&quot; is
the service tag). The current software cannot parse this so the p_value(dest_eid)
will always return 0. </p>

<p>Solution: we invoke get_route() routine to remove the
service tag in the eid(e.g. change dtn://hostname.dtn/prophet to
dtn://hostname.dtn). </p>

<p><span>&nbsp;</span></p>

<p>in bool<span>&nbsp;
</span>FwdDeciderGRTR::operator()(const Bundle* b) const</p>

<p><span>&nbsp;&nbsp;&nbsp; </span><b>std::string dest_eid=core_-&gt;get_route(b-&gt;destination_id());
</b>// this line is added to fix the problem</p>

<p><span>&nbsp;&nbsp;&nbsp;&nbsp; </span>// forward if
remote&#39;s predictability is greater that local&#39;s</p>

<p><span>&nbsp;&nbsp;&nbsp; </span><span>&nbsp;</span>// if (local_-&gt;p_value(b) &lt;
remote_-&gt;p_value(b)) // this line is removed</p>

<p><b><span>&nbsp; </span>if
(local_-&gt;p_value(dest_eid) &lt; remote_-&gt;p_value(dest_eid)) </b>// this
line is added</p>

<p><span>&nbsp;&nbsp;&nbsp;&nbsp; </span>{</p>

<p><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>LOG(&quot;ok
to fwd: %s is better route for bundle %s %u:%u &quot;</p>

<p><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>&quot;(%.2f &gt; %.2f)&quot;,
next_hop_-&gt;remote_eid(),b-&gt;destination_id().c_str(),</p>

<p>3. File transfer doesn&#39;t work with the original prophet
because of the presence of the service tag after &quot;?&quot; mark in the
destination eid. The bug is removed by a routine similar to get_route() routine
to remove the service tag &quot;?&quot;.<br></p>

<p>4.Considering a simple network consisting of three hosts: A,
B and C, the topology is A--B--C.<span>&nbsp;</span><br>Since node C is node B&#39;s direct neighbor, initially node B
includes P(B,C) in prophet bundle and sends it out to A. Node A updates P(A,C)
on receiving P(B,C) from node B. After that, node A includes P(A,C) in the
prophet bundle and sends it out to node B. When node B receives the prophet
bundle from A which includes P(A,C), it updates P(B,C) as follows:<br>P(B,C) = P(B,C)_old + (1 - P(B,C)_old) * P(B,A) * P(A,C) *
beta<br>A loop(C--B--A--B) exists in the delivery predictability
calculation, the loop keeps on reducing the value of P(B,C) and P(A,C).<br></p>

<p>Solution: To prevent looping, B will not update P(B,C)
transitively unless P(B,C) &lt; P(A,C).</p>

<p style="text-align: left;" align="left">servlib/prophet/Node.cc<br>in Node::update_transitive()<br><span style="font-size: 10pt;">void Node::update_transitive(double ab, double bc)</span></p>

<p style="text-align: left;" align="left"><span style="font-size: 10pt;">{</span></p>

<p style="text-align: left;" align="left"><span style="font-size: 10pt;"><span>&nbsp;&nbsp;&nbsp; </span>// validate
before proceeding</span></p>

<p style="text-align: left;" align="left"><span style="font-size: 10pt;"><span>&nbsp;&nbsp;&nbsp; </span>if (!(p_value_
&gt;= 0.0 &amp;&amp; p_value_ &lt;= 1.0)) return;</span></p>

<p style="text-align: left;" align="left"><span style="font-size: 10pt;"><span>&nbsp;&nbsp;&nbsp; </span>if (!(ab &gt;=
0.0 &amp;&amp; ab &lt;= 1.0)) return;</span></p>

<p style="text-align: left;" align="left"><span style="font-size: 10pt;"><span>&nbsp;&nbsp;&nbsp; </span>if (!(bc &gt;=
0.0 &amp;&amp; bc &lt;= 1.0)) return;</span></p>

<p style="text-align: left;" align="left"><span style="font-size: 10pt;"><span>&nbsp;&nbsp;&nbsp; </span>if (params_ ==
NULL) return;</span></p>

<p><b><span style="font-size: 10pt;">&nbsp;&nbsp;&nbsp; if(p_value_&gt;bc)<span>&nbsp; </span>return; </span></b><span style="font-size: 10pt;">// this line is added</span></p><p><br>5. Problem: the transitivity equation is not quite correct and
can cause the Prophet to pick a non-optimal route and sometimes even a route
that can cause a loop. Considering a simple network consisting of three hosts:
A, B and C, the topology is A--B--C. P(A,C) will be close to 1 after the route
A--B--C lasts for a certain time. Then, if the link B--C is broken temporally, P(B,C)
will age and P(A,C) will also decrease when it updates transitively. But P(A,C) will decrease much slower than P(B,C) since the transitivity equation gives more weight to the old P(A,C)
value. As a result, P(A,C) will be greater than P(B,C) and node B will choose node A
as the next hop to node C. </p>

<p>Solution: servlib/prophet/Node.cc</p>

<p>in Node::update_transitive()</p>

<p><span>&nbsp;&nbsp;&nbsp;&nbsp; </span>// new p_value_
is P_(A,C), previous p_value is P_(A,C)_old</p>

<p><span>&nbsp;&nbsp;&nbsp;&nbsp; </span>//
params_-&gt;beta_ is beta</p>

<p><span>&nbsp;&nbsp;&nbsp;&nbsp; </span>// A is the local
node</p>

<p><span>&nbsp;&nbsp; </span><span>&nbsp;&nbsp;</span>// B is the node just encountered (originator
of RIB)</p>

<p><span>&nbsp;&nbsp;&nbsp;&nbsp; </span>// C is the node
represented by this ProphetNode instance</p>

<p><span>&nbsp;&nbsp;&nbsp; </span><span>&nbsp;&nbsp;</span>p_value_ = p_value_ + (1.0 - p_value_) * ab *
bc * params_-&gt;beta_; // this line is removed</p>

<p><span>&nbsp; </span><span>&nbsp;</span><b>p_value_=p_value_*params_-&gt;beta_+(1-params_-&gt;beta_)*ab*bc*
params_-&gt;encounter_;</b> // this line is added</p>

<p>6. Current prophet router can handle pending application
bundles but not pending routing control bundles. Once the control bundle gets stuck at the prophet router, the prophet router doesn&#39;t work. New functions are added
to handle pending control bundles as well as pending application bundles. </p>

<p>&nbsp;</p>

<p style="text-align: left;" align="left">7.&nbsp; <span>in servlib/cmd/ProphetCommand.cc<br></span></p><p style="text-align: left;" align="left"><span></span>Assign value to ProphetRouter::params_.fs_
<b>after </b>calling p.parse(argc,argv,&amp;invalid) to read the configuration. <br> </p>

<p>Int ProphetCommand::exec(int argc, const char** argv,
Tcl_Interp* interp)<br>{</p>

<p><span>&nbsp;</span>if (!
p.parse(argc,argv,&amp;invalid))</p>

<p><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>{</p>

<p><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>resultf(&quot;bad parameter for fwd_strategy: %s&quot;,invalid);</p>

<p><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>return
TCL_ERROR;</p>

<p><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>}</p>

<p><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>ProphetRouter::params_.fs_
=</p>

<p><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>(prophet::FwdStrategy::fwd_strategy_t)fs_pass;</p>

<p>}</p>

<br>Peng

------=_Part_12856_17359062.1205468066915--

From: Michael Demmer <[email-masked]>
To: dtn-users mailing list <[email-masked]>
Date: Tue, 11 Mar 2008 10:20:00 -0700
Subject: Re: [dtn-users] trouble compiling DTN on Fedora Core 8
Reply-To: dtn-users mailing list <[email-masked]>

One other note, you can always configure --without-db if you're having  
trouble with BerkeleyDB specifically.

-mike

On Mar 11, 2008, at 6:13 AM, Gautam Thaker wrote:

> Hi:
>
> I am new to DTN but fairly experienced at building lots of open  
> source software. i am trying to build DTN-2.5 on Fedora Core 8  
> Linux. I have Berkeley DB 4.5 installed. I do:
>
> ./configure  --with-db=/home/gthaker/usr
>
> However, when building I get:
>
> checking for Berkeley DB header (version 4.5) in /home/gthaker/usr/ 
> include... yes
> checking for Berkeley DB library in /home/gthaker/usr/lib, - 
> ldb-4.5... no
> checking for Berkeley DB header (version 4.4) in /home/gthaker/usr/ 
> include... no
> checking for Berkeley DB header (version 4.3) in /home/gthaker/usr/ 
> include... no
> checking for Berkeley DB header (version 4.2) in /home/gthaker/usr/ 
> include... no
>
> Configure error with Berkeley DB...
>
> It find DB include files ok but not the lib. I have tried to look at  
> the "configure" file but it is some 12,000 lines long and I can find  
> where this error is "detected" but have not yet figured out what is  
> going on.
>
> In /home/gthaker/usr/lib I have:
>
> zadapi-L> pwd
> /home/gthaker/usr/lib
> zadapi-L> ls -lt *db*
> -rw-r--r-- 1 gthaker gthaker 1467492 Mar 10 21:54 libdb-4.5.a
> lrwxrwxrwx 1 gthaker gthaker      12 Mar 10 21:54 libdb-4.so ->  
> libdb-4.5.so
> -rw-r--r-- 1 gthaker gthaker 1467492 Mar 10 21:54 libdb.a
> lrwxrwxrwx 1 gthaker gthaker      12 Mar 10 21:54 libdb.so ->  
> libdb-4.5.so
> -rw-rw-r-- 1 gthaker gthaker     813 Mar 10 21:52 libdb-4.5.la
> -rwxrwxr-x 1 gthaker gthaker 1163035 Mar 10 21:52 libdb-4.5.so
>
>
> ANY HINTS WELCOME.
>
> Gautam
>
>
>
>
>
>
>       
> ____________________________________________________________________________________
> Never miss a thing.  Make Yahoo your home page.
> http://www.yahoo.com/r/hs
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users

From: Michael Demmer <[email-masked]>
To: dtn-users mailing list <[email-masked]>
Date: Tue, 11 Mar 2008 10:19:38 -0700
Subject: Re: [dtn-users] trouble compiling DTN on Fedora Core 8
Reply-To: dtn-users mailing list <[email-masked]>

My guess is that the problem is due to the fact that /home/gthaker/usr/ 
lib is not in your LD_LIBRARY_PATH (or in /etc/ld.so.conf) and so  
therefore it can't load the shared library that's contained there.

You can check this by adding the directory to LD_LIBRARY_PATH and  
trying again.

Also, for this and any future issues with configure, your best bet is  
to look in the config.log which, although verbose, will contain the  
indication of what actually went wrong in the compilation tests and  
can help debug this kind of problem.

-mike

On Mar 11, 2008, at 6:13 AM, Gautam Thaker wrote:

> Hi:
>
> I am new to DTN but fairly experienced at building lots of open  
> source software. i am trying to build DTN-2.5 on Fedora Core 8  
> Linux. I have Berkeley DB 4.5 installed. I do:
>
> ./configure  --with-db=/home/gthaker/usr
>
> However, when building I get:
>
> checking for Berkeley DB header (version 4.5) in /home/gthaker/usr/ 
> include... yes
> checking for Berkeley DB library in /home/gthaker/usr/lib, - 
> ldb-4.5... no
> checking for Berkeley DB header (version 4.4) in /home/gthaker/usr/ 
> include... no
> checking for Berkeley DB header (version 4.3) in /home/gthaker/usr/ 
> include... no
> checking for Berkeley DB header (version 4.2) in /home/gthaker/usr/ 
> include... no
>
> Configure error with Berkeley DB...
>
> It find DB include files ok but not the lib. I have tried to look at  
> the "configure" file but it is some 12,000 lines long and I can find  
> where this error is "detected" but have not yet figured out what is  
> going on.
>
> In /home/gthaker/usr/lib I have:
>
> zadapi-L> pwd
> /home/gthaker/usr/lib
> zadapi-L> ls -lt *db*
> -rw-r--r-- 1 gthaker gthaker 1467492 Mar 10 21:54 libdb-4.5.a
> lrwxrwxrwx 1 gthaker gthaker      12 Mar 10 21:54 libdb-4.so ->  
> libdb-4.5.so
> -rw-r--r-- 1 gthaker gthaker 1467492 Mar 10 21:54 libdb.a
> lrwxrwxrwx 1 gthaker gthaker      12 Mar 10 21:54 libdb.so ->  
> libdb-4.5.so
> -rw-rw-r-- 1 gthaker gthaker     813 Mar 10 21:52 libdb-4.5.la
> -rwxrwxr-x 1 gthaker gthaker 1163035 Mar 10 21:52 libdb-4.5.so
>
>
> ANY HINTS WELCOME.
>
> Gautam
>
>
>
>
>
>
>       
> ____________________________________________________________________________________
> Never miss a thing.  Make Yahoo your home page.
> http://www.yahoo.com/r/hs
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users

Date: Tue, 11 Mar 2008 06:13:32 -0700 (PDT)
From: Gautam Thaker <[email-masked]>
To: [email-masked]
Cc: Gautam H Thaker <[email-masked]>
Subject: [dtn-users] trouble compiling DTN on Fedora Core 8
Reply-To: dtn-users mailing list <[email-masked]>

Hi:

I am new to DTN but fairly experienced at building lots of open source software. i am trying to build DTN-2.5 on Fedora Core 8 Linux. I have Berkeley DB 4.5 installed. I do:

 ./configure  --with-db=/home/gthaker/usr

However, when building I get:

checking for Berkeley DB header (version 4.5) in /home/gthaker/usr/include... yes
checking for Berkeley DB library in /home/gthaker/usr/lib, -ldb-4.5... no
checking for Berkeley DB header (version 4.4) in /home/gthaker/usr/include... no
checking for Berkeley DB header (version 4.3) in /home/gthaker/usr/include... no
checking for Berkeley DB header (version 4.2) in /home/gthaker/usr/include... no

Configure error with Berkeley DB...

It find DB include files ok but not the lib. I have tried to look at the "configure" file but it is some 12,000 lines long and I can find where this error is "detected" but have not yet figured out what is going on.  

In /home/gthaker/usr/lib I have:

zadapi-L> pwd
/home/gthaker/usr/lib
zadapi-L> ls -lt *db*
-rw-r--r-- 1 gthaker gthaker 1467492 Mar 10 21:54 libdb-4.5.a
lrwxrwxrwx 1 gthaker gthaker      12 Mar 10 21:54 libdb-4.so -> libdb-4.5.so
-rw-r--r-- 1 gthaker gthaker 1467492 Mar 10 21:54 libdb.a
lrwxrwxrwx 1 gthaker gthaker      12 Mar 10 21:54 libdb.so -> libdb-4.5.so
-rw-rw-r-- 1 gthaker gthaker     813 Mar 10 21:52 libdb-4.5.la
-rwxrwxr-x 1 gthaker gthaker 1163035 Mar 10 21:52 libdb-4.5.so

ANY HINTS WELCOME.

Gautam

      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

Date: Mon, 3 Mar 2008 13:05:25 +0000
From: "Constantino Antunes" <[email-masked]>
To: "dtn-users mailing list" <[email-masked]>
Subject: Re: [dtn-users] prophet router and dtnsim
Reply-To: dtn-users mailing list <[email-masked]>

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

Thanks for the help. I made what you said and got this stack trace:

#0  0xffffe402 in __kernel_vsyscall ()
#1  0xb774c875 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb774e201 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0x08264aef in oasys::FatalSignals::die () at debug/FatalSignals.cc:154
#4  0x08252662 in oasys::Singleton<dtn::ProphetStore, false>::instance ()
    at ../oasys/util/Singleton.h:137
#5  0x08250029 in dtn::ProphetBundleCore::load_prophet_nodes
(this=0x83e4078,
    nodes=0x83e4c98, params=0x8385660) at routing/ProphetBundleCore.cc:327
#6  0x0812baf8 in dtn::ProphetRouter::initialize (this=0x83e41d8)
    at routing/ProphetRouter.cc:71
#7  0x080659cc in dtnsim::Node::configure (this=0x83dc318) at Node.cc:122
#8  0x0806d16f in dtnsim::Simulator::run (this=0x8389578) at Simulator.cc
:141
#9  0x0805fc90 in DTNSim::main (this=0xbfd2bfb4, argc=3, argv=0xbfd2c4f4)
    at dtnsim.cc:161
#10 0x0806009d in main (argc=3, argv=0xbfd2c4f4) at dtnsim.cc:177

I believe the problem is in #6. At that point there's the following code (in
ProphetRouter.cc):

// deserialize any routes from permanent storage
core_->load_prophet_nodes(oracle_->nodes(),&params_);

Is this supposed to be correct? The router is in any kind of storage and
have to be loaded?

>From the output of gdb I noticed that more than one thread was being used
which made me think that it may be a synchronization problem. I changed the
simulation .conf file to create nodes at a time in the future with "sim at
100 eval { ... }" and got a different error that happened in the
registration ("node registration add ..."). Here's the backtrace:

#0  0x0808bed8 in dtn::BundleDaemon::handle_event (this=0x83dcc4c,
event=0x83e1240) at bundling/BundleDaemon.cc:2367
#1  0x08065842 in dtnsim::Node::process_one_bundle_event (this=0x83dcc48) at
Node.cc:144
#2  0x0806d03c in dtnsim::Simulator::run_node_events (this=0x8389578) at
Simulator.cc:93
#3  0x0806d255 in dtnsim::Simulator::run (this=0x8389578) at Simulator.cc
:152
#4  0x0805fc90 in DTNSim::main (this=0xbff17194, argc=5, argv=0xbff176d4) at
dtnsim.cc:161
#5  0x0806009d in main (argc=5, argv=0xbff176d4) at dtnsim.cc:177

If I remove the registration the program exits normally because the
simulation in question didn't have any other command but the same error
happens for any command (registration, link, conn and tragent) that I use
after creating nodes. It looks like the simulator can't process any event
when the router type is prophet. Don't know what to do now, any ideas?

Constantino

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

Thanks for the help. I made what you said and got this stack trace:<br><br><br><br>#0&nbsp; 0xffffe402 in __kernel_vsyscall ()<br>#1&nbsp; 0xb774c875 in raise () from /lib/tls/i686/cmov/libc.so.6<br>#2&nbsp; 0xb774e201 in abort () from /lib/tls/i686/cmov/libc.so.6<br>
#3&nbsp; 0x08264aef in oasys::FatalSignals::die () at debug/FatalSignals.cc:154<br>#4&nbsp; 0x08252662 in oasys::Singleton&lt;dtn::ProphetStore, false&gt;::instance ()<br>&nbsp;&nbsp;&nbsp; at ../oasys/util/Singleton.h:137<br>#5&nbsp; 0x08250029 in dtn::ProphetBundleCore::load_prophet_nodes (this=0x83e4078, <br>
&nbsp;&nbsp;&nbsp; nodes=0x83e4c98, params=0x8385660) at routing/ProphetBundleCore.cc:327<br>#6&nbsp; 0x0812baf8 in dtn::ProphetRouter::initialize (this=0x83e41d8)<br>&nbsp;&nbsp;&nbsp; at routing/ProphetRouter.cc:71<br>#7&nbsp; 0x080659cc in dtnsim::Node::configure (this=0x83dc318) at Node.cc:122<br>
#8&nbsp; 0x0806d16f in dtnsim::Simulator::run (this=0x8389578) at Simulator.cc:141<br>#9&nbsp; 0x0805fc90 in DTNSim::main (this=0xbfd2bfb4, argc=3, argv=0xbfd2c4f4)<br>&nbsp;&nbsp;&nbsp; at dtnsim.cc:161<br>#10 0x0806009d in main (argc=3, argv=0xbfd2c4f4) at dtnsim.cc:177<br>
<br><br><br>I believe the problem is in #6. At that point there&#39;s the following code (in ProphetRouter.cc):<br><br><br>// deserialize any routes from permanent storage <br>core_-&gt;load_prophet_nodes(oracle_-&gt;nodes(),&amp;params_);<br>
<br><br>Is this supposed to be correct? The router is in any kind of storage and have to be loaded?<br><br>From the output of gdb I noticed that more
than one thread was being used which made me think that it may be a synchronization problem. I changed the simulation .conf file to create nodes at a time in the future with &quot;sim at 100 eval { ... }&quot; and got a different error that happened in the registration (&quot;node registration add ...&quot;). Here&#39;s the backtrace:<br>
<br><br>#0&nbsp; 0x0808bed8 in dtn::BundleDaemon::handle_event (this=0x83dcc4c, event=0x83e1240) at bundling/BundleDaemon.cc:2367<br>#1&nbsp; 0x08065842 in dtnsim::Node::process_one_bundle_event (this=0x83dcc48) at Node.cc:144<br>#2&nbsp; 0x0806d03c in dtnsim::Simulator::run_node_events (this=0x8389578) at Simulator.cc:93<br>
#3&nbsp; 0x0806d255 in dtnsim::Simulator::run (this=0x8389578) at Simulator.cc:152<br>#4&nbsp; 0x0805fc90 in DTNSim::main (this=0xbff17194, argc=5, argv=0xbff176d4) at dtnsim.cc:161<br>#5&nbsp; 0x0806009d in main (argc=5, argv=0xbff176d4) at dtnsim.cc:177<br>
<br><br>If I remove the registration the program exits normally because the simulation in question didn&#39;t have any other command but the same error happens for any command (registration, link, conn and tragent) that I use after creating nodes. It looks like the simulator can&#39;t process any event when the router type is prophet. Don&#39;t know what to do now, any ideas?<br>
<br>Constantino<br>

------=_Part_29978_2262490.1204549525733--

Content-class: urn:content-classes:message
Date: Mon, 3 Mar 2008 10:36:19 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: [dtn-users] prophet router and dtnsim
Reply-To: dtn-users mailing list <[email-masked]>

This is a multi-part message in MIME format.

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

Build with debugger support (typically gcc -g for gdb support).
Then run the code under gdb.

Once the assertion takes it down, the stack trace will be more =
meaningful.
'bt' for a backtrace.

L.

Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

-----Original Message-----
From: [email-masked] on behalf of Constantino =
Antunes
Sent: Mon 2008-03-03 8:31
To: [email-masked]
Subject: [dtn-users] prophet router and dtnsim
=20
Hi,
I am trying to use dtnsim with the prophet router but it keeps giving me =
the
same error when I create a network node:
=ABASSERTION FAILED (instance_) at ../oasys/util/Singleton.h:137
STACK TRACE: 0x8264aa3 0x8252662 0x8250029 0x812baf8 0x80659cc 0x806d16f
0x805fc90 0x806009d 0xb774d050=BB

Anyone could help me please?

Constantino

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

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

<P><FONT SIZE=3D2>Build with debugger support (typically gcc -g for gdb =
support).<BR>
Then run the code under gdb.<BR>
<BR>
Once the assertion takes it down, the stack trace will be more =
meaningful.<BR>
'bt' for a backtrace.<BR>
<BR>
L.<BR>
<BR>
Saratoga: <A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/">http://www.ee.su=
rrey.ac.uk/Personal/L.Wood/dtn/</A><BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: [email-masked] on behalf of Constantino =
Antunes<BR>
Sent: Mon 2008-03-03 8:31<BR>
To: [email-masked]<BR>
Subject: [dtn-users] prophet router and dtnsim<BR>
<BR>
Hi,<BR>
I am trying to use dtnsim with the prophet router but it keeps giving me =
the<BR>
same error when I create a network node:<BR>
=ABASSERTION FAILED (instance_) at ../oasys/util/Singleton.h:137<BR>
STACK TRACE: 0x8264aa3 0x8252662 0x8250029 0x812baf8 0x80659cc =
0x806d16f<BR>
0x805fc90 0x806009d 0xb774d050=BB<BR>
<BR>
Anyone could help me please?<BR>
<BR>
Constantino<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C87D1A.D240841B--

Date: Mon, 3 Mar 2008 08:31:50 +0000
From: "Constantino Antunes" <[email-masked]>
To: [email-masked]
Subject: [dtn-users] prophet router and dtnsim
Reply-To: dtn-users mailing list <[email-masked]>

------=_Part_29369_6440591.1204533111016
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,
I am trying to use dtnsim with the prophet router but it keeps giving me th=
e
same error when I create a network node:
=ABASSERTION FAILED (instance_) at ../oasys/util/Singleton.h:137
STACK TRACE: 0x8264aa3 0x8252662 0x8250029 0x812baf8 0x80659cc 0x806d16f
0x805fc90 0x806009d 0xb774d050=BB

Anyone could help me please?

Constantino

------=_Part_29369_6440591.1204533111016
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,<br>I am trying to use dtnsim with the prophet router but it keeps givin=
g me the same error when I create a network node:<br>=ABASSERTION FAILED (i=
nstance_) at ../oasys/util/Singleton.h:137<br>STACK TRACE: 0x8264aa3 0x8252=
662 0x8250029 0x812baf8 0x80659cc 0x806d16f 0x805fc90 0x806009d 0xb774d050=
=BB<br>
<br clear=3D"all">Anyone could help me please?<br><br>Constantino

------=_Part_29369_6440591.1204533111016--

From: Michael Demmer <[email-masked]>
To: dtn-users mailing list <[email-masked]>
Date: Sun, 2 Mar 2008 19:59:20 -0800
Subject: Re: [dtn-users] Building DTN2 fails due to missing headers in oasys
Reply-To: dtn-users mailing list <[email-masked]>

It looks like mercurial doesn't handle branches the way that I  
thought, and that you're inadvertently to on the apr-port branch, in  
which TCPClient.h doesn't exist. You can verify this by running 'hg  
branch'.

If you go into the oasys directory and run 'hg update -r default' then  
you can get back onto the main branch which should solve the build  
problems.

-m

On Mar 2, 2008, at 2:58 PM, [email-masked] wrote:

>
>
> Hi,
>
> I am unable to build bleeding edge code taken using mercurial from
> http://www.dtnrg.org/hg/oasys.
>
> Basically it complains about a missing header file
>
> In file included from APIServer.cc:31:
> APIServer.h:26:32: warning: oasys/io/TCPClient.h: No such file or  
> directory
>
> Does anyone has any clue?
>
> best regards
> imran
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users

Date: Mon,  3 Mar 2008 00:58:03 +0200
From: [email-masked]
To: [email-masked]
Subject: [dtn-users] Building DTN2 fails due to missing headers in oasys
Reply-To: dtn-users mailing list <[email-masked]>

Hi,

I am unable to build bleeding edge code taken using mercurial from
http://www.dtnrg.org/hg/oasys.

Basically it complains about a missing header file

In file included from APIServer.cc:31:
APIServer.h:26:32: warning: oasys/io/TCPClient.h: No such file or directory

Does anyone has any clue?

best regards
imran