Subject: [dtn-users] Problems with DTN from CVS (4 of 4)
From: Darren Long <[email-masked]>
To: [email-masked]
Date: Sat, 30 Jul 2005 12:42:02 +0100
List-Id: discussion/answers list for users of the dtn reference implementation <dtn-users.mailman.dtnrg.org>

Oh, and one more thing.

Darren

4)  I've also had ASSERTS fail when ON-DEMAND links get closed after  
30 second idle timeout, on both FC4 and Mac OS X 10.4.2.  I've  
commented out the assert, as below.  After looking at the explanation  
of state transitions in Link.h, I half suspect that the ASSERT is  
erroneous, and that transitions from CLOSING to AVAILABLE are valid.   
I'm not sure if the ASSERT should assert something else, as its not  
immediately clear.  it seems to work this way.

Darren

void
Link::set_state(state_t new_state)
{
     log_debug("set_state %s -> %s",
               state_to_str(state_), state_to_str(new_state));

     switch(new_state) {
     case UNAVAILABLE:
         break; // any old state is valid

     case AVAILABLE:
         //ASSERT(state_ == UNAVAILABLE);
         break;

     case OPENING:
         ASSERT(state_ == AVAILABLE);
         break;

     case OPEN:
         ASSERT(state_ == OPENING || state_ == BUSY);
         break;

     case BUSY:
         ASSERT(state_ == OPEN);
         break;

     case CLOSING:
         ASSERT(state_ == OPENING || state_ == OPEN || state_ == BUSY);
         break;

     default:
         NOTREACHED;
     }

     state_ = new_state;
}

To: [email-masked]
From: Darren Long <[email-masked]>
Date: Sat, 30 Jul 2005 12:16:50 +0100
Subject: [dtn-users] Problems with DTN from CVS (2 of 3)
Sender: [email-masked]
Reply-To: [email-masked]

2) dtnd fails an assertion when confused by bundle expirations during  
inter-node pinging.  It actually makes for a fun game, like "pass the  
hot potatoe", wondering which dtnd will get nailed ;-)  Most fun can  
be  had as it tries to delete a bundle after transmission, which had  
jus expired.  I managed to kill both dtnds once with one ping  
bundle.  This happens on both Tiger and FC4 on x86.
Self-pinging works ok, probably as the dtnd manages to get rid of the  
bundle before its expiration.  I haven't looked into this closely,  
yet.  Not much luck changing the expiration time in the dtnping  
invocation.

dtn% [1122590024.144912 /bundle/daemon info] BUNDLE_RECEIVED bundle  
id 0 bundles://internet/host://iBook12.dyndns.org/ping.19989 ->  
bundles://internet/host://soltek (1 bytes payload) (1 bytes recvd)
[1122590024.145575 /reg/admin info] ADMIN_ECHO from bundles:// 
internet/host://iBook12.dyndns.org/ping.19989
[1122590024.146219 /bundle/daemon info] BUNDLE_RECEIVED bundle id 1  
bundles://internet/host://soltek -> bundles://internet/host:// 
iBook12.dyndns.org/ping.19989 (88 bytes payload) (88 bytes recvd)
[1122590024.146830 /contact/host://iBook12.dyndns.org:5000 info] new  
contact contact host://iBook12.dyndns.org:5000 (started  
1122590024.146823)
[1122590024.165170 /bundle/daemon info] BUNDLE_EXPIRED bundle id 0  
bundles://internet/host://iBook12.dyndns.org/ping.19989 -> bundles:// 
internet/host://soltek (1 bytes payload)
[1122590024.165848 /bundle/daemon info] BUNDLE_TRANSMITTED id:0 (1  
bytes) ACKED -> bundles://internet/host://soltek
[1122590024.165988 /storage/bundles error] del bundle 0: bundle  
doesn't exist
[1122590024.166043 /assert critical] ASSERTION FAILED (removed) at  
bundling/BundleActions.cc:174
Aborted

/**
* Remove the given bundle from the data store.
*/
void
BundleActions::store_del(Bundle* bundle)
{
     log_debug("removing bundle %d from data store", bundle->bundleid_);
     bool removed = BundleStore::instance()->del(bundle->bundleid_);
     ASSERT(removed);
}

I've made a very nasty hack, by commenting out the ASSERT.  dtnd runs  
and complains about non-existent bundles, but it does work, which is  
slightly important.

Darren

To: [email-masked]
From: Darren Long <[email-masked]>
Date: Sat, 30 Jul 2005 12:10:48 +0100
Subject: [dtn-users] Problems with DTN from CVS (1 of 3)
Sender: [email-masked]
Reply-To: [email-masked]

Hi,

I originally sent this in one email, but it was intercepted due to  
its size. Now split into three parts, with some additional info.

Darren

1) Problem compiling from CVS  on FC4 x86.  This stuff is only  
compiled for Linux.

g++ -I.. -I../servlib    -g -fno-inline  -MMD -MP -MT "naming/ 
EthernetScheme.o naming/EthernetScheme.E naming/EthernetScheme.po" - 
Wall -Werror  -c naming/EthernetScheme.cc -o naming/EthernetScheme.o
naming/EthernetScheme.cc:50: error: too few template-parameter-lists
make[1]: *** [naming/EthernetScheme.o] Error 1
make[1]: Leaving directory `/home/darren/source/DTN2/servlib'
make: *** [servlib] Error 2

Problem seems to be with the line:
     EthernetScheme* oasys::Singleton<EthernetScheme>::instance_;

using gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)

I changed it to:
     template<> EthernetScheme*  
oasys::Singleton<EthernetScheme>::instance_ = 0;
and its ok now.

BTW, I notice that there is no mutex in the singleton template's  
instance method. I've found that needed to avoid memory leaks before,  
depending on how many threads you may invoke it from. YMMV.

Date: Tue, 26 Jul 2005 10:53:29 -0700
From: Michael Demmer <[email-masked]>
To: [email-masked]
Cc: Darren Long <[email-masked]>
Subject: Re: [dtn-users] DTN2 (from CVS) problems on Mac OS X 10.4.2
Sender: [email-masked]
Reply-To: [email-masked]

(Darren, be careful which email address you use to post, this message
was held since the account you used isn't subscribed)

> I had a problem running make tests related to the size_t issue.  This  
> time, the compiler said:
> 
> g++ -I.. -I../servlib   -Wno-long-double -I/usr/local/BerkeleyDB.4.2/ 
> include  -g -fno-inline  -MMD -MP -MT "bundle-list.o bundle-list.E  
> bundle-list.po" -Wall -Werror  -c unit_tests/bundle-list-test.cc -o  
> unit_tests/bundle-list-test.o
> cc1plus: warnings being treated as errors
> ../oasys/util/UnitTest.h: In member function `void  
> oasys::UnitTester::print_tail()':
> ../oasys/util/UnitTest.h:159: warning: format '%d' expects type  
> 'int', but argument 3 has type 'size_t'
> make[1]: *** [unit_tests/bundle-list-test.o] Error 1
> rm unit_tests/address-family-test.o
> make: *** [tests] Error 2
> 
> I used static_cast<int> again...
> 
> void print_tail() {
>     fprintf(stderr, "} { %d %d %d %d } }\n",
>     static_cast<int>(tests_.size()), passed_, failed_, input_);
> }

That's fine. I've actually been changing them more as follows:

> void print_tail() {
>     fprintf(stderr, "} { %u %d %d %d } }\n",
>             (u_int)tests_.size(), passed_, failed_, input_);

Marginal benefit for signed vs. unsigned issues, but it's not a big
deal one way or the other.

> and make tests ran ok, but then running the unit tests i got...
> ...
> Segmentation fault
> 
> Do you have a magic fix for this one too?  It could be related to my  
> hack.  I could try running it in the debugger when I get home.

Hrm. Doesn't happen for me either on Linux or on OS X 10.3.9. Can you
try to track it down in the debugger and at least see where it's
crashing, preferably try to do some investigation to see what the
problem is?

-m

From: Darren Long <[email-masked]>
Subject: Re: [dtn-users] DTN2 (from CVS) problems on Mac OS X 10.4.2
Date: Tue, 26 Jul 2005 12:41:16 +0100
To: Darren Long <[email-masked]>
Sender: [email-masked]
Reply-To: [email-masked]

On 26 Jul 2005, at 03:03, Michael Demmer wrote:

>
>
>
>> I got past this by using static_cast<unsigned int> for both of the
>> params  in the call to min in
>> oasys::StaticStringBuffer<_sz>::StaticStringBuffer(char*)
>>
>>
>
> I fixed this in a slightly different way by changing the template
> parameter to just be a size_t.
>
> But in either event, this should work for you now (I hope).
>

I had a problem running make tests related to the size_t issue.  This  
time, the compiler said:

g++ -I.. -I../servlib   -Wno-long-double -I/usr/local/BerkeleyDB.4.2/ 
include  -g -fno-inline  -MMD -MP -MT "bundle-list.o bundle-list.E  
bundle-list.po" -Wall -Werror  -c unit_tests/bundle-list-test.cc -o  
unit_tests/bundle-list-test.o
cc1plus: warnings being treated as errors
../oasys/util/UnitTest.h: In member function `void  
oasys::UnitTester::print_tail()':
../oasys/util/UnitTest.h:159: warning: format '%d' expects type  
'int', but argument 3 has type 'size_t'
make[1]: *** [unit_tests/bundle-list-test.o] Error 1
rm unit_tests/address-family-test.o
make: *** [tests] Error 2

I used static_cast<int> again...

void print_tail() {
     fprintf(stderr, "} { %d %d %d %d } }\n",
     static_cast<int>(tests_.size()), passed_, failed_, input_);
}

and make tests ran ok, but then running the unit tests i got...

iBook12:~/Source/DTN2/test/unit_tests darren$ ./bundle-list-test
Init...
[1122374166.285829 /bundle debug] Bundle::init bundle id 0
[1122374166.286571 /bundle/refs debug] bundle id 0: refcount 0 -> 1  
(0 mappings) add test
[1122374166.287170 /bundle debug] Bundle::init bundle id 1
[1122374166.287951 /bundle/refs debug] bundle id 1: refcount 0 -> 1  
(0 mappings) add test
[1122374166.288551 /bundle debug] Bundle::init bundle id 2
[1122374166.288985 /bundle/refs debug] bundle id 2: refcount 0 -> 1  
(0 mappings) add test
[1122374166.289494 /bundle debug] Bundle::init bundle id 3
[1122374166.289883 /bundle/refs debug] bundle id 3: refcount 0 -> 1  
(0 mappings) add test
[1122374166.290318 /bundle debug] Bundle::init bundle id 4
[1122374166.290683 /bundle/refs debug] bundle id 4: refcount 0 -> 1  
(0 mappings) add test
[1122374166.291103 /bundle debug] Bundle::init bundle id 5
[1122374166.291468 /bundle/refs debug] bundle id 5: refcount 0 -> 1  
(0 mappings) add test
[1122374166.291886 /bundle debug] Bundle::init bundle id 6
[1122374166.292246 /bundle/refs debug] bundle id 6: refcount 0 -> 1  
(0 mappings) add test
[1122374166.292656 /bundle debug] Bundle::init bundle id 7
[1122374166.293014 /bundle/refs debug] bundle id 7: refcount 0 -> 1  
(0 mappings) add test
[1122374166.293632 /bundle debug] Bundle::init bundle id 8
[1122374166.294045 /bundle/refs debug] bundle id 8: refcount 0 -> 1  
(0 mappings) add test
[1122374166.294478 /bundle debug] Bundle::init bundle id 9
[1122374166.294844 /bundle/refs debug] bundle id 9: refcount 0 -> 1  
(0 mappings) add test
[1122374166.295584 /test debug] CHECK 'l1->size()' (0) == '0' (0)
[1122374166.296114 /test debug] CHECK 'l2->size()' (0) == '0' (0)
[1122374166.296545 /test debug] CHECK 'l3->size()' (0) == '0' (0)
[1122374166.296954 /test debug] CHECK 'bundles[i]->num_mappings 
()' (0) == '0' (0)
[1122374166.297381 /test debug] CHECK 'bundles[i]->num_mappings 
()' (0) == '0' (0)
[1122374166.298036 /test debug] CHECK 'bundles[i]->num_mappings 
()' (0) == '0' (0)
[1122374166.298503 /test debug] CHECK 'bundles[i]->num_mappings 
()' (0) == '0' (0)
[1122374166.298928 /test debug] CHECK 'bundles[i]->num_mappings 
()' (0) == '0' (0)
[1122374166.299382 /test debug] CHECK 'bundles[i]->num_mappings 
()' (0) == '0' (0)
[1122374166.299794 /test debug] CHECK 'bundles[i]->num_mappings 
()' (0) == '0' (0)
[1122374166.300198 /test debug] CHECK 'bundles[i]->num_mappings 
()' (0) == '0' (0)
[1122374166.300592 /test debug] CHECK 'bundles[i]->num_mappings 
()' (0) == '0' (0)
[1122374166.300983 /test debug] CHECK 'bundles[i]->num_mappings 
()' (0) == '0' (0)
Init... Passed
BasicPushPop...
[1122374166.302258 /bundle/refs debug] bundle id 0: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.302761 /bundle/mapping debug] bundle id 0 add mapping  
[list1]
[1122374166.303351 /test debug] CHECK 'bundles[i]->refcount()' (2) ==  
'2' (2)
[1122374166.303788 /bundle/refs debug] bundle id 1: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.304234 /bundle/mapping debug] bundle id 1 add mapping  
[list1]
[1122374166.304615 /test debug] CHECK 'bundles[i]->refcount()' (2) ==  
'2' (2)
[1122374166.305027 /bundle/refs debug] bundle id 2: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.305467 /bundle/mapping debug] bundle id 2 add mapping  
[list1]
[1122374166.305844 /test debug] CHECK 'bundles[i]->refcount()' (2) ==  
'2' (2)
[1122374166.306219 /bundle/refs debug] bundle id 3: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.306631 /bundle/mapping debug] bundle id 3 add mapping  
[list1]
[1122374166.306997 /test debug] CHECK 'bundles[i]->refcount()' (2) ==  
'2' (2)
[1122374166.307431 /bundle/refs debug] bundle id 4: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.307890 /bundle/mapping debug] bundle id 4 add mapping  
[list1]
[1122374166.308594 /test debug] CHECK 'bundles[i]->refcount()' (2) ==  
'2' (2)
[1122374166.309008 /bundle/refs debug] bundle id 5: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.311434 /bundle/mapping debug] bundle id 5 add mapping  
[list1]
[1122374166.312162 /test debug] CHECK 'bundles[i]->refcount()' (2) ==  
'2' (2)
[1122374166.312661 /bundle/refs debug] bundle id 6: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.313127 /bundle/mapping debug] bundle id 6 add mapping  
[list1]
[1122374166.313523 /test debug] CHECK 'bundles[i]->refcount()' (2) ==  
'2' (2)
[1122374166.313906 /bundle/refs debug] bundle id 7: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.314328 /bundle/mapping debug] bundle id 7 add mapping  
[list1]
[1122374166.314697 /test debug] CHECK 'bundles[i]->refcount()' (2) ==  
'2' (2)
[1122374166.315067 /bundle/refs debug] bundle id 8: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.315495 /bundle/mapping debug] bundle id 8 add mapping  
[list1]
[1122374166.315867 /test debug] CHECK 'bundles[i]->refcount()' (2) ==  
'2' (2)
[1122374166.316241 /bundle/refs debug] bundle id 9: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.316655 /bundle/mapping debug] bundle id 9 add mapping  
[list1]
[1122374166.317016 /test debug] CHECK 'bundles[i]->refcount()' (2) ==  
'2' (2)
[1122374166.317488 /bundle/mapping debug] bundle id 0 del_bundle:  
deleting mapping [list1]
[1122374166.318656 /test debug] CHECK 'b' (6295040) == 'bundles 
[i]' (6295040)
[1122374166.319190 /bundle/refs debug] bundle id 0: refcount 2 -> 1  
(0 mappings) del test pop
[1122374166.319720 /test debug] CHECK 'b->refcount()' (1) == '1' (1)
[1122374166.320208 /bundle/mapping debug] bundle id 1 del_bundle:  
deleting mapping [list1]
[1122374166.320667 /test debug] CHECK 'b' (6295424) == 'bundles 
[i]' (6295424)
[1122374166.321055 /bundle/refs debug] bundle id 1: refcount 2 -> 1  
(0 mappings) del test pop
[1122374166.321473 /test debug] CHECK 'b->refcount()' (1) == '1' (1)
[1122374166.321885 /bundle/mapping debug] bundle id 2 del_bundle:  
deleting mapping [list1]
[1122374166.322310 /test debug] CHECK 'b' (6295808) == 'bundles 
[i]' (6295808)
[1122374166.322687 /bundle/refs debug] bundle id 2: refcount 2 -> 1  
(0 mappings) del test pop
[1122374166.323098 /test debug] CHECK 'b->refcount()' (1) == '1' (1)
[1122374166.323462 /bundle/mapping debug] bundle id 3 del_bundle:  
deleting mapping [list1]
[1122374166.323874 /test debug] CHECK 'b' (6296192) == 'bundles 
[i]' (6296192)
[1122374166.324241 /bundle/refs debug] bundle id 3: refcount 2 -> 1  
(0 mappings) del test pop
[1122374166.324640 /test debug] CHECK 'b->refcount()' (1) == '1' (1)
[1122374166.325000 /bundle/mapping debug] bundle id 4 del_bundle:  
deleting mapping [list1]
[1122374166.325415 /test debug] CHECK 'b' (6296576) == 'bundles 
[i]' (6296576)
[1122374166.325782 /bundle/refs debug] bundle id 4: refcount 2 -> 1  
(0 mappings) del test pop
[1122374166.326428 /test debug] CHECK 'b->refcount()' (1) == '1' (1)
[1122374166.326824 /bundle/mapping debug] bundle id 5 del_bundle:  
deleting mapping [list1]
[1122374166.327253 /test debug] CHECK 'b' (6296960) == 'bundles 
[i]' (6296960)
[1122374166.327628 /bundle/refs debug] bundle id 5: refcount 2 -> 1  
(0 mappings) del test pop
[1122374166.328039 /test debug] CHECK 'b->refcount()' (1) == '1' (1)
[1122374166.328629 /bundle/mapping debug] bundle id 6 del_bundle:  
deleting mapping [list1]
[1122374166.329091 /test debug] CHECK 'b' (6297344) == 'bundles 
[i]' (6297344)
[1122374166.329530 /bundle/refs debug] bundle id 6: refcount 2 -> 1  
(0 mappings) del test pop
[1122374166.329947 /test debug] CHECK 'b->refcount()' (1) == '1' (1)
[1122374166.330320 /bundle/mapping debug] bundle id 7 del_bundle:  
deleting mapping [list1]
[1122374166.331203 /test debug] CHECK 'b' (6297728) == 'bundles 
[i]' (6297728)
[1122374166.331675 /bundle/refs debug] bundle id 7: refcount 2 -> 1  
(0 mappings) del test pop
[1122374166.332118 /test debug] CHECK 'b->refcount()' (1) == '1' (1)
[1122374166.332496 /bundle/mapping debug] bundle id 8 del_bundle:  
deleting mapping [list1]
[1122374166.332915 /test debug] CHECK 'b' (6298112) == 'bundles 
[i]' (6298112)
[1122374166.333287 /bundle/refs debug] bundle id 8: refcount 2 -> 1  
(0 mappings) del test pop
[1122374166.333689 /test debug] CHECK 'b->refcount()' (1) == '1' (1)
[1122374166.334051 /bundle/mapping debug] bundle id 9 del_bundle:  
deleting mapping [list1]
[1122374166.334458 /test debug] CHECK 'b' (6298496) == 'bundles 
[i]' (6298496)
[1122374166.334822 /bundle/refs debug] bundle id 9: refcount 2 -> 1  
(0 mappings) del test pop
[1122374166.338247 /test debug] CHECK 'b->refcount()' (1) == '1' (1)
[1122374166.339160 /bundle/refs debug] bundle id 0: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.339788 /bundle/mapping debug] bundle id 0 add mapping  
[list1]
[1122374166.340220 /test debug] CHECK 'bundles[i]->refcount()' (2) ==  
'2' (2)
[1122374166.340629 /bundle/refs debug] bundle id 1: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.341059 /bundle/mapping debug] bundle id 1 add mapping  
[list1]
[1122374166.341435 /test debug] CHECK 'bundles[i]->refcount()' (2) ==  
'2' (2)
[1122374166.341814 /bundle/refs debug] bundle id 2: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.342228 /bundle/mapping debug] bundle id 2 add mapping  
[list1]
[1122374166.342592 /test debug] CHECK 'bundles[i]->refcount()' (2) ==  
'2' (2)
[1122374166.342961 /bundle/refs debug] bundle id 3: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.343373 /bundle/mapping debug] bundle id 3 add mapping  
[list1]
[1122374166.343738 /test debug] CHECK 'bundles[i]->refcount()' (2) ==  
'2' (2)
[1122374166.344107 /bundle/refs debug] bundle id 4: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.345388 /bundle/mapping debug] bundle id 4 add mapping  
[list1]
[1122374166.345913 /test debug] CHECK 'bundles[i]->refcount()' (2) ==  
'2' (2)
[1122374166.346342 /bundle/refs debug] bundle id 5: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.346906 /bundle/mapping debug] bundle id 5 add mapping  
[list1]
[1122374166.347297 /test debug] CHECK 'bundles[i]->refcount()' (2) ==  
'2' (2)
[1122374166.351827 /bundle/refs debug] bundle id 6: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.352566 /bundle/mapping debug] bundle id 6 add mapping  
[list1]
[1122374166.353040 /test debug] CHECK 'bundles[i]->refcount()' (2) ==  
'2' (2)
[1122374166.353460 /bundle/refs debug] bundle id 7: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.353906 /bundle/mapping debug] bundle id 7 add mapping  
[list1]
[1122374166.354287 /test debug] CHECK 'bundles[i]->refcount()' (2) ==  
'2' (2)
[1122374166.354662 /bundle/refs debug] bundle id 8: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.355117 /bundle/mapping debug] bundle id 8 add mapping  
[list1]
[1122374166.355511 /test debug] CHECK 'bundles[i]->refcount()' (2) ==  
'2' (2)
[1122374166.355889 /bundle/refs debug] bundle id 9: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.356307 /bundle/mapping debug] bundle id 9 add mapping  
[list1]
[1122374166.356675 /test debug] CHECK 'bundles[i]->refcount()' (2) ==  
'2' (2)
[1122374166.357093 /test debug] CHECK 'l1->size()' (10) == 'COUNT' (10)
[1122374166.357514 /bundle/mapping debug] bundle id 0 del_bundle:  
deleting mapping [list1]
[1122374166.357961 /test debug] CHECK 'b' (6295040) == 'bundles 
[i]' (6295040)
[1122374166.358600 /bundle/refs debug] bundle id 0: refcount 2 -> 1  
(0 mappings) del test pop
[1122374166.359081 /test debug] CHECK 'b->refcount()' (1) == '1' (1)
[1122374166.359525 /bundle/mapping debug] bundle id 1 del_bundle:  
deleting mapping [list1]
[1122374166.359969 /test debug] CHECK 'b' (6295424) == 'bundles 
[i]' (6295424)
[1122374166.360352 /bundle/refs debug] bundle id 1: refcount 2 -> 1  
(0 mappings) del test pop
[1122374166.360856 /test debug] CHECK 'b->refcount()' (1) == '1' (1)
[1122374166.361490 /bundle/mapping debug] bundle id 2 del_bundle:  
deleting mapping [list1]
[1122374166.361975 /test debug] CHECK 'b' (6295808) == 'bundles 
[i]' (6295808)
[1122374166.362378 /bundle/refs debug] bundle id 2: refcount 2 -> 1  
(0 mappings) del test pop
[1122374166.362797 /test debug] CHECK 'b->refcount()' (1) == '1' (1)
[1122374166.363168 /bundle/mapping debug] bundle id 3 del_bundle:  
deleting mapping [list1]
[1122374166.363582 /test debug] CHECK 'b' (6296192) == 'bundles 
[i]' (6296192)
[1122374166.363952 /bundle/refs debug] bundle id 3: refcount 2 -> 1  
(0 mappings) del test pop
[1122374166.364358 /test debug] CHECK 'b->refcount()' (1) == '1' (1)
[1122374166.364719 /bundle/mapping debug] bundle id 4 del_bundle:  
deleting mapping [list1]
[1122374166.365125 /test debug] CHECK 'b' (6296576) == 'bundles 
[i]' (6296576)
[1122374166.365501 /bundle/refs debug] bundle id 4: refcount 2 -> 1  
(0 mappings) del test pop
[1122374166.365903 /test debug] CHECK 'b->refcount()' (1) == '1' (1)
[1122374166.366262 /bundle/mapping debug] bundle id 5 del_bundle:  
deleting mapping [list1]
[1122374166.366674 /test debug] CHECK 'b' (6296960) == 'bundles 
[i]' (6296960)
[1122374166.367035 /bundle/refs debug] bundle id 5: refcount 2 -> 1  
(0 mappings) del test pop
[1122374166.367441 /test debug] CHECK 'b->refcount()' (1) == '1' (1)
[1122374166.367799 /bundle/mapping debug] bundle id 6 del_bundle:  
deleting mapping [list1]
[1122374166.368204 /test debug] CHECK 'b' (6297344) == 'bundles 
[i]' (6297344)
[1122374166.368563 /bundle/refs debug] bundle id 6: refcount 2 -> 1  
(0 mappings) del test pop
[1122374166.368965 /test debug] CHECK 'b->refcount()' (1) == '1' (1)
[1122374166.369325 /bundle/mapping debug] bundle id 7 del_bundle:  
deleting mapping [list1]
[1122374166.369789 /test debug] CHECK 'b' (6297728) == 'bundles 
[i]' (6297728)
[1122374166.370157 /bundle/refs debug] bundle id 7: refcount 2 -> 1  
(0 mappings) del test pop
[1122374166.370559 /test debug] CHECK 'b->refcount()' (1) == '1' (1)
[1122374166.371727 /bundle/mapping debug] bundle id 8 del_bundle:  
deleting mapping [list1]
[1122374166.372311 /test debug] CHECK 'b' (6298112) == 'bundles 
[i]' (6298112)
[1122374166.372726 /bundle/refs debug] bundle id 8: refcount 2 -> 1  
(0 mappings) del test pop
[1122374166.373167 /test debug] CHECK 'b->refcount()' (1) == '1' (1)
[1122374166.373582 /bundle/mapping debug] bundle id 9 del_bundle:  
deleting mapping [list1]
[1122374166.374009 /test debug] CHECK 'b' (6298496) == 'bundles 
[i]' (6298496)
[1122374166.374390 /bundle/refs debug] bundle id 9: refcount 2 -> 1  
(0 mappings) del test pop
[1122374166.374800 /test debug] CHECK 'b->refcount()' (1) == '1' (1)
[1122374166.375166 /test debug] CHECK 'l1->size()' (0) == '0' (0)
BasicPushPop... Passed
ContainsAndErase...
[1122374166.376249 /bundle/refs debug] bundle id 0: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.376678 /bundle/mapping debug] bundle id 0 add mapping  
[list1]
[1122374166.377141 /test debug] CHECK (l1->contains(bundles[i])) ok
[1122374166.378060 /bundle/refs debug] bundle id 1: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.379003 /bundle/mapping debug] bundle id 1 add mapping  
[list1]
[1122374166.383031 /test debug] CHECK (l1->contains(bundles[i])) ok
[1122374166.384281 /bundle/refs debug] bundle id 2: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.384923 /bundle/mapping debug] bundle id 2 add mapping  
[list1]
[1122374166.386749 /test debug] CHECK (l1->contains(bundles[i])) ok
[1122374166.386973 /bundle/refs debug] bundle id 3: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.387077 /bundle/mapping debug] bundle id 3 add mapping  
[list1]
[1122374166.387155 /test debug] CHECK (l1->contains(bundles[i])) ok
[1122374166.387242 /bundle/refs debug] bundle id 4: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.387316 /bundle/mapping debug] bundle id 4 add mapping  
[list1]
[1122374166.387396 /test debug] CHECK (l1->contains(bundles[i])) ok
[1122374166.387475 /bundle/refs debug] bundle id 5: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.387547 /bundle/mapping debug] bundle id 5 add mapping  
[list1]
[1122374166.387619 /test debug] CHECK (l1->contains(bundles[i])) ok
[1122374166.387706 /bundle/refs debug] bundle id 6: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.387826 /bundle/mapping debug] bundle id 6 add mapping  
[list1]
[1122374166.387899 /test debug] CHECK (l1->contains(bundles[i])) ok
[1122374166.387977 /bundle/refs debug] bundle id 7: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.388050 /bundle/mapping debug] bundle id 7 add mapping  
[list1]
[1122374166.388127 /test debug] CHECK (l1->contains(bundles[i])) ok
[1122374166.388205 /bundle/refs debug] bundle id 8: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.388277 /bundle/mapping debug] bundle id 8 add mapping  
[list1]
[1122374166.388384 /test debug] CHECK (l1->contains(bundles[i])) ok
[1122374166.388463 /bundle/refs debug] bundle id 9: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.388535 /bundle/mapping debug] bundle id 9 add mapping  
[list1]
[1122374166.388608 /test debug] CHECK (l1->contains(bundles[i])) ok
[1122374166.388687 /test debug] CHECK 'l1->size()' (10) == 'COUNT' (10)
[1122374166.388805 /bundle/mapping debug] bundle id 0 del_bundle:  
deleting mapping [list1]
[1122374166.388900 /bundle/refs debug] bundle id 0: refcount 2 -> 1  
(0 mappings) del bundle_list list1
[1122374166.393823 /test debug] CHECK (l1->erase(bundles[0])) ok
[1122374166.394000 /test debug] CHECK (! l1->contains(bundles[0])) ok
[1122374166.394070 /test debug] CHECK 'bundles[0]->refcount()' (1) ==  
'1' (1)
[1122374166.394136 /test debug] CHECK 'bundles[0]->num_mappings 
()' (0) == '0' (0)
[1122374166.394209 /test debug] CHECK 'l1->size()' (9) == 'COUNT -  
1' (9)
[1122374166.394280 /test debug] CHECK (! l1->erase(bundles[0])) ok
[1122374166.394356 /test debug] CHECK (! l1->contains(bundles[0])) ok
[1122374166.394416 /test debug] CHECK 'bundles[0]->refcount()' (1) ==  
'1' (1)
[1122374166.394477 /test debug] CHECK 'bundles[0]->num_mappings 
()' (0) == '0' (0)
[1122374166.394546 /test debug] CHECK 'l1->size()' (9) == '9' (9)
[1122374166.394620 /bundle/mapping debug] bundle id 5 del_bundle:  
deleting mapping [list1]
[1122374166.394737 /bundle/refs debug] bundle id 5: refcount 2 -> 1  
(0 mappings) del bundle_list list1
[1122374166.394816 /test debug] CHECK (l1->erase(bundles[5])) ok
[1122374166.394882 /test debug] CHECK (! l1->contains(bundles[5])) ok
[1122374166.394942 /test debug] CHECK 'bundles[5]->refcount()' (1) ==  
'1' (1)
[1122374166.395004 /test debug] CHECK 'bundles[5]->num_mappings 
()' (0) == '0' (0)
[1122374166.395073 /test debug] CHECK 'l1->size()' (8) == 'COUNT -  
2' (8)
[1122374166.395141 /test debug] CHECK (! l1->contains(NULL)) ok
[1122374166.395206 /test debug] CHECK (! l1->erase(NULL)) ok
[1122374166.395274 /test debug] CHECK 'l1->size()' (8) == 'COUNT -  
2' (8)
[1122374166.395343 /bundle/mapping debug] bundle id 1 del_bundle:  
deleting mapping [list1]
[1122374166.395432 /bundle/refs debug] bundle id 1: refcount 2 -> 1  
(0 mappings) del bundle_list list1
[1122374166.395511 /bundle/mapping debug] bundle id 2 del_bundle:  
deleting mapping [list1]
[1122374166.395593 /bundle/refs debug] bundle id 2: refcount 2 -> 1  
(0 mappings) del bundle_list list1
[1122374166.395670 /bundle/mapping debug] bundle id 3 del_bundle:  
deleting mapping [list1]
[1122374166.395746 /bundle/refs debug] bundle id 3: refcount 2 -> 1  
(0 mappings) del bundle_list list1
[1122374166.395823 /bundle/mapping debug] bundle id 4 del_bundle:  
deleting mapping [list1]
[1122374166.395964 /bundle/refs debug] bundle id 4: refcount 2 -> 1  
(0 mappings) del bundle_list list1
[1122374166.396054 /bundle/mapping debug] bundle id 6 del_bundle:  
deleting mapping [list1]
[1122374166.396131 /bundle/refs debug] bundle id 6: refcount 2 -> 1  
(0 mappings) del bundle_list list1
[1122374166.396213 /bundle/mapping debug] bundle id 7 del_bundle:  
deleting mapping [list1]
[1122374166.396297 /bundle/refs debug] bundle id 7: refcount 2 -> 1  
(0 mappings) del bundle_list list1
[1122374166.396373 /bundle/mapping debug] bundle id 8 del_bundle:  
deleting mapping [list1]
[1122374166.396452 /bundle/refs debug] bundle id 8: refcount 2 -> 1  
(0 mappings) del bundle_list list1
[1122374166.396529 /bundle/mapping debug] bundle id 9 del_bundle:  
deleting mapping [list1]
[1122374166.396611 /bundle/refs debug] bundle id 9: refcount 2 -> 1  
(0 mappings) del bundle_list list1
[1122374166.396690 /test debug] CHECK 'l1->size()' (0) == '0' (0)
[1122374166.396765 /test debug] CHECK (! l1->contains(bundles[i])) ok
[1122374166.396832 /test debug] CHECK (! l1->erase(bundles[i])) ok
[1122374166.396892 /test debug] CHECK 'bundles[i]->refcount()' (1) ==  
'1' (1)
[1122374166.396953 /test debug] CHECK 'bundles[i]->num_mappings 
()' (0) == '0' (0)
[1122374166.397019 /test debug] CHECK (! l1->contains(bundles[i])) ok
[1122374166.397082 /test debug] CHECK (! l1->erase(bundles[i])) ok
[1122374166.397141 /test debug] CHECK 'bundles[i]->refcount()' (1) ==  
'1' (1)
[1122374166.397201 /test debug] CHECK 'bundles[i]->num_mappings 
()' (0) == '0' (0)
[1122374166.397270 /test debug] CHECK (! l1->contains(bundles[i])) ok
[1122374166.397334 /test debug] CHECK (! l1->erase(bundles[i])) ok
[1122374166.397398 /test debug] CHECK 'bundles[i]->refcount()' (1) ==  
'1' (1)
[1122374166.397459 /test debug] CHECK 'bundles[i]->num_mappings 
()' (0) == '0' (0)
[1122374166.397524 /test debug] CHECK (! l1->contains(bundles[i])) ok
[1122374166.397587 /test debug] CHECK (! l1->erase(bundles[i])) ok
[1122374166.397645 /test debug] CHECK 'bundles[i]->refcount()' (1) ==  
'1' (1)
[1122374166.397706 /test debug] CHECK 'bundles[i]->num_mappings 
()' (0) == '0' (0)
[1122374166.397777 /test debug] CHECK (! l1->contains(bundles[i])) ok
[1122374166.397840 /test debug] CHECK (! l1->erase(bundles[i])) ok
[1122374166.397898 /test debug] CHECK 'bundles[i]->refcount()' (1) ==  
'1' (1)
[1122374166.397959 /test debug] CHECK 'bundles[i]->num_mappings 
()' (0) == '0' (0)
[1122374166.398027 /test debug] CHECK (! l1->contains(bundles[i])) ok
[1122374166.398097 /test debug] CHECK (! l1->erase(bundles[i])) ok
[1122374166.398156 /test debug] CHECK 'bundles[i]->refcount()' (1) ==  
'1' (1)
[1122374166.398216 /test debug] CHECK 'bundles[i]->num_mappings 
()' (0) == '0' (0)
[1122374166.398281 /test debug] CHECK (! l1->contains(bundles[i])) ok
[1122374166.398344 /test debug] CHECK (! l1->erase(bundles[i])) ok
[1122374166.398403 /test debug] CHECK 'bundles[i]->refcount()' (1) ==  
'1' (1)
[1122374166.398469 /test debug] CHECK 'bundles[i]->num_mappings 
()' (0) == '0' (0)
[1122374166.398534 /test debug] CHECK (! l1->contains(bundles[i])) ok
[1122374166.398597 /test debug] CHECK (! l1->erase(bundles[i])) ok
[1122374166.398656 /test debug] CHECK 'bundles[i]->refcount()' (1) ==  
'1' (1)
[1122374166.398716 /test debug] CHECK 'bundles[i]->num_mappings 
()' (0) == '0' (0)
[1122374166.398781 /test debug] CHECK (! l1->contains(bundles[i])) ok
[1122374166.398844 /test debug] CHECK (! l1->erase(bundles[i])) ok
[1122374166.398902 /test debug] CHECK 'bundles[i]->refcount()' (1) ==  
'1' (1)
[1122374166.398962 /test debug] CHECK 'bundles[i]->num_mappings 
()' (0) == '0' (0)
[1122374166.399027 /test debug] CHECK (! l1->contains(bundles[i])) ok
[1122374166.399090 /test debug] CHECK (! l1->erase(bundles[i])) ok
[1122374166.399152 /test debug] CHECK 'bundles[i]->refcount()' (1) ==  
'1' (1)
[1122374166.399213 /test debug] CHECK 'bundles[i]->num_mappings 
()' (0) == '0' (0)
ContainsAndErase... Passed
MultipleLists...
[1122374166.399390 /bundle/refs debug] bundle id 0: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.399485 /bundle/mapping debug] bundle id 0 add mapping  
[list1]
[1122374166.399631 /bundle/refs debug] bundle id 0: refcount 2 -> 3  
(1 mappings) add bundle_list list2
[1122374166.399719 /bundle/mapping debug] bundle id 0 add mapping  
[list2]
[1122374166.399846 /bundle/refs debug] bundle id 0: refcount 3 -> 4  
(2 mappings) add bundle_list list3
[1122374166.399935 /bundle/mapping debug] bundle id 0 add mapping  
[list3]
[1122374166.400015 /bundle/refs debug] bundle id 1: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.400090 /bundle/mapping debug] bundle id 1 add mapping  
[list1]
[1122374166.400172 /bundle/refs debug] bundle id 1: refcount 2 -> 3  
(1 mappings) add bundle_list list2
[1122374166.400313 /bundle/mapping debug] bundle id 1 add mapping  
[list2]
[1122374166.400398 /bundle/refs debug] bundle id 1: refcount 3 -> 4  
(2 mappings) add bundle_list list3
[1122374166.400472 /bundle/mapping debug] bundle id 1 add mapping  
[list3]
[1122374166.400550 /bundle/refs debug] bundle id 2: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.400626 /bundle/mapping debug] bundle id 2 add mapping  
[list1]
[1122374166.400702 /bundle/refs debug] bundle id 2: refcount 2 -> 3  
(1 mappings) add bundle_list list2
[1122374166.400776 /bundle/mapping debug] bundle id 2 add mapping  
[list2]
[1122374166.400852 /bundle/refs debug] bundle id 3: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.400925 /bundle/mapping debug] bundle id 3 add mapping  
[list1]
[1122374166.401007 /bundle/refs debug] bundle id 3: refcount 2 -> 3  
(1 mappings) add bundle_list list2
[1122374166.401080 /bundle/mapping debug] bundle id 3 add mapping  
[list2]
[1122374166.401169 /bundle/refs debug] bundle id 3: refcount 3 -> 4  
(2 mappings) add bundle_list list3
[1122374166.401244 /bundle/mapping debug] bundle id 3 add mapping  
[list3]
[1122374166.401322 /bundle/refs debug] bundle id 4: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.401395 /bundle/mapping debug] bundle id 4 add mapping  
[list1]
[1122374166.401470 /bundle/refs debug] bundle id 4: refcount 2 -> 3  
(1 mappings) add bundle_list list2
[1122374166.401543 /bundle/mapping debug] bundle id 4 add mapping  
[list2]
[1122374166.401620 /bundle/refs debug] bundle id 4: refcount 3 -> 4  
(2 mappings) add bundle_list list3
[1122374166.401693 /bundle/mapping debug] bundle id 4 add mapping  
[list3]
[1122374166.401770 /bundle/refs debug] bundle id 5: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.401843 /bundle/mapping debug] bundle id 5 add mapping  
[list1]
[1122374166.402260 /bundle/refs debug] bundle id 5: refcount 2 -> 3  
(1 mappings) add bundle_list list2
[1122374166.402374 /bundle/mapping debug] bundle id 5 add mapping  
[list2]
[1122374166.402463 /bundle/refs debug] bundle id 6: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.402541 /bundle/mapping debug] bundle id 6 add mapping  
[list1]
[1122374166.402624 /bundle/refs debug] bundle id 6: refcount 2 -> 3  
(1 mappings) add bundle_list list2
[1122374166.402698 /bundle/mapping debug] bundle id 6 add mapping  
[list2]
[1122374166.402776 /bundle/refs debug] bundle id 6: refcount 3 -> 4  
(2 mappings) add bundle_list list3
[1122374166.402851 /bundle/mapping debug] bundle id 6 add mapping  
[list3]
[1122374166.402929 /bundle/refs debug] bundle id 7: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.403004 /bundle/mapping debug] bundle id 7 add mapping  
[list1]
[1122374166.403080 /bundle/refs debug] bundle id 7: refcount 2 -> 3  
(1 mappings) add bundle_list list2
[1122374166.403154 /bundle/mapping debug] bundle id 7 add mapping  
[list2]
[1122374166.403231 /bundle/refs debug] bundle id 7: refcount 3 -> 4  
(2 mappings) add bundle_list list3
[1122374166.403305 /bundle/mapping debug] bundle id 7 add mapping  
[list3]
[1122374166.403383 /bundle/refs debug] bundle id 8: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.403458 /bundle/mapping debug] bundle id 8 add mapping  
[list1]
[1122374166.403534 /bundle/refs debug] bundle id 8: refcount 2 -> 3  
(1 mappings) add bundle_list list2
[1122374166.403631 /bundle/mapping debug] bundle id 8 add mapping  
[list2]
[1122374166.403724 /bundle/refs debug] bundle id 9: refcount 1 -> 2  
(0 mappings) add bundle_list list1
[1122374166.403804 /bundle/mapping debug] bundle id 9 add mapping  
[list1]
[1122374166.403881 /bundle/refs debug] bundle id 9: refcount 2 -> 3  
(1 mappings) add bundle_list list2
[1122374166.403961 /bundle/mapping debug] bundle id 9 add mapping  
[list2]
[1122374166.404039 /bundle/refs debug] bundle id 9: refcount 3 -> 4  
(2 mappings) add bundle_list list3
[1122374166.404113 /bundle/mapping debug] bundle id 9 add mapping  
[list3]
[1122374166.404192 /test debug] CHECK 'b->num_mappings()' (3) == '3' (3)
[1122374166.404328 /test debug] CHECK (l->contains(b)) ok
[1122374166.404431 /test debug] CHECK (l->contains(b)) ok
[1122374166.404500 /test debug] CHECK (l->contains(b)) ok
[1122374166.404572 /bundle/mapping debug] bundle id 0 del_bundle:  
deleting mapping [list1]
[1122374166.404653 /bundle/refs debug] bundle id 0: refcount 4 -> 3  
(2 mappings) del bundle_list list1
[1122374166.404731 /test debug] CHECK (l->erase(b)) ok
[1122374166.404798 /test debug] CHECK (! l->contains(b)) ok
Segmentation fault

Do you have a magic fix for this one too?  It could be related to my  
hack.  I could try running it in the debugger when I get home.

cheers,
Darren

Date: Mon, 25 Jul 2005 19:03:18 -0700
From: Michael Demmer <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] DTN2 (from CVS) problems on Mac OS X 10.4.2
Sender: [email-masked]
Reply-To: [email-masked]

> I got past this by using static_cast<unsigned int> for both of the  
> params  in the call to min in  
> oasys::StaticStringBuffer<_sz>::StaticStringBuffer(char*)

I fixed this in a slightly different way by changing the template
parameter to just be a size_t.

But in either event, this should work for you now (I hope).

> The second problem has me baffled though...can't spot the cause of  
> this warning/error in the code.

> // replace this fine looking code
> /*
>     if(bound == len_)
>     {
>         return std::pair<std::string, bool>(buf.c_str(), false);
>     }
>     else
>     {
>         return std::pair<std::string, bool>(buf.c_str(), true);
>     }
> */
> 
> // with this, which doesn't annoy the daft compiler
>      return std::pair<std::string, bool>(buf.c_str(), (bound ==  
> len_) ? false: true);
> 
> }

Seems like a bug in the compiler, since the code should be fine either
way. I guess I'll just check your change in since the two are
equivalent.

> Well, that compiles.  I don't get it.  Oh well.  Now I'm starting
> to see more size_t related issues, and giving up for bed...

I've fixed this one as well (actually it's been sitting for weeks on
my OS X machine at home...). But I found some others too, so at least
now it builds fine on my machine.

-m

From: Darren Long <[email-masked]>
Subject: Re: [dtn-users] DTN2 (from CVS) problems on Mac OS X 10.4.2
Date: Tue, 26 Jul 2005 00:30:33 +0100
To: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

Now tripping over during make with:

g++ -I.   -Wno-long-double -I/usr/local/BerkeleyDB.4.2/include -g - 
fno-inline  -MMD -MP -MT "io/PrettyPrintBuffer.o io/ 
PrettyPrintBuffer.E io/PrettyPrintBuffer.po" -Wall -Werror  -c io/ 
PrettyPrintBuffer.cc -o io/PrettyPrintBuffer.o
./util/StringBuffer.h: In constructor  
`oasys::StaticStringBuffer<_sz>::StaticStringBuffer(char*)':
./util/StringBuffer.h:204: error: call of overloaded 'min(unsigned  
int&, size_t&)' is ambiguous
./util/../util/IntUtils.h:61: note: candidates are: int oasys::min 
(int, int)
./util/../util/IntUtils.h:62: note:                 unsigned int  
oasys::min(unsigned int, unsigned int)
./util/../util/IntUtils.h:63: note:                 long int  
oasys::min(long int, long int)
./util/../util/IntUtils.h:64: note:                 long unsigned int  
oasys::min(long unsigned int, long unsigned int)
make[1]: *** [io/PrettyPrintBuffer.o] Error 1
make[1]: Leaving directory `/Users/darren/Source/DTN2/oasys'
make: *** [oasys] Error 2

The old "spoilt for choice" problem again ;-)

I got past this by using static_cast<unsigned int> for both of the  
params  in the call to min in  
oasys::StaticStringBuffer<_sz>::StaticStringBuffer(char*)

The second problem has me baffled though...can't spot the cause of  
this warning/error in the code.

make -w -C oasys
make[1]: Entering directory `/Users/darren/Source/DTN2/oasys'
g++ -I.   -Wno-long-double -I/usr/local/BerkeleyDB.4.2/include -g - 
fno-inline  -MMD -MP -MT "io/PrettyPrintBuffer.o io/ 
PrettyPrintBuffer.E io/PrettyPrintBuffer.po" -Wall -Werror  -c io/ 
PrettyPrintBuffer.cc -o io/PrettyPrintBuffer.o
cc1plus: warnings being treated as errors
io/PrettyPrintBuffer.cc: In member function `std::pair<std::string,  
bool> oasys::PrettyPrintBuf::next_str()':
io/PrettyPrintBuffer.cc:85: warning: control reaches end of non-void  
function
make[1]: *** [io/PrettyPrintBuffer.o] Error 1
make[1]: Leaving directory `/Users/darren/Source/DTN2/oasys'
make: *** [oasys] Error 2

Still, I hacked the following in frustration:

std::pair<std::string, bool>
PrettyPrintBuf::next_str()
{
     StringBuffer buf;

     int bound = std::min(cur_ + MAX_COL, len_);
     for(int i = cur_; i<bound; ++i, ++cur_)
     {
         switch(buf_[i])
         {
         case '\n': buf.append("\\n"); break;
         case '\r': buf.append("\\r"); break;
         case '\t': buf.append("\\t"); break;
         case '\0': buf.append("\\0"); break;

         default:
             buf.append(buf_[i]);
         }
     }
// replace this fine looking code
/*
     if(bound == len_)
     {
         return std::pair<std::string, bool>(buf.c_str(), false);
     }
     else
     {
         return std::pair<std::string, bool>(buf.c_str(), true);
     }
*/

// with this, which doesn't annoy the daft compiler
      return std::pair<std::string, bool>(buf.c_str(), (bound ==  
len_) ? false: true);

}

Well, that compiles.  I don't get it.  Oh well.  Now I'm starting to  
see more size_t related issues, and giving up for bed...

g++ -I.   -Wno-long-double -I/usr/local/BerkeleyDB.4.2/include -g - 
fno-inline  -MMD -MP -MT "storage/BerkeleyDBStore.o storage/ 
BerkeleyDBStore.E storage/BerkeleyDBStore.po" -Wall -Werror  -c  
storage/BerkeleyDBStore.cc -o storage/BerkeleyDBStore.o
cc1plus: warnings being treated as errors
storage/BerkeleyDBStore.cc: In member function `virtual int  
oasys::BerkeleyDBTable::put(const oasys::SerializableObject&, const  
oasys::SerializableObject*, int)':
storage/BerkeleyDBStore.cc:526: warning: format '%d' expects type  
'int', but argument 4 has type 'size_t'
make[1]: *** [storage/BerkeleyDBStore.o] Error 1
make[1]: Leaving directory `/Users/darren/Source/DTN2/oasys'
make: *** [oasys] Error 2

Darren

On 25 Jul 2005, at 21:57, Michael Demmer wrote:

>
> Should be fixed -- try to update and reconfigure and let me know if it
> works now. You should see a line in the configure output where it
> correctly identifies it as GCC 4.0.0.
>
> -m
>
>
>> That was quick!
>>
>> On 25 Jul 2005, at 20:06, Michael Demmer wrote:
>>
>>>
>>> Can you post the full output of gcc --version here.
>>>
>>
>>
>> Tiger's gcc reports:
>> powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 20041026 (Apple Computer,
>> Inc. build 4061)
>> Copyright (C) 2004 Free Software Foundation, Inc.
>> (plus some ass covering stuff)
>>
>> Darren
>> _______________________________________________
>> dtn-users mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-users
>>
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users
>

Date: Mon, 25 Jul 2005 13:57:59 -0700
From: Michael Demmer <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] DTN2 (from CVS) problems on Fedora Core 4 and Mac OS X 10.4.2
Sender: [email-masked]
Reply-To: [email-masked]

Should be fixed -- try to update and reconfigure and let me know if it
works now. You should see a line in the configure output where it
correctly identifies it as GCC 4.0.0.

-m

> That was quick!
> 
> On 25 Jul 2005, at 20:06, Michael Demmer wrote:
> >
> >Can you post the full output of gcc --version here.
> 
> 
> Tiger's gcc reports:
> powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 20041026 (Apple Computer,  
> Inc. build 4061)
> Copyright (C) 2004 Free Software Foundation, Inc.
> (plus some ass covering stuff)
> 
> Darren
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users

From: Darren Long <[email-masked]>
Subject: Re: [dtn-users] DTN2 (from CVS) problems on Fedora Core 4 and Mac OS X 10.4.2
Date: Mon, 25 Jul 2005 21:24:07 +0100
To: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

That was quick!

On 25 Jul 2005, at 20:06, Michael Demmer wrote:
>
> Can you post the full output of gcc --version here.

Tiger's gcc reports:
powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 20041026 (Apple Computer,  
Inc. build 4061)
Copyright (C) 2004 Free Software Foundation, Inc.
(plus some ass covering stuff)

Darren

Date: Mon, 25 Jul 2005 12:06:10 -0700
From: Michael Demmer <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] DTN2 (from CVS) problems on Fedora Core 4 and Mac OS X 10.4.2
Sender: [email-masked]
Reply-To: [email-masked]

> On FC4, it looked like
> 
>      DTNServer::init_dir(const char* dirname)
> 
> was being invoked with an empty string during make install.

Interesting -- this seems like it would be a problem on all
architectures (and is a legacy thing due to the old way of doing
command line options).

> I hacked tools/install.sh and removed the
>     -c ""
> from the dtnd invocation.

I've checked in this fix.

> That fixed it, at least to the dtnd prompt.  I haven't tried doing  
> anything more interesting yet, as I had royally screwed up my .conf  
> when trying to get on demand contacts running via incoming ssh  
> tunnels and haven't yet fixed it.  Any hints here would be
> appreciated.

Hrm. Maybe describe the problem more in detail? Run with -l debug will
give you more information.

> I don't know why this appears to have broken on FC4...the latest  
> install.sh file looks unchanged from my old build dirs.  BTW, running  
> V 4.0.0 of  gcc on FC4 happily.

As I said, this is confusing. It's probably just that no-one has
tested the install.sh script in a while :-)

> OK.  Now for Tiger (10.4.2). configure complains about the compiler:
> ...
> checking for the version of the gcc compiler... powerpc-apple- 
> darwin8-4.0.0
> error: unsupported compiler version powerpc-apple-darwin8-4.0.0
> 
> I'm using the latest fat binary version of the Mac OS X dev tools  
> (XCode 2.1) I think. Any suggestions, please?

Well, it turns out gcc doesn't have a nice cross-version way to spit
out the actual version of the compiler, so in oasys/aclocal/gcc.ac
you'll see a little sed stuff to try to reliably extract the version.

Can you post the full output of gcc --version here.

> Also, do the issues under Cygwin still exist?

Nope -- that should be all fixed.

Thanks for the efforts.

-m

To: [email-masked]
From: Darren Long <[email-masked]>
Date: Mon, 25 Jul 2005 19:44:04 +0100
Subject: [dtn-users] DTN2 (from CVS) problems on Fedora Core 4 and Mac OS X 10.4.2
Sender: [email-masked]
Reply-To: [email-masked]

Hi,

On 21 Jul 2005, at 21:51, Michael Demmer wrote:

> it would be good (for us) to
> have more OS coverage.
>

Well, you asked for it, Mike ;-)

Being a sucker for the latest thing, I have upgraded my Linux box  
from Fedora Core 3 to 4, and my iBook to Tiger (now Mac OS X  
10.4.2).  Both have broken DTN2 as built from today's CVS version.

On FC4, it looked like

      DTNServer::init_dir(const char* dirname)

was being invoked with an empty string during make install.

***
*** Installing dtn...
***

user account to use for the dtn daemon [dtn]: asif
install daemon setuid? [y]: n
creating dtn directories...
/var/dtn already exists... skipping
/var/dtn/bundles already exists... skipping
/var/dtn/db already exists... skipping
installing dtnd executable...
installing dtn applications: dtnsend... dtnrecv... dtnping...  
dtncp... dtncpd...
copying default configuration file to /etc/dtn.conf
running dtn daemon to create initial database...
[1122310545.901980 /dtnd info] random seed is 901969
[1122310545.902616 /dtnd info] No config file specified.
[1122310545.902741 /panic critical] PANIC at DTNServer.cc:281: can't  
create directory : No such file or directory
tools/install.sh: line 70: 26323 Aborted                 /usr/bin/ 
dtnd -c "" --init-db
installation complete.

I hacked tools/install.sh and removed the
     -c ""
from the dtnd invocation.

That fixed it, at least to the dtnd prompt.  I haven't tried doing  
anything more interesting yet, as I had royally screwed up my .conf  
when trying to get on demand contacts running via incoming ssh  
tunnels and haven't yet fixed it.  Any hints here would be appreciated.

I don't know why this appears to have broken on FC4...the latest  
install.sh file looks unchanged from my old build dirs.  BTW, running  
V 4.0.0 of  gcc on FC4 happily.

OK.  Now for Tiger (10.4.2). configure complains about the compiler:

checking compilation target... native
checking whether to compile with debugging... yes
checking whether to compile with memory debugging... no
checking whether to compile with optimization... no
checking whether to build and link using static tcl and db  
libraries... no
checking for a C compiler (trying gcc gcc-3.3 gcc-3.2 gcc-2.96 gcc296  
gcc-2.95 gcc295)...
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for a C++ compiler (trying g++ g++-3.3 g++-3.2 g++-2.96 g+ 
+296 g++-2.95 g++295)...
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking for a BSD-compatible install... /usr/bin/install -c
checking whether make sets $(MAKE)... yes
checking for ranlib... ranlib
checking for the version of the gcc compiler... powerpc-apple- 
darwin8-4.0.0
error: unsupported compiler version powerpc-apple-darwin8-4.0.0
>

I'm using the latest fat binary version of the Mac OS X dev tools  
(XCode 2.1) I think. Any suggestions, please?

Also, do the issues under Cygwin still exist?

cheers

Darren

Date: Thu, 21 Jul 2005 14:44:27 -0700
From: Joshua Schoolcraft <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] Fwd: Configure / compile under updated FC3?
Sender: [email-masked]
Reply-To: [email-masked]

Great, that fixed it.  Thanks, and I'll try and keep an updated box running it.

On 7/21/05, Michael Demmer <[email-masked]> wrote:
> 
> > Oops, I spoke too soon.
> >
> > compile error:
> >
> > make[1]: Entering directory `/home/dtn/DTN2/servlib'
> > g++ -I.. -I../servlib   -I/usr/local/BerkeleyDB.4.3/include  -g -fno-i
> > D -MP -MT "naming/SchemeTable.o naming/SchemeTable.E naming/SchemeTabl
> > l -Werror  -c naming/SchemeTable.cc -o naming/SchemeTable.o
> > naming/SchemeTable.cc:45: error: too few template-parameter-lists
> > make[1]: *** [naming/SchemeTable.o] Error 1
> > make[1]: Leaving directory `/home/dtn/DTN2/servlib'
> > make: *** [servlib] Error 2
> 
> Oops -- this is my fault. I didn't test with gcc 3.4 and the new
> compiler is more finicky when it comes to template stuff.
> 
> I've checked in a fix that should take care of the problem. If you
> don't mind sticking with the updated FC3, it would be good (for us) to
> have more OS coverage.
> 
> Thanks,
> -m
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users
>

Date: Thu, 21 Jul 2005 13:51:57 -0700
From: Michael Demmer <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] Fwd: Configure / compile under updated FC3?
Sender: [email-masked]
Reply-To: [email-masked]

> Oops, I spoke too soon.
> 
> compile error:
> 
> make[1]: Entering directory `/home/dtn/DTN2/servlib'
> g++ -I.. -I../servlib   -I/usr/local/BerkeleyDB.4.3/include  -g -fno-i
> D -MP -MT "naming/SchemeTable.o naming/SchemeTable.E naming/SchemeTabl
> l -Werror  -c naming/SchemeTable.cc -o naming/SchemeTable.o
> naming/SchemeTable.cc:45: error: too few template-parameter-lists
> make[1]: *** [naming/SchemeTable.o] Error 1
> make[1]: Leaving directory `/home/dtn/DTN2/servlib'
> make: *** [servlib] Error 2

Oops -- this is my fault. I didn't test with gcc 3.4 and the new
compiler is more finicky when it comes to template stuff.

I've checked in a fix that should take care of the problem. If you
don't mind sticking with the updated FC3, it would be good (for us) to
have more OS coverage.

Thanks,
-m

Date: Thu, 21 Jul 2005 13:11:14 -0700
From: Joshua Schoolcraft <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] Fwd: Configure / compile under updated FC3?
Sender: [email-masked]
Reply-To: [email-masked]

Oops, I spoke too soon.

compile error:

make[1]: Entering directory `/home/dtn/DTN2/servlib'
g++ -I.. -I../servlib   -I/usr/local/BerkeleyDB.4.3/include  -g -fno-i
D -MP -MT "naming/SchemeTable.o naming/SchemeTable.E naming/SchemeTabl
l -Werror  -c naming/SchemeTable.cc -o naming/SchemeTable.o
naming/SchemeTable.cc:45: error: too few template-parameter-lists
make[1]: *** [naming/SchemeTable.o] Error 1
make[1]: Leaving directory `/home/dtn/DTN2/servlib'
make: *** [servlib] Error 2

DTN2 compiles fine on an FC3 machine that hasn't been updated.  Looks
like I'll stick with that for now.

On 7/21/05, Joshua Schoolcraft <[email-masked]> wrote:
> When I tried to configure with the latest code, it made it past the
> original sticking point but then gave an error about the C compiler
> failing a sanity check.
> 
> Attempting to build BerkeleyDB yielded the same error, so I took
> drastic action and re-installed Fedora Core 3, and then brought it up
> to date once again.  There are no longer any issues with the configure
> or compile process for DTN2 on our machine.
> 
> On 7/19/05, Michael Demmer <[email-masked]> wrote:
> >
> > well -- i don't really know why this would be a problem for your
> > installation and not melissa's, but in any event, it turns out that
> > particular check is no longer necessary since i don't use the
> > std::string class in the same way for bundle payload data.
> >
> > i've checked in a new configure script that doesn't include the test
> > any more so it should be fine with your compiler.
> >
> > to be sure, in the DTN2 directory, run 'make tests' and then run
> > DTN2/test/unit_tests/bundle-payload-test. it should pass all the
> > various checks.
> >
> > -m
> >
> > > 'whereis g++' shows '/usr/bin/g++'
> > >
> > > then './configure CXX=/usr/bin/g++' gives:
> > >
> > > checking compilation target... native
> > > checking whether to compile with debugging... yes
> > > checking whether to compile with memory debugging... no
> > > checking whether to compile with optimization... no
> > > checking whether to build and link using static tcl and db libraries... no
> > > checking for a C compiler (trying gcc gcc-3.3 gcc-3.2 gcc-2.96 gcc296
> > > gcc-2.95 g cc295)...
> > > checking for gcc... gcc
> > > checking for C compiler default output... a.out
> > > checking whether the C compiler works... yes
> > > checking whether we are cross compiling... no
> > > checking for suffix of executables...
> > > checking for suffix of object files... o
> > > checking whether we are using the GNU C compiler... yes
> > > checking whether gcc accepts -g... yes
> > > checking for gcc option to accept ANSI C... none needed
> > > checking for a C++ compiler (trying g++ g++-3.3 g++-3.2 g++-2.96
> > > g++296 g++-2.95  g++295)...
> > > checking whether we are using the GNU C++ compiler... yes
> > > checking whether /usr/bin/g++ accepts -g... yes
> > > checking for gawk... gawk
> > > checking for a BSD-compatible install... /usr/bin/install -c
> > > checking whether make sets $(MAKE)... yes
> > > checking for ranlib... ranlib
> > > checking for the version of the gcc compiler... 3.4.3
> > > checking whether gcc accepts -Wno-long-double (Apple OSX only)... no
> > > checking whether std::string::reserve() is broken... yes
> > > configure: error: broken std::string::reserve() -- upgrade your compiler
> > >
> > >
> > > On 7/19/05, Melissa Ho <[email-masked]> wrote:
> > > > Did you try running configure with the CXX variable set?
> > > >
> > > > ./configure CXX=/wherever/g++/happens/to/be
> > > >
> > > > Based on your configure output, it looks like g++ wasn't found by
> > > > configure - probably because the default location for 3.4.3 may have
> > > > changed.
> > > >
> > > > Melissa
> > > >
> > > > On 7/19/05, Joshua Schoolcraft <[email-masked]> wrote:
> > > > > Issuing a 'g++ -v' gives the following output:
> > > > >
> > > > > Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.3/specs
> > > > > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> > > > > --infodir=/usr/share/info --enable-shared --enable-threads=posix
> > > > > --disable-checking --with-system-zlib --enable-__cxa_atexit
> > > > > --disable-libunwind-exceptions --enable-java-awt=gtk
> > > > > --host=i386-redhat-linux
> > > > > Thread model: posix
> > > > > gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)
> > > > >
> > > > > On 7/18/05, Melissa Ho <[email-masked]> wrote:
> > > > > > happened with your g++.  Can you make sure you are
> > > > > _______________________________________________
> > > > > dtn-users mailing list
> > > > > [email-masked]
> > > > > http://mailman.dtnrg.org/mailman/listinfo/dtn-users
> > > > >
> > > > _______________________________________________
> > > > dtn-users mailing list
> > > > [email-masked]
> > > > http://mailman.dtnrg.org/mailman/listinfo/dtn-users
> > > >
> > > _______________________________________________
> > > dtn-users mailing list
> > > [email-masked]
> > > http://mailman.dtnrg.org/mailman/listinfo/dtn-users
> > _______________________________________________
> > dtn-users mailing list
> > [email-masked]
> > http://mailman.dtnrg.org/mailman/listinfo/dtn-users
> >
>

Date: Thu, 21 Jul 2005 13:07:00 -0700
From: Joshua Schoolcraft <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] Fwd: Configure / compile under updated FC3?
Sender: [email-masked]
Reply-To: [email-masked]

When I tried to configure with the latest code, it made it past the
original sticking point but then gave an error about the C compiler
failing a sanity check.

Attempting to build BerkeleyDB yielded the same error, so I took
drastic action and re-installed Fedora Core 3, and then brought it up
to date once again.  There are no longer any issues with the configure
or compile process for DTN2 on our machine.

On 7/19/05, Michael Demmer <[email-masked]> wrote:
> 
> well -- i don't really know why this would be a problem for your
> installation and not melissa's, but in any event, it turns out that
> particular check is no longer necessary since i don't use the
> std::string class in the same way for bundle payload data.
> 
> i've checked in a new configure script that doesn't include the test
> any more so it should be fine with your compiler.
> 
> to be sure, in the DTN2 directory, run 'make tests' and then run
> DTN2/test/unit_tests/bundle-payload-test. it should pass all the
> various checks.
> 
> -m 
> 
> > 'whereis g++' shows '/usr/bin/g++'
> >
> > then './configure CXX=/usr/bin/g++' gives:
> >
> > checking compilation target... native
> > checking whether to compile with debugging... yes
> > checking whether to compile with memory debugging... no
> > checking whether to compile with optimization... no
> > checking whether to build and link using static tcl and db libraries... no
> > checking for a C compiler (trying gcc gcc-3.3 gcc-3.2 gcc-2.96 gcc296
> > gcc-2.95 g cc295)...
> > checking for gcc... gcc
> > checking for C compiler default output... a.out
> > checking whether the C compiler works... yes
> > checking whether we are cross compiling... no
> > checking for suffix of executables...
> > checking for suffix of object files... o
> > checking whether we are using the GNU C compiler... yes
> > checking whether gcc accepts -g... yes
> > checking for gcc option to accept ANSI C... none needed
> > checking for a C++ compiler (trying g++ g++-3.3 g++-3.2 g++-2.96
> > g++296 g++-2.95  g++295)...
> > checking whether we are using the GNU C++ compiler... yes
> > checking whether /usr/bin/g++ accepts -g... yes
> > checking for gawk... gawk
> > checking for a BSD-compatible install... /usr/bin/install -c
> > checking whether make sets $(MAKE)... yes
> > checking for ranlib... ranlib
> > checking for the version of the gcc compiler... 3.4.3
> > checking whether gcc accepts -Wno-long-double (Apple OSX only)... no
> > checking whether std::string::reserve() is broken... yes
> > configure: error: broken std::string::reserve() -- upgrade your compiler
> >
> >
> > On 7/19/05, Melissa Ho <[email-masked]> wrote:
> > > Did you try running configure with the CXX variable set?
> > >
> > > ./configure CXX=/wherever/g++/happens/to/be
> > >
> > > Based on your configure output, it looks like g++ wasn't found by
> > > configure - probably because the default location for 3.4.3 may have
> > > changed.
> > >
> > > Melissa
> > >
> > > On 7/19/05, Joshua Schoolcraft <[email-masked]> wrote:
> > > > Issuing a 'g++ -v' gives the following output:
> > > >
> > > > Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.3/specs
> > > > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> > > > --infodir=/usr/share/info --enable-shared --enable-threads=posix
> > > > --disable-checking --with-system-zlib --enable-__cxa_atexit
> > > > --disable-libunwind-exceptions --enable-java-awt=gtk
> > > > --host=i386-redhat-linux
> > > > Thread model: posix
> > > > gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)
> > > >
> > > > On 7/18/05, Melissa Ho <[email-masked]> wrote:
> > > > > happened with your g++.  Can you make sure you are
> > > > _______________________________________________
> > > > dtn-users mailing list
> > > > [email-masked]
> > > > http://mailman.dtnrg.org/mailman/listinfo/dtn-users
> > > >
> > > _______________________________________________
> > > dtn-users mailing list
> > > [email-masked]
> > > http://mailman.dtnrg.org/mailman/listinfo/dtn-users
> > >
> > _______________________________________________
> > dtn-users mailing list
> > [email-masked]
> > http://mailman.dtnrg.org/mailman/listinfo/dtn-users
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users
>

Date: Wed, 20 Jul 2005 10:43:56 -0700
From: Michael Demmer <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] Bundle Protocol Specification and Implementation
Sender: [email-masked]
Reply-To: [email-masked]

the reference implementation does NOT currently support the message
format specifications in the current version of the specification,
though i plan to add support for it before the next release. 

given some personal scheduling conflicts and the rather significant
protocol changes from the last version, i'm doubtful that will happen
before september of this year, though it's possible.  

-m

> hi, there:
> 
> There are some changes about the Bundle Header/signal formats in the new 
> specification document draft-irtf-dtnrg-bundle-spec-03.txt compared to the 
> previous version.
> 
> I would like to know whether the bundles generated by the DTN2 code always 
> follow the format specifications. If we develop a program generating 
> bundles strictly according to the latest specifications, is the node 
> running our program able to talk to another node running DTN2?
> 
> thx.
> 
> rgds,
> Yang 
> 
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users

From: "Yang Chen" <[email-masked]>
To: <[email-masked]>
Date: Wed, 20 Jul 2005 10:52:06 -0400
X-Spam-Report-$ThisHost: ---- Start SpamAssassin (v2.6xx-cscf) results -4.9 BAYES_00               BODY: Bayesian spam probability is 0 to 1% [score: 0.0000]
X-MIMEDefang-Relay-1852595aaf0946a4530a11f79d6f33e3dfd75698: 128.119.40.196
X-Scanned-By: MIMEDefang 2.43
Subject: [dtn-users] Bundle Protocol Specification and Implementation
Sender: [email-masked]
Errors-To: [email-masked]
X-BeenThere: [email-masked]
X-Mailman-Version: 2.0.13
Precedence: bulk
Reply-To: [email-masked]
List-Unsubscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-users>, <mailto:[email-masked]?subject=unsubscribe>
List-Id: discussion/answers list for users of the dtn reference implementation <dtn-users.mailman.dtnrg.org>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-users>, <mailto:[email-masked]?subject=subscribe>
List-Archive: <http://mailman.dtnrg.org/pipermail/dtn-users/>

hi, there:

There are some changes about the Bundle Header/signal formats in the new 
specification document draft-irtf-dtnrg-bundle-spec-03.txt compared to the 
previous version.

I would like to know whether the bundles generated by the DTN2 code always 
follow the format specifications. If we develop a program generating bundles 
strictly according to the latest specifications, is the node running our 
program able to talk to another node running DTN2?

thx.

rgds,
Yang 

Date: Tue, 19 Jul 2005 17:36:17 -0700
From: Michael Demmer <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] Fwd: Configure / compile under updated FC3?
Sender: [email-masked]
Reply-To: [email-masked]

well -- i don't really know why this would be a problem for your
installation and not melissa's, but in any event, it turns out that
particular check is no longer necessary since i don't use the
std::string class in the same way for bundle payload data.

i've checked in a new configure script that doesn't include the test
any more so it should be fine with your compiler.

to be sure, in the DTN2 directory, run 'make tests' and then run 
DTN2/test/unit_tests/bundle-payload-test. it should pass all the
various checks.

-m

> 'whereis g++' shows '/usr/bin/g++'
> 
> then './configure CXX=/usr/bin/g++' gives:
> 
> checking compilation target... native
> checking whether to compile with debugging... yes
> checking whether to compile with memory debugging... no
> checking whether to compile with optimization... no
> checking whether to build and link using static tcl and db libraries... no
> checking for a C compiler (trying gcc gcc-3.3 gcc-3.2 gcc-2.96 gcc296
> gcc-2.95 g cc295)...
> checking for gcc... gcc
> checking for C compiler default output... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables...
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ANSI C... none needed
> checking for a C++ compiler (trying g++ g++-3.3 g++-3.2 g++-2.96
> g++296 g++-2.95  g++295)...
> checking whether we are using the GNU C++ compiler... yes
> checking whether /usr/bin/g++ accepts -g... yes
> checking for gawk... gawk
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether make sets $(MAKE)... yes
> checking for ranlib... ranlib
> checking for the version of the gcc compiler... 3.4.3
> checking whether gcc accepts -Wno-long-double (Apple OSX only)... no
> checking whether std::string::reserve() is broken... yes
> configure: error: broken std::string::reserve() -- upgrade your compiler
> 
> 
> On 7/19/05, Melissa Ho <[email-masked]> wrote:
> > Did you try running configure with the CXX variable set?
> > 
> > ./configure CXX=/wherever/g++/happens/to/be
> > 
> > Based on your configure output, it looks like g++ wasn't found by
> > configure - probably because the default location for 3.4.3 may have
> > changed.
> > 
> > Melissa
> > 
> > On 7/19/05, Joshua Schoolcraft <[email-masked]> wrote:
> > > Issuing a 'g++ -v' gives the following output:
> > >
> > > Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.3/specs
> > > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> > > --infodir=/usr/share/info --enable-shared --enable-threads=posix
> > > --disable-checking --with-system-zlib --enable-__cxa_atexit
> > > --disable-libunwind-exceptions --enable-java-awt=gtk
> > > --host=i386-redhat-linux
> > > Thread model: posix
> > > gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)
> > >
> > > On 7/18/05, Melissa Ho <[email-masked]> wrote:
> > > > happened with your g++.  Can you make sure you are
> > > _______________________________________________
> > > dtn-users mailing list
> > > [email-masked]
> > > http://mailman.dtnrg.org/mailman/listinfo/dtn-users
> > >
> > _______________________________________________
> > dtn-users mailing list
> > [email-masked]
> > http://mailman.dtnrg.org/mailman/listinfo/dtn-users
> >
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users

Date: Tue, 19 Jul 2005 15:50:01 -0700
From: Joshua Schoolcraft <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] Fwd: Configure / compile under updated FC3?
Sender: [email-masked]
Reply-To: [email-masked]

'whereis g++' shows '/usr/bin/g++'

then './configure CXX=/usr/bin/g++' gives:

checking compilation target... native
checking whether to compile with debugging... yes
checking whether to compile with memory debugging... no
checking whether to compile with optimization... no
checking whether to build and link using static tcl and db libraries... no
checking for a C compiler (trying gcc gcc-3.3 gcc-3.2 gcc-2.96 gcc296
gcc-2.95 g cc295)...
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for a C++ compiler (trying g++ g++-3.3 g++-3.2 g++-2.96
g++296 g++-2.95  g++295)...
checking whether we are using the GNU C++ compiler... yes
checking whether /usr/bin/g++ accepts -g... yes
checking for gawk... gawk
checking for a BSD-compatible install... /usr/bin/install -c
checking whether make sets $(MAKE)... yes
checking for ranlib... ranlib
checking for the version of the gcc compiler... 3.4.3
checking whether gcc accepts -Wno-long-double (Apple OSX only)... no
checking whether std::string::reserve() is broken... yes
configure: error: broken std::string::reserve() -- upgrade your compiler

On 7/19/05, Melissa Ho <[email-masked]> wrote:
> Did you try running configure with the CXX variable set?
> 
> ./configure CXX=/wherever/g++/happens/to/be
> 
> Based on your configure output, it looks like g++ wasn't found by
> configure - probably because the default location for 3.4.3 may have
> changed.
> 
> Melissa
> 
> On 7/19/05, Joshua Schoolcraft <[email-masked]> wrote:
> > Issuing a 'g++ -v' gives the following output:
> >
> > Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.3/specs
> > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> > --infodir=/usr/share/info --enable-shared --enable-threads=posix
> > --disable-checking --with-system-zlib --enable-__cxa_atexit
> > --disable-libunwind-exceptions --enable-java-awt=gtk
> > --host=i386-redhat-linux
> > Thread model: posix
> > gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)
> >
> > On 7/18/05, Melissa Ho <[email-masked]> wrote:
> > > happened with your g++.  Can you make sure you are
> > _______________________________________________
> > dtn-users mailing list
> > [email-masked]
> > http://mailman.dtnrg.org/mailman/listinfo/dtn-users
> >
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users
>

Date: Tue, 19 Jul 2005 15:17:00 -0700
From: Melissa Ho <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] Fwd: Configure / compile under updated FC3?
Sender: [email-masked]
Reply-To: [email-masked]

Did you try running configure with the CXX variable set?

./configure CXX=/wherever/g++/happens/to/be

Based on your configure output, it looks like g++ wasn't found by
configure - probably because the default location for 3.4.3 may have
changed.

Melissa

On 7/19/05, Joshua Schoolcraft <[email-masked]> wrote:
> Issuing a 'g++ -v' gives the following output:
> 
> Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.3/specs
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> --infodir=/usr/share/info --enable-shared --enable-threads=posix
> --disable-checking --with-system-zlib --enable-__cxa_atexit
> --disable-libunwind-exceptions --enable-java-awt=gtk
> --host=i386-redhat-linux
> Thread model: posix
> gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)
> 
> On 7/18/05, Melissa Ho <[email-masked]> wrote:
> > happened with your g++.  Can you make sure you are
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users
>

Date: Tue, 19 Jul 2005 15:08:14 -0700
From: Joshua Schoolcraft <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] Fwd: Configure / compile under updated FC3?
Sender: [email-masked]
Reply-To: [email-masked]

Issuing a 'g++ -v' gives the following output:

Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk
--host=i386-redhat-linux
Thread model: posix
gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)

On 7/18/05, Melissa Ho <[email-masked]> wrote:
> happened with your g++.  Can you make sure you are

Date: Mon, 18 Jul 2005 22:51:36 -0700
From: Melissa Ho <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] Fwd: Configure / compile under updated FC3?
Sender: [email-masked]
Reply-To: [email-masked]

Okay, after a day of updating (i haven't done it in a while), my FC3
laptop configures DTN2 without a problem.

However, taking a look at your configure output, I suspect something
bad happened with your g++.  Can you make sure you are using the gnu
C++ compiler?   That's where std::string::reserve() seems to be
broken.

Melissa

On 7/18/05, Esther H Jennings <[email-masked]> wrote:
> Hi Joshua,
> 
> Is there any DARPA DTN machine that I can take to my office so that I can try to install FC3 and DTN2 on it?  I'll try to see if I can help you bring these machines up.
> 
> Esther
> 
> -----------------------------------------------
> Esther Jennings, Ph.D.
> Communications Networks Group (332M)
> Jet Propulsion Laboratory
> 4800 Oak Grove Drive, M/S 238-343
> Pasadena, CA 91109-8099
> (818)354 1390   FAX: (818)393-1717
> Email: [email-masked]
> 
> ----- Original Message -----
> From: Joshua Schoolcraft <[email-masked]>
> Date: Monday, July 18, 2005 4:04 pm
> Subject: Re: [dtn-users] Fwd: Configure / compile under updated FC3?
> 
> > I still am unable to get ./configure to complete on yum-updated FC3.
> >
> > Josh
> >
> > On 7/18/05, Michael Demmer <[email-masked]> wrote:
> > >
> > > Is this still a problem? I looked quickly and I'm not even sure that
> > > the configure check is necessary any more, so if this is still
> > causing> headaches, let me know and I can remove the check.
> > >
> > > -m
> > >
> > > > I'll look into it later today and see what I can do. Although
> > I have
> > > > FC3 on my laptop, and haven't had any problems with
> > configure/compile> > thus far. I suspect you may need a patch to
> > configure for the new
> > > > version of yum.
> > > >
> > > > Melissa
> > > >
> > > > On 7/11/05, Joshua Schoolcraft <[email-masked]> wrote:
> > > > > This is perhaps more a more appropriate question for the
> > users mailing list.
> > > > >
> > > > > ---------- Forwarded message ----------
> > > > > From: Joshua Schoolcraft <[email-masked]>
> > > > > Date: Jul 8, 2005 3:13 PM
> > > > > Subject: Configure / compile under updated FC3?
> > > > > To: [email-masked]
> > > > >
> > > > >
> > > > > Hello,
> > > > >
> > > > > I'm trying to compile DTN2 in Fedora Core 3, but I run into
> > an issue
> > > > > with ./configure:
> > > > >
> > > > > checking compilation target... native
> > > > > checking whether to compile with debugging... yes
> > > > > checking whether to compile with memory debugging... no
> > > > > checking whether to compile with optimization... no
> > > > > checking whether to build and link using static tcl and db
> > libraries... no
> > > > > checking for a C compiler (trying gcc gcc-3.3 gcc-3.2 gcc-
> > 2.96 gcc296
> > > > > gcc-2.95 gcc295)...
> > > > > checking for gcc... gcc
> > > > > checking for C compiler default output... a.out
> > > > > checking whether the C compiler works... yes
> > > > > checking whether we are cross compiling... no
> > > > > checking for suffix of executables...
> > > > > checking for suffix of object files... o
> > > > > checking whether we are using the GNU C compiler... yes
> > > > > checking whether gcc accepts -g... yes
> > > > > checking for gcc option to accept ANSI C... none needed
> > > > > checking for a C++ compiler (trying g++ g++-3.3 g++-3.2 g++-2.96
> > > > > g++296 g++-2.95 g++295)...
> > > > > checking for g++... no
> > > > > checking for g++-3.3... no
> > > > > checking for g++-3.2... no
> > > > > checking for g++-2.96... no
> > > > > checking for g++296... no
> > > > > checking for g++-2.95... no
> > > > > checking for g++295... no
> > > > > checking whether we are using the GNU C++ compiler... no
> > > > > checking whether g++ accepts -g... no
> > > > > checking for gawk... gawk
> > > > > checking for a BSD-compatible install... /usr/bin/install -c
> > > > > checking whether make sets $(MAKE)... yes
> > > > > checking for ranlib... ranlib
> > > > > checking for the version of the gcc compiler... 3.4.3
> > > > > checking whether gcc accepts -Wno-long-double (Apple OSX
> > only)... no
> > > > > checking whether std::string::reserve() is broken... yes
> > > > > configure: error: broken std::string::reserve() -- upgrade
> > your compiler
> > > > >
> > > > > The installation of Fedora Core 3 was updated with yum
> > recently, and
> > > > > gcc is version 3.4.3-22.  Does anyone know how to deal with
> > this?  A
> > > > > Google search for broken std::string::reserve() didn't turn
> > up much.
> > > > >
> > > > > Thanks,
> > > > > Josh
> > > > > _______________________________________________
> > > > > dtn-users mailing list
> > > > > [email-masked]
> > > > > http://mailman.dtnrg.org/mailman/listinfo/dtn-users
> > > > >
> > > > _______________________________________________
> > > > dtn-users mailing list
> > > > [email-masked]
> > > > http://mailman.dtnrg.org/mailman/listinfo/dtn-users
> > > _______________________________________________
> > > dtn-users mailing list
> > > [email-masked]
> > > http://mailman.dtnrg.org/mailman/listinfo/dtn-users
> > >
> > _______________________________________________
> > dtn-users mailing list
> > [email-masked]
> > http://mailman.dtnrg.org/mailman/listinfo/dtn-users
> >
> 
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users
>

From: Esther H Jennings <[email-masked]>
To: [email-masked]
Date: Mon, 18 Jul 2005 18:42:02 -0700
Subject: Re: [dtn-users] Fwd: Configure / compile under updated FC3?
Priority: normal
Sender: [email-masked]
Reply-To: [email-masked]

Hi Joshua,

Is there any DARPA DTN machine that I can take to my office so that I can try to install FC3 and DTN2 on it?  I'll try to see if I can help you bring these machines up.

Esther

-----------------------------------------------
Esther Jennings, Ph.D.
Communications Networks Group (332M)
Jet Propulsion Laboratory
4800 Oak Grove Drive, M/S 238-343
Pasadena, CA 91109-8099
(818)354 1390   FAX: (818)393-1717
Email: [email-masked]

----- Original Message -----
From: Joshua Schoolcraft <[email-masked]>
Date: Monday, July 18, 2005 4:04 pm
Subject: Re: [dtn-users] Fwd: Configure / compile under updated FC3?

> I still am unable to get ./configure to complete on yum-updated FC3.
> 
> Josh
> 
> On 7/18/05, Michael Demmer <[email-masked]> wrote:
> > 
> > Is this still a problem? I looked quickly and I'm not even sure that
> > the configure check is necessary any more, so if this is still 
> causing> headaches, let me know and I can remove the check.
> > 
> > -m
> > 
> > > I'll look into it later today and see what I can do. Although 
> I have
> > > FC3 on my laptop, and haven't had any problems with 
> configure/compile> > thus far. I suspect you may need a patch to 
> configure for the new
> > > version of yum.
> > >
> > > Melissa
> > >
> > > On 7/11/05, Joshua Schoolcraft <[email-masked]> wrote:
> > > > This is perhaps more a more appropriate question for the 
> users mailing list.
> > > >
> > > > ---------- Forwarded message ----------
> > > > From: Joshua Schoolcraft <[email-masked]>
> > > > Date: Jul 8, 2005 3:13 PM
> > > > Subject: Configure / compile under updated FC3?
> > > > To: [email-masked]
> > > >
> > > >
> > > > Hello,
> > > >
> > > > I'm trying to compile DTN2 in Fedora Core 3, but I run into 
> an issue
> > > > with ./configure:
> > > >
> > > > checking compilation target... native
> > > > checking whether to compile with debugging... yes
> > > > checking whether to compile with memory debugging... no
> > > > checking whether to compile with optimization... no
> > > > checking whether to build and link using static tcl and db 
> libraries... no
> > > > checking for a C compiler (trying gcc gcc-3.3 gcc-3.2 gcc-
> 2.96 gcc296
> > > > gcc-2.95 gcc295)...
> > > > checking for gcc... gcc
> > > > checking for C compiler default output... a.out
> > > > checking whether the C compiler works... yes
> > > > checking whether we are cross compiling... no
> > > > checking for suffix of executables...
> > > > checking for suffix of object files... o
> > > > checking whether we are using the GNU C compiler... yes
> > > > checking whether gcc accepts -g... yes
> > > > checking for gcc option to accept ANSI C... none needed
> > > > checking for a C++ compiler (trying g++ g++-3.3 g++-3.2 g++-2.96
> > > > g++296 g++-2.95 g++295)...
> > > > checking for g++... no
> > > > checking for g++-3.3... no
> > > > checking for g++-3.2... no
> > > > checking for g++-2.96... no
> > > > checking for g++296... no
> > > > checking for g++-2.95... no
> > > > checking for g++295... no
> > > > checking whether we are using the GNU C++ compiler... no
> > > > checking whether g++ accepts -g... no
> > > > checking for gawk... gawk
> > > > checking for a BSD-compatible install... /usr/bin/install -c
> > > > checking whether make sets $(MAKE)... yes
> > > > checking for ranlib... ranlib
> > > > checking for the version of the gcc compiler... 3.4.3
> > > > checking whether gcc accepts -Wno-long-double (Apple OSX 
> only)... no
> > > > checking whether std::string::reserve() is broken... yes
> > > > configure: error: broken std::string::reserve() -- upgrade 
> your compiler
> > > >
> > > > The installation of Fedora Core 3 was updated with yum 
> recently, and
> > > > gcc is version 3.4.3-22.  Does anyone know how to deal with 
> this?  A
> > > > Google search for broken std::string::reserve() didn't turn 
> up much.
> > > >
> > > > Thanks,
> > > > Josh
> > > > _______________________________________________
> > > > dtn-users mailing list
> > > > [email-masked]
> > > > http://mailman.dtnrg.org/mailman/listinfo/dtn-users
> > > >
> > > _______________________________________________
> > > dtn-users mailing list
> > > [email-masked]
> > > http://mailman.dtnrg.org/mailman/listinfo/dtn-users
> > _______________________________________________
> > dtn-users mailing list
> > [email-masked]
> > http://mailman.dtnrg.org/mailman/listinfo/dtn-users
> >
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users
> 

Date: Mon, 18 Jul 2005 16:04:22 -0700
From: Joshua Schoolcraft <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] Fwd: Configure / compile under updated FC3?
Sender: [email-masked]
Reply-To: [email-masked]

I still am unable to get ./configure to complete on yum-updated FC3.

Josh

On 7/18/05, Michael Demmer <[email-masked]> wrote:
> 
> Is this still a problem? I looked quickly and I'm not even sure that
> the configure check is necessary any more, so if this is still causing
> headaches, let me know and I can remove the check.
> 
> -m
> 
> > I'll look into it later today and see what I can do. Although I have
> > FC3 on my laptop, and haven't had any problems with configure/compile
> > thus far. I suspect you may need a patch to configure for the new
> > version of yum.
> >
> > Melissa
> >
> > On 7/11/05, Joshua Schoolcraft <[email-masked]> wrote:
> > > This is perhaps more a more appropriate question for the users mailing list.
> > >
> > > ---------- Forwarded message ----------
> > > From: Joshua Schoolcraft <[email-masked]>
> > > Date: Jul 8, 2005 3:13 PM
> > > Subject: Configure / compile under updated FC3?
> > > To: [email-masked]
> > >
> > >
> > > Hello,
> > >
> > > I'm trying to compile DTN2 in Fedora Core 3, but I run into an issue
> > > with ./configure:
> > >
> > > checking compilation target... native
> > > checking whether to compile with debugging... yes
> > > checking whether to compile with memory debugging... no
> > > checking whether to compile with optimization... no
> > > checking whether to build and link using static tcl and db libraries... no
> > > checking for a C compiler (trying gcc gcc-3.3 gcc-3.2 gcc-2.96 gcc296
> > > gcc-2.95 gcc295)...
> > > checking for gcc... gcc
> > > checking for C compiler default output... a.out
> > > checking whether the C compiler works... yes
> > > checking whether we are cross compiling... no
> > > checking for suffix of executables...
> > > checking for suffix of object files... o
> > > checking whether we are using the GNU C compiler... yes
> > > checking whether gcc accepts -g... yes
> > > checking for gcc option to accept ANSI C... none needed
> > > checking for a C++ compiler (trying g++ g++-3.3 g++-3.2 g++-2.96
> > > g++296 g++-2.95 g++295)...
> > > checking for g++... no
> > > checking for g++-3.3... no
> > > checking for g++-3.2... no
> > > checking for g++-2.96... no
> > > checking for g++296... no
> > > checking for g++-2.95... no
> > > checking for g++295... no
> > > checking whether we are using the GNU C++ compiler... no
> > > checking whether g++ accepts -g... no
> > > checking for gawk... gawk
> > > checking for a BSD-compatible install... /usr/bin/install -c
> > > checking whether make sets $(MAKE)... yes
> > > checking for ranlib... ranlib
> > > checking for the version of the gcc compiler... 3.4.3
> > > checking whether gcc accepts -Wno-long-double (Apple OSX only)... no
> > > checking whether std::string::reserve() is broken... yes
> > > configure: error: broken std::string::reserve() -- upgrade your compiler
> > >
> > > The installation of Fedora Core 3 was updated with yum recently, and
> > > gcc is version 3.4.3-22.  Does anyone know how to deal with this?  A
> > > Google search for broken std::string::reserve() didn't turn up much.
> > >
> > > Thanks,
> > > Josh
> > > _______________________________________________
> > > dtn-users mailing list
> > > [email-masked]
> > > http://mailman.dtnrg.org/mailman/listinfo/dtn-users
> > >
> > _______________________________________________
> > dtn-users mailing list
> > [email-masked]
> > http://mailman.dtnrg.org/mailman/listinfo/dtn-users
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users
>

Date: Mon, 18 Jul 2005 13:04:25 -0700
From: Michael Demmer <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] Fwd: Configure / compile under updated FC3?
Sender: [email-masked]
Reply-To: [email-masked]

Is this still a problem? I looked quickly and I'm not even sure that
the configure check is necessary any more, so if this is still causing
headaches, let me know and I can remove the check.

-m

> I'll look into it later today and see what I can do. Although I have
> FC3 on my laptop, and haven't had any problems with configure/compile
> thus far. I suspect you may need a patch to configure for the new
> version of yum.
> 
> Melissa
> 
> On 7/11/05, Joshua Schoolcraft <[email-masked]> wrote:
> > This is perhaps more a more appropriate question for the users mailing list.
> > 
> > ---------- Forwarded message ----------
> > From: Joshua Schoolcraft <[email-masked]>
> > Date: Jul 8, 2005 3:13 PM
> > Subject: Configure / compile under updated FC3?
> > To: [email-masked]
> > 
> > 
> > Hello,
> > 
> > I'm trying to compile DTN2 in Fedora Core 3, but I run into an issue
> > with ./configure:
> > 
> > checking compilation target... native
> > checking whether to compile with debugging... yes
> > checking whether to compile with memory debugging... no
> > checking whether to compile with optimization... no
> > checking whether to build and link using static tcl and db libraries... no
> > checking for a C compiler (trying gcc gcc-3.3 gcc-3.2 gcc-2.96 gcc296
> > gcc-2.95 gcc295)...
> > checking for gcc... gcc
> > checking for C compiler default output... a.out
> > checking whether the C compiler works... yes
> > checking whether we are cross compiling... no
> > checking for suffix of executables...
> > checking for suffix of object files... o
> > checking whether we are using the GNU C compiler... yes
> > checking whether gcc accepts -g... yes
> > checking for gcc option to accept ANSI C... none needed
> > checking for a C++ compiler (trying g++ g++-3.3 g++-3.2 g++-2.96
> > g++296 g++-2.95 g++295)...
> > checking for g++... no
> > checking for g++-3.3... no
> > checking for g++-3.2... no
> > checking for g++-2.96... no
> > checking for g++296... no
> > checking for g++-2.95... no
> > checking for g++295... no
> > checking whether we are using the GNU C++ compiler... no
> > checking whether g++ accepts -g... no
> > checking for gawk... gawk
> > checking for a BSD-compatible install... /usr/bin/install -c
> > checking whether make sets $(MAKE)... yes
> > checking for ranlib... ranlib
> > checking for the version of the gcc compiler... 3.4.3
> > checking whether gcc accepts -Wno-long-double (Apple OSX only)... no
> > checking whether std::string::reserve() is broken... yes
> > configure: error: broken std::string::reserve() -- upgrade your compiler
> > 
> > The installation of Fedora Core 3 was updated with yum recently, and
> > gcc is version 3.4.3-22.  Does anyone know how to deal with this?  A
> > Google search for broken std::string::reserve() didn't turn up much.
> > 
> > Thanks,
> > Josh
> > _______________________________________________
> > dtn-users mailing list
> > [email-masked]
> > http://mailman.dtnrg.org/mailman/listinfo/dtn-users
> >
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users

Date: Mon, 18 Jul 2005 12:48:00 -0700
From: Michael Demmer <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] dtnperf
Sender: [email-masked]
Reply-To: [email-masked]

if you could send me the code, i'll make sure it gets checked in and
integrated into the build system.

thanks for the time and effort!

-m

> Hello,
>    i've ended the development of dtnperf, a software by which is possible to
> test a DTN, similar to Iperf.
> It should be made by two applications: dtnClient and dtnServer. By now, only the
> client is done, and it can be used with dtnrecv.
> In a future, both client and server should be joined into a single "dtnperf"
> command.
> 
> It can work in two modes: Time-Mode and Data-Mode.
> In the first case, the user shall specify for how many seconds the client must
> send data to the receiver, and the output is how many data have been sent.
> Data-Mode is the opposite: send n-bytes and see how many seconds does it take.
> It also gives the goodput of the DTN, and supports CSV (Comma Separated Values)
> output, so that the results can be easily imported into a spreadsheet.
> 
> If you are interested in it, i could send you the code and, if you wish, you can
> include it into the DTN2/apps directory... just let me know.
> 
> Cheers,
>    Piero Cornice
>    Dipartimento di Elettronica, Informatica e Sistemistica
>    Universita' degli Studi di Bologna
> 
> 
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users

Date: Mon, 18 Jul 2005 11:31:46 -0700
From: Melissa Ho <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] retransmissions
Sender: [email-masked]
Reply-To: [email-masked]

This behavior is correct - currently the UDP convergence layer is
written without built-in reliability mechanism, and should only be
used for reliable links.

If you set the correct flags on the bundle, you can get notifications
to track the receipt of bundle at each hop.  In theory, you could also
set the custody xfer flag, and use the bundle-layer-level reliability.
However, custody xfer has not yet been implemented in DTN2.

You are wecome to implement a reliable-UDP convergence layer; although
for reliability sake you might as well use the TCP cl.

Melissa

On 7/18/05, Isidro Nistal Garrido <[email-masked]> wrote:
> Hi
> 
> I am testing DTN2 program in a 3 computers enviroment. I have connected the
> computers to another one that is transparent and has a dynamic switch program
> installed. This dynamic switch program lets me set the dropping probability of
> packets that go through it.
> 
> My problem is that when I set an enviroment with tcp connections between the
> nodes and some kind of dropping probability in the switch, dtn works and the
> replys are got(with much more time of course), but if I set up an enviroment
> with udp, no retransmissions are done, dtn agent lets all the retransmissions
> stuff to the transport layer, so as udp doesn't have, the bundles never arrive
> to its destination... Am I right? The retransmissions shouldn't be done by the
> bundle layer too?
> 
> Thanks in advance.
> 
> BEst regards.
> 
> 
> Isidro Nistal Garrido
> Spanish Exchange Student in Luleå
> Tfn: +46 730 583 165
> 
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users
>

Date: Mon, 18 Jul 2005 12:09:10 +0200
From: Isidro Nistal Garrido <[email-masked]>
To: [email-masked]
Subject: [dtn-users] retransmissions
Sender: [email-masked]
Reply-To: [email-masked]

Hi

I am testing DTN2 program in a 3 computers enviroment. I have connected the
computers to another one that is transparent and has a dynamic switch program
installed. This dynamic switch program lets me set the dropping probability of
packets that go through it. 

My problem is that when I set an enviroment with tcp connections between the
nodes and some kind of dropping probability in the switch, dtn works and the
replys are got(with much more time of course), but if I set up an enviroment
with udp, no retransmissions are done, dtn agent lets all the retransmissions
stuff to the transport layer, so as udp doesn't have, the bundles never arrive
to its destination... Am I right? The retransmissions shouldn't be done by the
bundle layer too?

Thanks in advance.

BEst regards.

Isidro Nistal Garrido
Spanish Exchange Student in Luleå
Tfn: +46 730 583 165

Date: Wed, 13 Jul 2005 19:24:55 +0200
From: "[email-masked]" <[email-masked]>
To: [email-masked]
Subject: [dtn-users] dtnperf
Sender: [email-masked]
Reply-To: [email-masked]

Hello,
   i've ended the development of dtnperf, a software by which is possible to
test a DTN, similar to Iperf.
It should be made by two applications: dtnClient and dtnServer. By now, only the
client is done, and it can be used with dtnrecv.
In a future, both client and server should be joined into a single "dtnperf"
command.

It can work in two modes: Time-Mode and Data-Mode.
In the first case, the user shall specify for how many seconds the client must
send data to the receiver, and the output is how many data have been sent.
Data-Mode is the opposite: send n-bytes and see how many seconds does it take.
It also gives the goodput of the DTN, and supports CSV (Comma Separated Values)
output, so that the results can be easily imported into a spreadsheet.

If you are interested in it, i could send you the code and, if you wish, you can
include it into the DTN2/apps directory... just let me know.

Cheers,
   Piero Cornice
   Dipartimento di Elettronica, Informatica e Sistemistica
   Universita' degli Studi di Bologna

Date: Tue, 12 Jul 2005 10:34:06 -0700
From: Melissa Ho <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] Fwd: Configure / compile under updated FC3?
Sender: [email-masked]
Reply-To: [email-masked]

I'll look into it later today and see what I can do. Although I have
FC3 on my laptop, and haven't had any problems with configure/compile
thus far. I suspect you may need a patch to configure for the new
version of yum.

Melissa

On 7/11/05, Joshua Schoolcraft <[email-masked]> wrote:
> This is perhaps more a more appropriate question for the users mailing list.
> 
> ---------- Forwarded message ----------
> From: Joshua Schoolcraft <[email-masked]>
> Date: Jul 8, 2005 3:13 PM
> Subject: Configure / compile under updated FC3?
> To: [email-masked]
> 
> 
> Hello,
> 
> I'm trying to compile DTN2 in Fedora Core 3, but I run into an issue
> with ./configure:
> 
> checking compilation target... native
> checking whether to compile with debugging... yes
> checking whether to compile with memory debugging... no
> checking whether to compile with optimization... no
> checking whether to build and link using static tcl and db libraries... no
> checking for a C compiler (trying gcc gcc-3.3 gcc-3.2 gcc-2.96 gcc296
> gcc-2.95 gcc295)...
> checking for gcc... gcc
> checking for C compiler default output... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables...
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ANSI C... none needed
> checking for a C++ compiler (trying g++ g++-3.3 g++-3.2 g++-2.96
> g++296 g++-2.95 g++295)...
> checking for g++... no
> checking for g++-3.3... no
> checking for g++-3.2... no
> checking for g++-2.96... no
> checking for g++296... no
> checking for g++-2.95... no
> checking for g++295... no
> checking whether we are using the GNU C++ compiler... no
> checking whether g++ accepts -g... no
> checking for gawk... gawk
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether make sets $(MAKE)... yes
> checking for ranlib... ranlib
> checking for the version of the gcc compiler... 3.4.3
> checking whether gcc accepts -Wno-long-double (Apple OSX only)... no
> checking whether std::string::reserve() is broken... yes
> configure: error: broken std::string::reserve() -- upgrade your compiler
> 
> The installation of Fedora Core 3 was updated with yum recently, and
> gcc is version 3.4.3-22.  Does anyone know how to deal with this?  A
> Google search for broken std::string::reserve() didn't turn up much.
> 
> Thanks,
> Josh
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users
>

Date: Tue, 12 Jul 2005 13:38:11 +0200
From: "[email-masked]" <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] FILE vs MEM
Sender: [email-masked]
Reply-To: [email-masked]

Hi, i'm Piero from Italy.
Did you succeed in writing the dtncpd patch, allowing bundle transfer as  a
file? If you did please let me know.
Thanks,
   Piero Cornice

Scrive Jeff Allen <[email-masked]>:

> > Shall i write the destination filename into
> > payload.dtn_bundle_payload_t_u.filename_val before the dtn_recv?
> 
> Yes, that's my understanding of how the API works.
> 
> If I get a chance later today, I'll make a patch to dtncpd that
> demonstrates receiving as a file. It would probably make sense to
> check it in and leave it that way going forward so that it serves as a
> better example. (I'll leave that decision to Mike and Melissa.)
> 
>   -jeff
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users
> 
> 

Date: Mon, 11 Jul 2005 10:22:11 -0700
From: Joshua Schoolcraft <[email-masked]>
To: [email-masked]
Subject: [dtn-users] Fwd: Configure / compile under updated FC3?
Sender: [email-masked]
Reply-To: [email-masked]

This is perhaps more a more appropriate question for the users mailing list.

---------- Forwarded message ----------
From: Joshua Schoolcraft <[email-masked]>
Date: Jul 8, 2005 3:13 PM
Subject: Configure / compile under updated FC3?
To: [email-masked]

Hello,

I'm trying to compile DTN2 in Fedora Core 3, but I run into an issue
with ./configure:

checking compilation target... native
checking whether to compile with debugging... yes
checking whether to compile with memory debugging... no
checking whether to compile with optimization... no
checking whether to build and link using static tcl and db libraries... no
checking for a C compiler (trying gcc gcc-3.3 gcc-3.2 gcc-2.96 gcc296
gcc-2.95 gcc295)...
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for a C++ compiler (trying g++ g++-3.3 g++-3.2 g++-2.96
g++296 g++-2.95 g++295)...
checking for g++... no
checking for g++-3.3... no
checking for g++-3.2... no
checking for g++-2.96... no
checking for g++296... no
checking for g++-2.95... no
checking for g++295... no
checking whether we are using the GNU C++ compiler... no
checking whether g++ accepts -g... no
checking for gawk... gawk
checking for a BSD-compatible install... /usr/bin/install -c
checking whether make sets $(MAKE)... yes
checking for ranlib... ranlib
checking for the version of the gcc compiler... 3.4.3
checking whether gcc accepts -Wno-long-double (Apple OSX only)... no
checking whether std::string::reserve() is broken... yes
configure: error: broken std::string::reserve() -- upgrade your compiler

The installation of Fedora Core 3 was updated with yum recently, and
gcc is version 3.4.3-22.  Does anyone know how to deal with this?  A
Google search for broken std::string::reserve() didn't turn up much.

Thanks,
Josh

Date: Sun, 10 Jul 2005 11:28:57 -0700
From: Jeff Allen <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] FILE vs MEM
Sender: [email-masked]
Reply-To: [email-masked]

> Shall i write the destination filename into
> payload.dtn_bundle_payload_t_u.filename_val before the dtn_recv?

Yes, that's my understanding of how the API works.

If I get a chance later today, I'll make a patch to dtncpd that
demonstrates receiving as a file. It would probably make sense to
check it in and leave it that way going forward so that it serves as a
better example. (I'll leave that decision to Mike and Melissa.)

  -jeff

Date: Sun, 10 Jul 2005 19:32:32 +0200
From: "[email-masked]" <[email-masked]>
To: [email-masked]
Subject: [dtn-users] FILE vs MEM
Sender: [email-masked]
Reply-To: [email-masked]

Hi, i'm still trying to cope with "dtn_recv + DTN_PAYLOAD_FILE" in order to
receive a bundle as a file.
First i tried to use dtncpd, since it should receive files sent by dtncp. So i
sent a 10000 KB file and everything worked. Good :)
Then i tried with a 100000 KB file and... ops, i got this:

error getting recv reply: -1 (error in xdr routines)

which is the same error i obtain when sending bundles greater than 50000 bytes
(when received into memory).
So i had a look at dtncpd code and SURPRISE! That application doesn't use (as i
was hoping) DTN_PAYLOAD_FILE, but it stores received bundles into a memory
buffer (with DTN_PAYLOAD_MEM) and then copies that buffer into a file :-(
Since i want to directly use files, i tried to look for some other sample
program, but found nothing. Then tried to write it by myself, but didn't succeed.
The trouble is (i think) which parameters to use into dtn_recv.
Theoretically, i should write:

dtn_recv(handle, &bundle_spec, DTN_PAYLOAD_FILE, &payload, -1);

where "payload" is a dtn_bundle_payload_t variable, but it doesn't work.
How should i do this?
Is there any sample application i could look at?

I know that dtn_bundle_payload_t type is an union with the fields:

---- filename -----+---- buf -----
u_int filename_len | u_int buf_len
char* filename_val | char* buf_val
-------------------+--------------

Shall i write the destination filename into
payload.dtn_bundle_payload_t_u.filename_val before the dtn_recv?

Thanks,
   Piero Cornice
   Dipartimento di Elettronica, Informatica e Sistemistica
   Universita' degli Studi di Bologna
   Italy

Date: Fri, 8 Jul 2005 15:06:14 -0700
From: Melissa Ho <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] dtn_payload_type
Sender: [email-masked]
Reply-To: [email-masked]

Functionally speaking, you are very correct - if you were to receive a
bundle greater than whatever the max DTN_PAYLOAD_MEM size is, then
something bad would happen. (hmm.. it might be interesting to have
something in the bundle api to indicate that a too-big bundle is
ready...).

Theoretically and Bundle Protocol and DTN Architecturally speaking,
your application should "know" what sizes of bundles to expect, and
not specify DTN_PAYLOAD_MEM if any bundles larger than the functional
bundle--in-memory limit are expected/possible/reasonAYLOAD_MEM if any
bundles larger than the functional bundle--in-memory limit are
expected/possible/reasonable.

Incidentally there is a parameter called payload_mem_threshold
(default=16384) which is used for some level of optimization. Payloads
below this size have an in memory shadow copy in addition to the file
to reduce disk access.  Which is different from the question since it
has nothing to do with the applib.

Looking at the code, the APIServer uses an oasys::StringBuffer to
deliver the payload, which uses malloc and realloc to allocate space
for the data buffer. So the theoretical limit should be however much
memory can be successfully allocated, since StringBuffer::reserve
silently sets buf_ to null if the realloc fails. Mike can confirm this
when he gets back.

And I should clarify some terminology here:
 "the bundle will be stored into memory" should read "the bundle
payload will be delivered to the application in memory"

Melissa
> 
> 
> Scrive Melissa Ho <[email-masked]>:
> 
> > > Ok, let's suppose i want to send a bundle containing a filename: i have to
> > do
> > > dtn_set_payload using DTN_PAYLOAD_FILE.
> > > On the destination machine there's a software which doesn't know if i'm
> > sending
> > > a file-bundle or a memory-bundle. Is there a way to make it know? Now i'm
> > > sending a previous memory-bundle where it's written the next bundle's type,
> > is
> > > this the only way?
> >
> > This question doesn't make sense.  How you sent the bundle (file vs
> > mem) has nothing to do with how the bundle is received. It has
> > everything to do with how the application has registered itself with
> > the application api.  So when you register the destination
> > application, you actually specify whether you want to receive the
> > bundles as files or in memory.
> >
> > Melissa
> > _______________________________________________
> > dtn-users mailing list
> > [email-masked]
> > http://mailman.dtnrg.org/mailman/listinfo/dtn-users
> >
> >
> 
> 
> 
> 
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users
>

Date: Fri,  8 Jul 2005 13:03:48 +0200
From: "[email-masked]" <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] dtn_payload_type
Sender: [email-masked]
Reply-To: [email-masked]

Excuse me for my insistence, but i'd like to clearly understand this fact.

If i wrote dtn_recv(..., DTN_PAYLOAD_FILE, ...) in my receiver application, it
would store the received bundle into a file, and i shouldn't worry about payload
size (which should be limited to 4GB).
If i instead specify DTN_PAYLOAD_MEM, the bundle will be stored into memory, but
in this case it shoud be smaller than a certain size (maybe 50000 bytes?).

Is this right?

Thank you for your patience :-)
   piero

Scrive Melissa Ho <[email-masked]>:

> > Ok, let's suppose i want to send a bundle containing a filename: i have to
> do
> > dtn_set_payload using DTN_PAYLOAD_FILE.
> > On the destination machine there's a software which doesn't know if i'm
> sending
> > a file-bundle or a memory-bundle. Is there a way to make it know? Now i'm
> > sending a previous memory-bundle where it's written the next bundle's type,
> is
> > this the only way?
> 
> This question doesn't make sense.  How you sent the bundle (file vs
> mem) has nothing to do with how the bundle is received. It has
> everything to do with how the application has registered itself with
> the application api.  So when you register the destination
> application, you actually specify whether you want to receive the
> bundles as files or in memory.
> 
> Melissa
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users
> 
> 

Date: Fri, 8 Jul 2005 03:23:23 -0700
From: Melissa Ho <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] dtn_payload_type
Sender: [email-masked]
Reply-To: [email-masked]

> Ok, let's suppose i want to send a bundle containing a filename: i have to do
> dtn_set_payload using DTN_PAYLOAD_FILE.
> On the destination machine there's a software which doesn't know if i'm sending
> a file-bundle or a memory-bundle. Is there a way to make it know? Now i'm
> sending a previous memory-bundle where it's written the next bundle's type, is
> this the only way?

This question doesn't make sense.  How you sent the bundle (file vs
mem) has nothing to do with how the bundle is received. It has
everything to do with how the application has registered itself with
the application api.  So when you register the destination
application, you actually specify whether you want to receive the
bundles as files or in memory.

Melissa

Date: Fri,  8 Jul 2005 11:42:56 +0200
From: "[email-masked]" <[email-masked]>
To: [email-masked]
Subject: [dtn-users] dtn_payload_type
Sender: [email-masked]
Reply-To: [email-masked]

Excuse me, i found something about it in the doxygen documentation:

"The payload of a bundle can be sent or received either in a file, in which case
the payload structure contains the filename, or in memory where the struct has
the actual data.

Note that there is a limit (DTN_PAYLOAD_MEM) on the maximum size bundle payload
that can be sent or received in memory."

Ok, let's suppose i want to send a bundle containing a filename: i have to do
dtn_set_payload using DTN_PAYLOAD_FILE.
On the destination machine there's a software which doesn't know if i'm sending
a file-bundle or a memory-bundle. Is there a way to make it know? Now i'm
sending a previous memory-bundle where it's written the next bundle's type, is
this the only way?

Thanks,

   Piero Cornice
   Dipartimento di Elettronica, Informatica e Sistemistica
   Universita' di Bologna
   Italy

Date: Fri,  8 Jul 2005 11:28:58 +0200
From: "[email-masked]" <[email-masked]>
To: DTNRG <[email-masked]>
Subject: [dtn-users] dtn_payload_type
Sender: [email-masked]
Reply-To: [email-masked]

Hi,
   could anybody tell me what are the differences between DTN_PAYLOAD_MEM and
DTN_PAYLOAD_FILE as dtn_recv arguments?
Perhaps DTN_PAYLOAD_MEM has a limited size?

Thanks,

   Piero Cornice
   Dipartimento di Elettronica, Informatica e Sistemistica
   Universita' degli Studi di Bologna