Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o5TCwVrI018053 for ; Tue, 29 Jun 2010 05:58:32 -0700 Message-Id: <201006291258.o5TCwVrI018053@maillists.intel-research.net> Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id o5TCwTEL026701; Tue, 29 Jun 2010 08:58:29 -0400 From: "Ng, Nicole - 0663 - MITLL" To: "Iannicca, Dennis C. (GRC-RHN0)" , "Andresen, Jason R." Date: Tue, 29 Jun 2010 08:58:31 -0400 Thread-Topic: [dtn-users] Error installing DTN2 Thread-Index: AcsXCBHC9UFswaiuSj6HnL8Z7k3rNQAgerZg References: <201006282057.o5SKvB4G028744@maillists.intel-research.net> <600C0C33850FFE49B76BDD81AED4D25801E012E1F2@IMCMBX3.MITRE.ORG> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_472187D7E7E0264EAE23897B2A51619E97838F720DLLE2K7BE01mit_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-29_01:2010-02-06, 2010-06-29, 2010-06-29 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1006290051 Cc: "dtn-users@maillists.intel-research.net" , "Dastangoo, Siamak - 0663 - MITLL" Subject: Re: [dtn-users] Error installing DTN2 X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 12:58:33 -0000 --_000_472187D7E7E0264EAE23897B2A51619E97838F720DLLE2K7BE01mit_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you guys for your help! I edited the gcc.ac file as you suggested Den= nis and now it compiles without any errors. Thank you, Nicole From: Iannicca, Dennis C. (GRC-RHN0) [mailto:dennis.c.iannicca@nasa.gov] Sent: Monday, June 28, 2010 5:23 PM To: Andresen, Jason R. Cc: Ng, Nicole - 0663 - MITLL; dtn-users@maillists.intel-research.net; Dast= angoo, Siamak - 0663 - MITLL Subject: Re: [dtn-users] Error installing DTN2 If the problem you're referring to is the same issue I was havi= ng building DTN2 2.7.0 on 64-bit Linux, the fix was for me to go to line 31= 2 of oasys/aclocal/gcc.ac, add "$picflags" to the LDFLAGS options, and then= rerun the build-configure.sh scripts under the oasys and dtn2 directories.= The line should look like this: LDFLAGS=3D"$picflags $shopt $ac_save_LDFLAGS" The configure script should then pick up the PIC flags for the = 64-bit architecture and it'll build with shared library support. On Jun 28, 2010, at 5:01 PM, Andresen, Jason R. wrote: That happens when ./configure erroneously thinks that it cannot make shared= objects and does not populate the -shared and PIC flags. It seems to happ= en a lot on very new (Fedora 13 for example) versions of Linux. I have not= tracked down the exact reason unfortunately, I've just hacked up the confi= gure scripts to bypass the check and then populate the fields by hand. You will to recompile oasys after you make the fix (in both DTN2 and oasys)= . From: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users-bounces@maillists.intel-= research.net] On Behalf Of Ng, Nicole - 0663 - MITLL Sent: Monday, June 28, 2010 4:57 PM To: dtn-users@maillists.intel-research.net Cc: Dastangoo, Siamak - 0663 - MITLL Subject: [dtn-users] Error installing DTN2 Dear All, I am a summer intern working at MIT Lincoln Laboratory. I am trying to inst= all/build DTN on redhat linux, but I have run into some difficulties. I dow= nloaded dtn-2.7.0 and oasys-1.4.0 from SourceForge. I have also installed t= cl 8.4, db 4.3, and xerces -c-3.1.1. The folders for dtn-2.7.0 and oasys-1.= 4.0 are in the same directory. The oasys directory resides in ../ of the ma= in dtn-2.7.0 directory. I successfully installed oasys and renamed the fol= der oasys-1.4.0 to oasys so that dtn-2.7.0 can find the libraries. I then tried to compile dtn-2.7.0 but received an error. The following are = the commands I've entered once I cd into the dtn-2.7.0 folder: make distclean ./build-configure.sh ./configure make After entering make, I receive an error that reads "undefined reference to = 'main'". Below is the output: (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status make[1]: *** [libdtnapi-2.7.0.] Error 1 make[1]: Leaving directory `/root/dtn-2.7.0/applib' make: *** [applib] Error 2 Has anyone else run into this problem as well? Any insight into this error = would be greatly appreciated. Thank you, Nicole --_000_472187D7E7E0264EAE23897B2A51619E97838F720DLLE2K7BE01mit_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you guys for your help! I edited the gcc.ac file as yo= u suggested Dennis and now it compiles without any errors.<= /p>

 

Thank you,

 

Nicole

 

From: Iannicca, Den= nis C. (GRC-RHN0) [mailto:dennis.c.iannicca@nasa.gov]
Sent: Monday, June 28, 2010 5:23 PM
To: Andresen, Jason R.
Cc: Ng, Nicole - 0663 - MITLL; dtn-users@maillists.intel-research.ne= t; Dastangoo, Siamak - 0663 - MITLL
Subject: Re: [dtn-users] Error installing DTN2

 

    &= nbsp;       If the problem you're referring to is the same issue I was having building DTN= 2 2.7.0 on 64-bit Linux, the fix was for me to go to line 312 of oasys/aclocal/gcc.ac, add "$picflags" to the LDFLAGS options, and then rerun the build-configure.sh scripts under the oasys and dtn2 director= ies.  The line should look like this:

 

             LDFLAGS=3D"$picflags $shopt $ac_save_LDFLAGS"

 

    &= nbsp;       The configure script should then pick up the PIC flags for the 64-bit architect= ure and it'll build with shared library support.  

 

On Jun 28, 2010, at 5:01 PM, Andresen, Jason R. wrote:=



That happens when ./configure erroneously thinks that it can= not make shared objects and does not populate the –shared and PIC flags.  It seems to happen a lot on very new (Fedora 13 for example) versions of Linux.  I have not tracked down the exact reason unfortunately, I’ve just hacked up the configure scripts to bypass th= e check and then populate the fields by hand. 

 

You will to recompile oasys after you make the fix (in both = DTN2 and oasys).

 

From: dtn-users-bo= unces@maillists.intel-research.net [mailto:dtn-users-bounces@mailli= sts.intel-research.net] On Behalf Of Ng, Nicole - 0663 - MITLL Sent: Monday, June 2= 8, 2010 4:57 PM
To: dtn-users@maillists.= intel-research.net
Cc: Dastangoo, Siama= k - 0663 - MITLL
Subject: [dtn-users]= Error installing DTN2

 

Dear All,

 

I am a summer intern working at MIT Lincoln Laboratory. I am trying to install/build DTN on redhat linux, but I have run into some difficulties. I downloaded dtn-2.7.0 and oasys-1.4.0 from SourceForge. I have also installe= d tcl 8.4, db 4.3, and xerces –c-3.1.1. The folders for dtn-2.7.0 and oasys-1.4.0 are in the same directory. The oasys directory resides in ../ o= f the main dtn-2.7.0 directory.  I successfully installed oasys and rena= med the folder oasys-1.4.0 to oasys so that dtn-2.7.0 can find the libraries.&n= bsp; 

 

I then tried to compile dtn-2.7.0 but received an error. The following are th= e commands I’ve entered once I cd into the dtn-2.7.0 folder:=

 

make distclean

./build-configure.sh

./configure

make

 

After entering make, I receive an error that reads “undefined reference to ‘main’”. Below is the output:

 

(.text+0x20): undefined reference to `main'

collect2: ld returned 1 exit status

make[1]: *** [libdtnapi-2.7.0.] Error 1

make[1]: Leaving directory `/root/dtn-2.7.0/applib'

make: *** [applib] Error 2

 

Has anyone else run into this problem as well? Any insight into this error woul= d be greatly appreciated.

 

Thank you,

 

Nicole

 

<ATT00001..txt>

 

--_000_472187D7E7E0264EAE23897B2A51619E97838F720DLLE2K7BE01mit_-- Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o5SLMsF6029981 for ; Mon, 28 Jun 2010 14:22:54 -0700 Received: from ndjsppt05.ndc.nasa.gov (ndjsppt05.ndc.nasa.gov [198.117.1.104]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id C1E742D82CE; Mon, 28 Jun 2010 16:22:54 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt05.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o5SLMsV0025119; Mon, 28 Jun 2010 16:22:54 -0500 Received: from NDJSSCC05.ndc.nasa.gov ([198.117.4.174]) by ndjshub04.ndc.nasa.gov ([10.202.202.163]) with mapi; Mon, 28 Jun 2010 16:22:54 -0500 From: "Iannicca, Dennis C. (GRC-RHN0)" To: "Andresen, Jason R." Date: Mon, 28 Jun 2010 16:22:52 -0500 Thread-Topic: [dtn-users] Error installing DTN2 Thread-Index: AcsXCBHC9UFswaiuSj6HnL8Z7k3rNQ== Message-ID: References: <201006282057.o5SKvB4G028744@maillists.intel-research.net> <600C0C33850FFE49B76BDD81AED4D25801E012E1F2@IMCMBX3.MITRE.ORG> In-Reply-To: <600C0C33850FFE49B76BDD81AED4D25801E012E1F2@IMCMBX3.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CE31B79762B64F819FF0E3B720349D97nasagov_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-28_03:2010-02-06, 2010-06-28, 2010-06-28 signatures=0 Cc: "dtn-users@maillists.intel-research.net" , "Dastangoo, Siamak - 0663 - MITLL" Subject: Re: [dtn-users] Error installing DTN2 X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 21:22:54 -0000 --_000_CE31B79762B64F819FF0E3B720349D97nasagov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable If the problem you're referring to is the same issue I was having building = DTN2 2.7.0 on 64-bit Linux, the fix was for me to go to line 312 of oasys/a= clocal/gcc.ac, add "$picflags" to the LDFLAGS options, and then rerun the b= uild-configure.sh scripts under the oasys and dtn2 directories. The line s= hould look like this: LDFLAGS=3D"$picflags $shopt $ac_save_LDFLAGS" The configure script should then pick up the PIC flags for the 64-bit archi= tecture and it'll build with shared library support. On Jun 28, 2010, at 5:01 PM, Andresen, Jason R. wrote: That happens when ./configure erroneously thinks that it cannot make shared= objects and does not populate the =96shared and PIC flags. It seems to ha= ppen a lot on very new (Fedora 13 for example) versions of Linux. I have n= ot tracked down the exact reason unfortunately, I=92ve just hacked up the c= onfigure scripts to bypass the check and then populate the fields by hand. You will to recompile oasys after you make the fix (in both DTN2 and oasys)= . From: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users-bounces@maillists.intel-= research.net] On Behalf Of Ng, Nicole - 0663 - MITLL Sent: Monday, June 28, 2010 4:57 PM To: dtn-users@maillists.intel-research.net Cc: Dastangoo, Siamak - 0663 - MITLL Subject: [dtn-users] Error installing DTN2 Dear All, I am a summer intern working at MIT Lincoln Laboratory. I am trying to inst= all/build DTN on redhat linux, but I have run into some difficulties. I dow= nloaded dtn-2.7.0 and oasys-1.4.0 from SourceForge. I have also installed t= cl 8.4, db 4.3, and xerces =96c-3.1.1. The folders for dtn-2.7.0 and oasys-= 1.4.0 are in the same directory. The oasys directory resides in ../ of the = main dtn-2.7.0 directory. I successfully installed oasys and renamed the f= older oasys-1.4.0 to oasys so that dtn-2.7.0 can find the libraries. I then tried to compile dtn-2.7.0 but received an error. The following are = the commands I=92ve entered once I cd into the dtn-2.7.0 folder: make distclean ./build-configure.sh ./configure make After entering make, I receive an error that reads =93undefined reference t= o =91main=92=94. Below is the output: (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status make[1]: *** [libdtnapi-2.7.0.] Error 1 make[1]: Leaving directory `/root/dtn-2.7.0/applib' make: *** [applib] Error 2 Has anyone else run into this problem as well? Any insight into this error = would be greatly appreciated. Thank you, Nicole --_000_CE31B79762B64F819FF0E3B720349D97nasagov_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
If t= he problem you're referring to is the same issue I was having building DTN2= 2.7.0 on 64-bit Linux, the fix was for me to go to line 312 of oasys/= aclocal/gcc.ac, add "$picflags" to the LDFLAGS options, and then rerun the = build-configure.sh scripts under the oasys and dtn2 directories.  The = line should look like this:

   &nbs= p;         LDFLAGS=3D"$picflags $shopt $ac_save_LDFLAGS= "

The configure script should then pick up the PIC fla= gs for the 64-bit architecture and it'll build with shared library support.=  

On Jun 28, 2010, at 5:01 PM, Andresen, Jason R. = wrote:

That happens when ./configure erroneously thinks that it cannot make share= d objects and does not populate the =96shared and PIC flags.  It seems= to happen a lot on very new (Fedora 13 for example) versions of Linux.&nbs= p; I have not tracked down the exact reason unfortunately, I=92ve just hack= ed up the configure scripts to bypass the check and then populate the field= s by hand. 
You = will to recompile oasys after you make the fix (in both DTN2 and oasys).
 
From: dtn-users-bounces@maillists.intel-resea= rch.net [mailto:dtn-u= sers-bounces@maillists.intel-research.net] On Behalf Of&nbs= p;Ng, Nicole - 0663 - MITLL
Sent: Monday, June 28, 2010 4:57 PM
To: dtn-users@maillists.intel-research.net
Cc: Dastangoo, Siamak - 0663 - MITLLSubject: [dtn-us= ers] Error installing DTN2
 =
 
I am a summer intern working at = MIT Lincoln Laboratory. I am trying to install/build DTN on redhat linux, b= ut I have run into some difficulties. I downloaded dtn-2.7.0 and oasys-1.4.= 0 from SourceForge. I have also installed tcl 8.4, db 4.3, and xerces =96c-= 3.1.1. The folders for dtn-2.7.0 and oasys-1.4.0 are in the same directory.= The oasys directory resides in ../ of the main dtn-2.7.0 directory.  = I successfully installed oasys and renamed the folder oasys-1.4.0 to oasys = so that dtn-2.7.0 can find the libraries.  
&nbs= p;
I then tried to compile dtn-2.7.0 but received an error. The foll= owing are the commands I=92ve entered once I cd into the dtn-2.7.0 folder:<= o:p>
 
make distclean
./build-configure= .sh
./configure
make
 <= /div>
After entering make, I receive an error that reads =93undefined reference = to =91main=92=94. Below is the output:
 
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; m= argin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">(.tex= t+0x20): undefined reference to `main'
collect2: ld returned 1 = exit status
make[1]: *** [libdtnapi-2.7.0.] Error 1<= /div>
make[1]: Leaving directory `/root/dtn-2.7.0/applib'
make: *** = [applib] Error 2
 
Has anyone else run into th= is problem as well? Any insight into this error would be greatly appreciate= d.
 
Thank you,
 <= /div>
Nicole
 
<ATT00001..= txt>

= --_000_CE31B79762B64F819FF0E3B720349D97nasagov_-- Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o5SL21rB029037 for ; Mon, 28 Jun 2010 14:02:01 -0700 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5SL22dG024826 for ; Mon, 28 Jun 2010 17:02:02 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5SL219v024812; Mon, 28 Jun 2010 17:02:01 -0400 Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Mon, 28 Jun 2010 17:02:00 -0400 From: "Andresen, Jason R." To: "Ng, Nicole - 0663 - MITLL" , "dtn-users@maillists.intel-research.net" Date: Mon, 28 Jun 2010 17:01:57 -0400 Thread-Topic: Error installing DTN2 Thread-Index: AcsXBHi6riiXTUfLQ5SYWpjp0mLB4AAAE9IQ Message-ID: <600C0C33850FFE49B76BDD81AED4D25801E012E1F2@IMCMBX3.MITRE.ORG> References: <201006282057.o5SKvB4G028744@maillists.intel-research.net> In-Reply-To: <201006282057.o5SKvB4G028744@maillists.intel-research.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_600C0C33850FFE49B76BDD81AED4D25801E012E1F2IMCMBX3MITREO_" MIME-Version: 1.0 Cc: "Dastangoo, Siamak - 0663 - MITLL" Subject: Re: [dtn-users] Error installing DTN2 X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 21:02:02 -0000 --_000_600C0C33850FFE49B76BDD81AED4D25801E012E1F2IMCMBX3MITREO_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That happens when ./configure erroneously thinks that it cannot make shared= objects and does not populate the -shared and PIC flags. It seems to happ= en a lot on very new (Fedora 13 for example) versions of Linux. I have not= tracked down the exact reason unfortunately, I've just hacked up the confi= gure scripts to bypass the check and then populate the fields by hand. You will to recompile oasys after you make the fix (in both DTN2 and oasys)= . From: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users-boun= ces@maillists.intel-research.net] On Behalf Of Ng, Nicole - 0663 - MITLL Sent: Monday, June 28, 2010 4:57 PM To: dtn-users@maillists.intel-research.net Cc: Dastangoo, Siamak - 0663 - MITLL Subject: [dtn-users] Error installing DTN2 Dear All, I am a summer intern working at MIT Lincoln Laboratory. I am trying to inst= all/build DTN on redhat linux, but I have run into some difficulties. I dow= nloaded dtn-2.7.0 and oasys-1.4.0 from SourceForge. I have also installed t= cl 8.4, db 4.3, and xerces -c-3.1.1. The folders for dtn-2.7.0 and oasys-1.= 4.0 are in the same directory. The oasys directory resides in ../ of the ma= in dtn-2.7.0 directory. I successfully installed oasys and renamed the fol= der oasys-1.4.0 to oasys so that dtn-2.7.0 can find the libraries. I then tried to compile dtn-2.7.0 but received an error. The following are = the commands I've entered once I cd into the dtn-2.7.0 folder: make distclean ./build-configure.sh ./configure make After entering make, I receive an error that reads "undefined reference to = 'main'". Below is the output: (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status make[1]: *** [libdtnapi-2.7.0.] Error 1 make[1]: Leaving directory `/root/dtn-2.7.0/applib' make: *** [applib] Error 2 Has anyone else run into this problem as well? Any insight into this error = would be greatly appreciated. Thank you, Nicole --_000_600C0C33850FFE49B76BDD81AED4D25801E012E1F2IMCMBX3MITREO_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That happens when ./conf= igure erroneously thinks that it cannot make shared objects and does not populate the –= shared and PIC flags.  It seems to happen a lot on very new (Fedora 13 for example) versions of Linux.  I have not tracked down the exact reason unfortunately, I’ve just hacked up the configure scripts to bypass th= e check and then populate the fields by hand. 

 =

You will to recompile oa= sys after you make the fix (in both DTN2 and oasys).

 =

From: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users-bounces@maillists.intel-research.net] On Behalf Of Ng, Nicole - 0663 - MITLL
Sent: Monday, June 28, 2010 4:57 PM
To: dtn-users@maillists.intel-research.net
Cc: Dastangoo, Siamak - 0663 - MITLL
Subject: [dtn-users] Error installing DTN2

 

Dear All,

 

I am a summer intern working at MIT Lincoln Laboratory= . I am trying to install/build DTN on redhat linux, but I have run into some diffi= culties. I downloaded dtn-2.7.0 and oasys-1.4.0 from SourceForge. I have also instal= led tcl 8.4, db 4.3, and xerces –c-3.1.1. The folders for dtn-2.7.0 and oasys-1.4.0 are in the same directory. The oasys directory resides in ../ o= f the main dtn-2.7.0 directory.  I successfully installed oasys and rena= med the folder oasys-1.4.0 to oasys so that dtn-2.7.0 can find the libraries.  

 

I then tried to compile dtn-2.7.0 but received an erro= r. The following are the commands I’ve entered once I cd into the dtn-2.7.0 folder:

 

make distclean

./build-configure.sh

./configure

make

 

After entering make, I receive an error that reads “undefined reference to ‘main’”. Below is the outpu= t:

 

(.text+0x20): undefined reference to `main'=

collect2: ld returned 1 exit status

make[1]: *** [libdtnapi-2.7.0.] Error 1

make[1]: Leaving directory `/root/dtn-2.7.0/applib'

make: *** [applib] Error 2

 

Has anyone else run into this problem as well? Any ins= ight into this error would be greatly appreciated.

 

Thank you,

 

Nicole

 

--_000_600C0C33850FFE49B76BDD81AED4D25801E012E1F2IMCMBX3MITREO_-- Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o5SKvB4G028744 for ; Mon, 28 Jun 2010 13:57:11 -0700 Message-Id: <201006282057.o5SKvB4G028744@maillists.intel-research.net> Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id o5SKv7xV013118 for ; Mon, 28 Jun 2010 16:57:07 -0400 From: "Ng, Nicole - 0663 - MITLL" To: "dtn-users@maillists.intel-research.net" Date: Mon, 28 Jun 2010 16:57:08 -0400 Thread-Topic: Error installing DTN2 Thread-Index: AcsXBHi6riiXTUfLQ5SYWpjp0mLB4A== Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_472187D7E7E0264EAE23897B2A51619E97838F717DLLE2K7BE01mit_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-28_03:2010-02-06, 2010-06-28, 2010-06-28 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1006280115 Cc: "Dastangoo, Siamak - 0663 - MITLL" Subject: [dtn-users] Error installing DTN2 X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 20:57:11 -0000 --_000_472187D7E7E0264EAE23897B2A51619E97838F717DLLE2K7BE01mit_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, I am a summer intern working at MIT Lincoln Laboratory. I am trying to inst= all/build DTN on redhat linux, but I have run into some difficulties. I dow= nloaded dtn-2.7.0 and oasys-1.4.0 from SourceForge. I have also installed t= cl 8.4, db 4.3, and xerces -c-3.1.1. The folders for dtn-2.7.0 and oasys-1.= 4.0 are in the same directory. The oasys directory resides in ../ of the ma= in dtn-2.7.0 directory. I successfully installed oasys and renamed the fol= der oasys-1.4.0 to oasys so that dtn-2.7.0 can find the libraries. I then tried to compile dtn-2.7.0 but received an error. The following are = the commands I've entered once I cd into the dtn-2.7.0 folder: make distclean ./build-configure.sh ./configure make After entering make, I receive an error that reads "undefined reference to = 'main'". Below is the output: (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status make[1]: *** [libdtnapi-2.7.0.] Error 1 make[1]: Leaving directory `/root/dtn-2.7.0/applib' make: *** [applib] Error 2 Has anyone else run into this problem as well? Any insight into this error = would be greatly appreciated. Thank you, Nicole --_000_472187D7E7E0264EAE23897B2A51619E97838F717DLLE2K7BE01mit_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

 

I am a summer intern working at MIT Lincoln Laboratory= . I am trying to install/build DTN on redhat linux, but I have run into some difficulties. I downloaded dtn-2.7.0 and oasys-1.4.0 from SourceForge. I ha= ve also installed tcl 8.4, db 4.3, and xerces –c-3.1.1. The folders for dtn-2.7.0 and oasys-1.4.0 are in the same directory. The oasys directory resides in ../ of the main dtn-2.7.0 directory.  I successfully instal= led oasys and renamed the folder oasys-1.4.0 to oasys so that dtn-2.7.0 can fin= d the libraries.  

 

I then tried to compile dtn-2.7.0 but received an erro= r. The following are the commands I’ve entered once I cd into the dtn-2.7.0 folder:

 

make distclean

./build-configure.sh

./configure

make

 

After entering make, I receive an error that reads = 220;undefined reference to ‘main’”. Below is the output:

 

(.text+0x20): undefined reference to `main'=

collect2: ld returned 1 exit status

make[1]: *** [libdtnapi-2.7.0.] Error 1

make[1]: Leaving directory `/root/dtn-2.7.0/applib'

make: *** [applib] Error 2

 

Has anyone else run into this problem as well? Any ins= ight into this error would be greatly appreciated.

 

Thank you,

 

Nicole

 

--_000_472187D7E7E0264EAE23897B2A51619E97838F717DLLE2K7BE01mit_-- Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o5SEpTLd011235 for ; Mon, 28 Jun 2010 07:51:29 -0700 Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 156803E4076; Mon, 28 Jun 2010 15:51:29 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id p9hTVrnaw35h; Mon, 28 Jun 2010 15:51:28 +0100 (IST) Received: from [10.10.11.220] (nat-cawifiupf.upf.edu [193.145.39.152]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id BE7D13E4074; Mon, 28 Jun 2010 15:51:24 +0100 (IST) Message-ID: <4C28B6DB.8080400@cs.tcd.ie> Date: Mon, 28 Jun 2010 15:51:07 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Kevin Fall References: <7BBFF2424089F04FB7D62F800895E2B629A8B79A08@NDJSSCC07.ndc.nasa.gov> <644882.38065.qm@web56608.mail.re3.yahoo.com> <7BBFF2424089F04FB7D62F800895E2B629A8B36EE7@NDJSSCC07.ndc.nasa.gov> <13FEB3EC-F3EE-4272-A2DE-478BE5E92EDF@cs.berkeley.edu> In-Reply-To: <13FEB3EC-F3EE-4272-A2DE-478BE5E92EDF@cs.berkeley.edu> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dtn-users@maillists.intel-research.net, Justin Dailey Subject: Re: [dtn-users] Some very interesting results with large bundles... X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 14:51:29 -0000 Actually after this thread I may set a 4th year project to send a 4GB+ bundle if no-one else gets to delve into if before the autumn. I also don't think this'd warrant a re-write of DTN2. S. On 06/28/2010 03:42 PM, Kevin Fall wrote: > My reaction is that a walk-through and revision of the existing code > base would probably be more fruitful. The DARPA DTN program (BBN more > specifically) wound up doing a re-write. You may want to drop Preston > Marshall an e-mail regarding his thoughts on the motivation and results > of doing so; somebody from BBN could also offer some perspective. > > - K > > On Jun 28, 2010, at Jun 285:56 AMPDT, Ivancic, William D. (GRC-RHN0) wrote: > >> Just curious. DTN-2 has severed us well for quite some time. Many >> thanks to Mike Demmer and others for getting the core in place and >> being extremely useable and useful. My colleagues have expressed >> interested in a possible re-write (more like re-implementation not a >> changing of the specification). With these noted limitations on >> bundle size and such, what are others thoughts on this? >> >> Personally, I think we need to see if there is a RFC5050-bis first as >> the specification may change as well at that time. >> >> Thoughts? >> >> >> --Will >> >> *From:* demmer@gmail.com >> [mailto:demmer@gmail.com] *On Behalf >> Of *Michael Demmer >> *Sent:* Monday, June 28, 2010 3:38 AM >> *To:* Justin Dailey >> *Cc:* stephen.farrell@cs.tcd.ie >> ; L.Wood@surrey.ac.uk >> ; Ivancic, William D. >> (GRC-RHN0); dtn-users@maillists.intel-research.net >> >> *Subject:* Re: [dtn-users] Some very interesting results with large >> bundles... >> >> For what it's worth when I wrote DTN2 I did not think to design for >> >2GB bundles, so I suspect there are multiple places where an int >> (signed or unsigned) is used to store either a structure length or >> file offset. >> >> Also I'm sure I didn't use the large file options when opening files >> on a 32 bit platform so that too would need to be fixed. >> >> >> -m >> >> On Mon, Jun 28, 2010 at 3:57 AM, Justin Dailey > > wrote: >> There was no disconnection at this time. There seems to be enough >> issues just getting it to send a large file as is. Once some bugs are >> fixed then we will further test large bundles on a disconnected >> network to cause it to store and forward bundles. >> >> After doing a few more tests we realized something else that was >> happening. When sending over a 2GB file and causing it to store it, >> the dtnd daemon said that the bundle was the correct size. However, >> the bundle it has stored on the hard drive is 0 bytes long!!! Our >> previous test showed that a 4KB chuck was getting duplicated. We are >> pretty sure this data it copied was leftover in a buffer from the >> previous bundle being sent. >> >> I'm not too familiar with the inner workings of the code, but I'm >> guessing that some part of the code is using an "int" and should be >> using an "unsigned int" (we are running 32-bit OS's) and causing >> anything over the 2GB mark to wrap around to a negative value and >> causing an uncaught error. I hope this helps anybody working on the >> code at this time. I'll see what all code I can dig through of it and >> see if I can't find the bug. >> >> Thanks, >> Justin Dailey >> Shawnee State University - Cyber Center >> Research Assistant >> >> --- On *Sat, 6/26/10, Ivancic, William D. >> (GRC-RHN0) /> >/* wrote: >> >> From: Ivancic, William D. (GRC-RHN0) > > >> Subject: RE: [dtn-users] Some very interesting results with large >> bundles... >> To: "Justin Dailey" >, >> "stephen.farrell@cs.tcd.ie " >> >, >> "L.Wood@surrey.ac.uk " >> > >> Cc: "dtn-users@maillists.intel-research.net >> " >> > > >> Date: Saturday, June 26, 2010, 11:43 PM >> >> >> >> Justin, yoiu had multi-hop. Was there disconnection such that there >> was store and forward verses just forward? >> >> Will >> ________________________________________ >> From: dtn-users-bounces@maillists.intel-research.net >> [dtn-users-bounces@maillists.intel-research.net >> ] >> On Behalf Of Justin Dailey [dail8859@yahoo.com >> ] >> Sent: Friday, June 25, 2010 11:55 AM >> To: stephen.farrell@cs.tcd.ie >> ; L.Wood@surrey.ac.uk >> >> Cc: dtn-users@maillists.intel-research.net >> >> Subject: [dtn-users] Some very interesting results with large bundles... >> >> First of all, Stephen, I'd be glad to take you up on that offer some >> time :) >> >> Lloyd, the 4.4GB file was just a ~1.5GB iso file concatenated together >> 3 times, so we are not for sure what the 396MB was in relation to it. >> >> However, those attempts were quick tests just to see some results. Now >> we have come up with some better ways of getting different sized files >> and ways of telling what parts of the file got there. Pretty much the >> high-tech solution is to make a file containing the text >> "1\n2\n3\n4\n..." and so on and make it as large as we want (1GB, >> 1.5GB, 2GB...) . That way whenever we get a part of the file, we will >> be able to tell what part it is. This makes inspecting the files (ie >> using the head and tail command and visually inspecting) easy to get >> an idea of what went wrong. >> >> Note: Testbed is using TCP CL, 4 hops, no delay/corruption >> >> Here are some things we have noticed. We first noticed that sometimes >> the call to "dtnsend" returned immediately, other times it took more >> than a minute to return from the command. During the times it took a >> while to return, the dtnd process was using more CPU than normal (I'm >> guessing it is processing the large file at this time) As soon as it >> returned (whether the call returned immediately, or several minutes >> later), then there will be heavy network traffic as expected. We >> correlated this "anomaly" to whether the file got to the endpoint >> correctly! Any time the dtnsend took a while, the file would be intact >> at the receiving node. >> >> Secondly, we've noticed so far that any file under 2GB will cause >> dtnsend to take several minutes, and get to the endpoint correctly. >> (Thus far we have correctly sent 1.5, 1.75, and 1.9GB files over our >> network). >> >> We have tried a 2GB and 2.2GB file but the data is not correct. >> >> After doing some visual inspection of the received data for the 2.2GB >> file, it seems that the whole 2.2GB file is a 4KB chunk of data that >> has been duplicated over and over again. The 4KB chunk has some data >> at the end of it that includes the sender EID, destination EID, and >> some unreadable characters. If any body is interested I do have the >> first 1000, and last 1000 lines of the received 2.2GB file. >> >> Sorry for such a long message but I feel this is well worth it. >> >> Thanks, >> Justin Dailey >> Shawnee State University - Cyber Center >> Research Assistant >> >> >> >> >> >> >> _______________________________________________ >> dtn-users mailing list >> dtn-users@maillists.intel-research.net >> >> http://maillists.intel-research.net/mailman/listinfo/dtn-users >> >> >> _______________________________________________ >> dtn-users mailing list >> dtn-users@maillists.intel-research.net >> >> http://maillists.intel-research.net/mailman/listinfo/dtn-users > > > > _______________________________________________ > dtn-users mailing list > dtn-users@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-users Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o5SEgWKI010790 for ; Mon, 28 Jun 2010 07:42:32 -0700 Received: from [10.0.1.33] (76-230-50-89.lightspeed.sntcca.sbcglobal.net [76.230.50.89]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o5SEgU0X000739 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 28 Jun 2010 07:42:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-18-928722615 From: Kevin Fall In-Reply-To: <7BBFF2424089F04FB7D62F800895E2B629A8B36EE7@NDJSSCC07.ndc.nasa.gov> Date: Mon, 28 Jun 2010 07:42:29 -0700 Message-Id: <13FEB3EC-F3EE-4272-A2DE-478BE5E92EDF@cs.berkeley.edu> References: <7BBFF2424089F04FB7D62F800895E2B629A8B79A08@NDJSSCC07.ndc.nasa.gov> <644882.38065.qm@web56608.mail.re3.yahoo.com> <7BBFF2424089F04FB7D62F800895E2B629A8B36EE7@NDJSSCC07.ndc.nasa.gov> To: "Ivancic, William D. (GRC-RHN0)" X-Mailer: Apple Mail (2.1078) Cc: dtn-users@maillists.intel-research.net, Justin Dailey Subject: Re: [dtn-users] Some very interesting results with large bundles... X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 14:42:33 -0000 --Apple-Mail-18-928722615 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii My reaction is that a walk-through and revision of the existing code = base would probably be more fruitful. The DARPA DTN program (BBN more = specifically) wound up doing a re-write. You may want to drop Preston = Marshall an e-mail regarding his thoughts on the motivation and results = of doing so; somebody from BBN could also offer some perspective. - K On Jun 28, 2010, at Jun 285:56 AMPDT, Ivancic, William D. (GRC-RHN0) = wrote: > Just curious. DTN-2 has severed us well for quite some time. Many = thanks to Mike Demmer and others for getting the core in place and = being extremely useable and useful. My colleagues have expressed = interested in a possible re-write (more like re-implementation not a = changing of the specification). With these noted limitations on bundle = size and such, what are others thoughts on this? > =20 > Personally, I think we need to see if there is a RFC5050-bis first as = the specification may change as well at that time. > =20 > Thoughts? > =20 > =20 > --Will > =20 > From: demmer@gmail.com [mailto:demmer@gmail.com] On Behalf Of Michael = Demmer > Sent: Monday, June 28, 2010 3:38 AM > To: Justin Dailey > Cc: stephen.farrell@cs.tcd.ie; L.Wood@surrey.ac.uk; Ivancic, William = D. (GRC-RHN0); dtn-users@maillists.intel-research.net > Subject: Re: [dtn-users] Some very interesting results with large = bundles... > =20 > For what it's worth when I wrote DTN2 I did not think to design for = >2GB bundles, so I suspect there are multiple places where an int = (signed or unsigned) is used to store either a structure length or file = offset.=20 > =20 > Also I'm sure I didn't use the large file options when opening files = on a 32 bit platform so that too would need to be fixed. > =20 > -m >=20 > On Mon, Jun 28, 2010 at 3:57 AM, Justin Dailey = wrote: > There was no disconnection at this time. There seems to be enough = issues just getting it to send a large file as is. Once some bugs are = fixed then we will further test large bundles on a disconnected network = to cause it to store and forward bundles.=20 > =20 > After doing a few more tests we realized something else that was = happening. When sending over a 2GB file and causing it to store it, the = dtnd daemon said that the bundle was the correct size. However, the = bundle it has stored on the hard drive is 0 bytes long!!! Our previous = test showed that a 4KB chuck was getting duplicated. We are pretty sure = this data it copied was leftover in a buffer from the previous bundle = being sent.=20 > =20 > I'm not too familiar with the inner workings of the code, but I'm = guessing that some part of the code is using an "int" and should be = using an "unsigned int" (we are running 32-bit OS's) and causing = anything over the 2GB mark to wrap around to a negative value and = causing an uncaught error. I hope this helps anybody working on the code = at this time. I'll see what all code I can dig through of it and see if = I can't find the bug. > =20 > Thanks, > Justin Dailey > Shawnee State University - Cyber Center > Research Assistant=20 >=20 > --- On Sat, 6/26/10, Ivancic, William D. (GRC-RHN0) = wrote: >=20 > From: Ivancic, William D. (GRC-RHN0) > Subject: RE: [dtn-users] Some very interesting results with large = bundles... > To: "Justin Dailey" , "stephen.farrell@cs.tcd.ie" = , "L.Wood@surrey.ac.uk" > Cc: "dtn-users@maillists.intel-research.net" = > Date: Saturday, June 26, 2010, 11:43 PM > =20 >=20 > Justin, yoiu had multi-hop. Was there disconnection such that there = was store and forward verses just forward? >=20 > Will > ________________________________________ > From: dtn-users-bounces@maillists.intel-research.net = [dtn-users-bounces@maillists.intel-research.net] On Behalf Of Justin = Dailey [dail8859@yahoo.com] > Sent: Friday, June 25, 2010 11:55 AM > To: stephen.farrell@cs.tcd.ie; L.Wood@surrey.ac.uk > Cc: dtn-users@maillists.intel-research.net > Subject: [dtn-users] Some very interesting results with large = bundles... >=20 > First of all, Stephen, I'd be glad to take you up on that offer some = time :) >=20 > Lloyd, the 4.4GB file was just a ~1.5GB iso file concatenated together = 3 times, so we are not for sure what the 396MB was in relation to it. >=20 > However, those attempts were quick tests just to see some results. Now = we have come up with some better ways of getting different sized files = and ways of telling what parts of the file got there. Pretty much the = high-tech solution is to make a file containing the text = "1\n2\n3\n4\n..." and so on and make it as large as we want (1GB, 1.5GB, = 2GB...) . That way whenever we get a part of the file, we will be able = to tell what part it is. This makes inspecting the files (ie using the = head and tail command and visually inspecting) easy to get an idea of = what went wrong. >=20 > Note: Testbed is using TCP CL, 4 hops, no delay/corruption >=20 > Here are some things we have noticed. We first noticed that sometimes = the call to "dtnsend" returned immediately, other times it took more = than a minute to return from the command. During the times it took a = while to return, the dtnd process was using more CPU than normal (I'm = guessing it is processing the large file at this time) As soon as it = returned (whether the call returned immediately, or several minutes = later), then there will be heavy network traffic as expected. We = correlated this "anomaly" to whether the file got to the endpoint = correctly! Any time the dtnsend took a while, the file would be intact = at the receiving node. >=20 > Secondly, we've noticed so far that any file under 2GB will cause = dtnsend to take several minutes, and get to the endpoint correctly. = (Thus far we have correctly sent 1.5, 1.75, and 1.9GB files over our = network). >=20 > We have tried a 2GB and 2.2GB file but the data is not correct. >=20 > After doing some visual inspection of the received data for the 2.2GB = file, it seems that the whole 2.2GB file is a 4KB chunk of data that = has been duplicated over and over again. The 4KB chunk has some data at = the end of it that includes the sender EID, destination EID, and some = unreadable characters. If any body is interested I do have the first = 1000, and last 1000 lines of the received 2.2GB file. >=20 > Sorry for such a long message but I feel this is well worth it. >=20 > Thanks, > Justin Dailey > Shawnee State University - Cyber Center > Research Assistant >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > dtn-users mailing list > dtn-users@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-users >=20 > =20 > _______________________________________________ > dtn-users mailing list > dtn-users@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-users --Apple-Mail-18-928722615 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii My reaction is that a walk-through and revision of = the existing code base would probably be more fruitful.  The DARPA = DTN program (BBN more specifically) wound up doing a re-write.  You = may want to drop Preston Marshall an e-mail regarding his thoughts on = the motivation and results of doing so; somebody from BBN could also = offer some perspective.

- = K

On Jun 28, 2010, at Jun 285:56 AMPDT, Ivancic, = William D. (GRC-RHN0) wrote:

Just curious.  DTN-2 has severed us well for = quite some time. Many thanks to Mike Demmer and others  for getting = the core in place and being extremely useable and useful.  My = colleagues have expressed interested in a possible re-write (more like = re-implementation not a changing of the specification).  With these = noted limitations on bundle size and such, what are others thoughts on = this?
 demmer@gmail.com [mailto:demmer@gmail.com] On Behalf Of Michael = Demmer
Sent: Monday, June 28, 2010 3:38 = AM
To: Justin = Dailey
Cc: stephen.farrell@cs.tcd.ie; L.Wood@surrey.ac.uk; Ivancic, William = D. (GRC-RHN0);  Re: [dtn-users] Some very = interesting results with large = bundles...

-m

On Mon, Jun 28, 2010 at = 3:57 AM, Justin Dailey <
There was no disconnection at this time. There seems to be = enough issues just getting it to send a large file as is. Once some bugs = are fixed then we will further test large bundles on a disconnected = network to cause it to store and forward = bundles. 
After doing a few more = tests we realized something else that was happening. When sending over a = 2GB file and causing it to store it, the dtnd daemon said that the = bundle was the correct size. However, the bundle it has stored on the = hard drive is 0 bytes long!!! Our previous test showed that a 4KB chuck = was getting duplicated. We are pretty sure this data it copied was = leftover in a buffer from the previous bundle being = sent. 
I'm not too familiar with = the inner workings of the code, but I'm guessing that some part of the = code is using an "int" and should be using an "unsigned int" (we are = running 32-bit OS's) and causing anything over the 2GB mark to wrap = around to a negative value and causing an uncaught error. I hope this = helps anybody working on the code at this time. I'll see what all code I = can dig through of it and see if I can't find the = bug.
Justin = Dailey
Shawnee State University = - Cyber Center
Research = Assistant 

From: Ivancic, William D. (GRC-RHN0) <L.Wood@surrey.ac.uk" <L.Wood@surrey.ac.uk>
Cc: = " 

Justin, yoiu had multi-hop.  Was there disconnection such = that there was store and forward verses just = forward?

Will
________________________________________
From:<= span class=3D"Apple-converted-space">  [   
Note: Testbed is using TCP CL, 4 hops, no = delay/corruption

Here are some things we have noticed. We first = noticed that sometimes the call to "dtnsend" returned immediately, other = times it took more than a minute to return from the command. During the = times it took a while to return, the dtnd process was using more CPU = than normal (I'm guessing it is processing the large file at this time) = As soon as it returned (whether the call returned immediately, or = several minutes later), then there will be heavy network traffic as = expected. We correlated this "anomaly" to whether the file got to the = endpoint correctly! Any time the dtnsend took a while, the file would be = intact at the receiving node.

Secondly, we've noticed so far that = any file under 2GB will cause dtnsend to take several minutes, and get = to the endpoint correctly. (Thus far we have correctly sent 1.5, 1.75, = and 1.9GB files over our network).

We have tried a 2GB and 2.2GB = file but the data is not correct.

After doing some visual = inspection of the received data for the 2.2GB file, it seems that  = the whole 2.2GB file is a 4KB chunk of data that has been duplicated = over and over again. The 4KB chunk has some data at the end of it that = includes the sender EID, destination EID, and some unreadable = characters. If any body is interested I do have the first 1000, and last = 1000 lines of the received 2.2GB file.

Sorry for such a long = message but I feel this is well worth it.

Thanks,
Justin = Dailey
Shawnee State University - Cyber Center
Research = Assistant




<= /tr>

To: Michael Demmer , Justin Dailey Date: Mon, 28 Jun 2010 07:56:32 -0500 Thread-Topic: [dtn-users] Some very interesting results with large bundles... Thread-Index: AcsWlO+FZSGoKAvaSl2Bk86/dCWKvQAK7wGA Message-ID: <7BBFF2424089F04FB7D62F800895E2B629A8B36EE7@NDJSSCC07.ndc.nasa.gov> References: <7BBFF2424089F04FB7D62F800895E2B629A8B79A08@NDJSSCC07.ndc.nasa.gov> <644882.38065.qm@web56608.mail.re3.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7BBFF2424089F04FB7D62F800895E2B629A8B36EE7NDJSSCC07ndcn_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-28_02:2010-02-06, 2010-06-28, 2010-06-28 signatures=0 Cc: "dtn-users@maillists.intel-research.net" , "L.Wood@surrey.ac.uk" Subject: Re: [dtn-users] Some very interesting results with large bundles... X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 12:56:50 -0000 --_000_7BBFF2424089F04FB7D62F800895E2B629A8B36EE7NDJSSCC07ndcn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just curious. DTN-2 has severed us well for quite some time. Many thanks t= o Mike Demmer and others for getting the core in place and being extremely= useable and useful. My colleagues have expressed interested in a possible= re-write (more like re-implementation not a changing of the specification)= . With these noted limitations on bundle size and such, what are others th= oughts on this? Personally, I think we need to see if there is a RFC5050-bis first as the s= pecification may change as well at that time. Thoughts? --Will From: demmer@gmail.com [mailto:demmer@gmail.com] On Behalf Of Michael Demme= r Sent: Monday, June 28, 2010 3:38 AM To: Justin Dailey Cc: stephen.farrell@cs.tcd.ie; L.Wood@surrey.ac.uk; Ivancic, William D. (GR= C-RHN0); dtn-users@maillists.intel-research.net Subject: Re: [dtn-users] Some very interesting results with large bundles..= . For what it's worth when I wrote DTN2 I did not think to design for >2GB bu= ndles, so I suspect there are multiple places where an int (signed or unsig= ned) is used to store either a structure length or file offset. Also I'm sure I didn't use the large file options when opening files on a 3= 2 bit platform so that too would need to be fixed. -m On Mon, Jun 28, 2010 at 3:57 AM, Justin Dailey > wrote: There was no disconnection at this time. There seems to be enough issues ju= st getting it to send a large file as is. Once some bugs are fixed then we = will further test large bundles on a disconnected network to cause it to st= ore and forward bundles. After doing a few more tests we realized something else that was happening.= When sending over a 2GB file and causing it to store it, the dtnd daemon s= aid that the bundle was the correct size. However, the bundle it has stored= on the hard drive is 0 bytes long!!! Our previous test showed that a 4KB c= huck was getting duplicated. We are pretty sure this data it copied was lef= tover in a buffer from the previous bundle being sent. I'm not too familiar with the inner workings of the code, but I'm guessing = that some part of the code is using an "int" and should be using an "unsign= ed int" (we are running 32-bit OS's) and causing anything over the 2GB mark= to wrap around to a negative value and causing an uncaught error. I hope t= his helps anybody working on the code at this time. I'll see what all code = I can dig through of it and see if I can't find the bug. Thanks, Justin Dailey Shawnee State University - Cyber Center Research Assistant --- On Sat, 6/26/10, Ivancic, William D. (GRC-RHN0) > wrote: From: Ivancic, William D. (GRC-RHN0) > Subject: RE: [dtn-users] Some very interesting results with large bundles..= . To: "Justin Dailey" >, "steph= en.farrell@cs.tcd.ie" >, "L.Wood@surrey.ac.uk" > Cc: "dtn-users@maillists.intel-research.net" > Date: Saturday, June 26, 2010, 11:43 PM Justin, yoiu had multi-hop. Was there disconnection such that there was st= ore and forward verses just forward? Will ________________________________________ From: dtn-users-bounces@maillists.intel-research.net [dtn-users-bounces@maill= ists.intel-research.net] On Behalf Of Justin Dailey [dail8859@yahoo.com] Sent: Friday, June 25, 2010 11:55 AM To: stephen.farrell@cs.tcd.ie; L.Wood@surrey.ac.uk Cc: dtn-users@maillists.intel-research.net Subject: [dtn-users] Some very interesting results with large bundles... First of all, Stephen, I'd be glad to take you up on that offer some time := ) Lloyd, the 4.4GB file was just a ~1.5GB iso file concatenated together 3 ti= mes, so we are not for sure what the 396MB was in relation to it. However, those attempts were quick tests just to see some results. Now we h= ave come up with some better ways of getting different sized files and ways= of telling what parts of the file got there. Pretty much the high-tech sol= ution is to make a file containing the text "1\n2\n3\n4\n..." and so on an= d make it as large as we want (1GB, 1.5GB, 2GB...) . That way whenever we g= et a part of the file, we will be able to tell what part it is. This makes = inspecting the files (ie using the head and tail command and visually inspe= cting) easy to get an idea of what went wrong. Note: Testbed is using TCP CL, 4 hops, no delay/corruption Here are some things we have noticed. We first noticed that sometimes the c= all to "dtnsend" returned immediately, other times it took more than a minu= te to return from the command. During the times it took a while to return, = the dtnd process was using more CPU than normal (I'm guessing it is process= ing the large file at this time) As soon as it returned (whether the call r= eturned immediately, or several minutes later), then there will be heavy ne= twork traffic as expected. We correlated this "anomaly" to whether the file= got to the endpoint correctly! Any time the dtnsend took a while, the file= would be intact at the receiving node. Secondly, we've noticed so far that any file under 2GB will cause dtnsend t= o take several minutes, and get to the endpoint correctly. (Thus far we hav= e correctly sent 1.5, 1.75, and 1.9GB files over our network). We have tried a 2GB and 2.2GB file but the data is not correct. After doing some visual inspection of the received data for the 2.2GB file,= it seems that the whole 2.2GB file is a 4KB chunk of data that has been d= uplicated over and over again. The 4KB chunk has some data at the end of it= that includes the sender EID, destination EID, and some unreadable charact= ers. If any body is interested I do have the first 1000, and last 1000 line= s of the received 2.2GB file. Sorry for such a long message but I feel this is well worth it. Thanks, Justin Dailey Shawnee State University - Cyber Center Research Assistant _______________________________________________ dtn-users mailing list dtn-users@maillists.intel-research.net http://maillists.intel-research.net/mailman/listinfo/dtn-users --_000_7BBFF2424089F04FB7D62F800895E2B629A8B36EE7NDJSSCC07ndcn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just curious.  DTN-2 has severed us well for quite some time. Many thanks to Mike Demmer and others  for getting the core in p= lace and being extremely useable and useful.  My colleagues have expressed interested in a possible re-write (more like re-implementation not a changi= ng of the specification).  With these noted limitations on bundle size an= d such, what are others thoughts on this?

 

Personally, I think we need to see if there is a RFC5050-bis first as the specification may change as well at that time.

 

Thoughts?

 

 

--Will

 

From: demmer@gmail.= com [mailto:demmer@gmail.com] On Behalf Of Michael Demmer
Sent: Monday, June 28, 2010 3:38 AM
To: Justin Dailey
Cc: stephen.farrell@cs.tcd.ie; L.Wood@surrey.ac.uk; Ivancic, William= D. (GRC-RHN0); dtn-users@maillists.intel-research.net
Subject: Re: [dtn-users] Some very interesting results with large bundles...

 

For what it's worth when I wrote DTN2 I did not think = to design for >2GB bundles, so I suspect there are multiple places where an= int (signed or unsigned) is used to store either a structure length or file offset. 

 

Also I'm sure I didn't use the large file options when opening files on a 32 bit platform so that too would need to be fixed.=

 

-m

On Mon, Jun 28, 2010 at 3:57 AM, Justin Dailey <dail8859@yahoo.com> wrote:

There was no disconnection at this time. There seems= to be enough issues just getting it to send a large file as is. Once some bugs = are fixed then we will further test large bundles on a disconnected network t= o cause it to store and forward bundles. 

 

After doing a few more tests we realized something e= lse that was happening. When sending over a 2GB file and causing it to store it, t= he dtnd daemon said that the bundle was the correct size. However, the bundl= e it has stored on the hard drive is 0 bytes long!!! Our previous test showed = that a 4KB chuck was getting duplicated. We are pretty sure this data it copie= d was leftover in a buffer from the previous bundle being sent. <= /o:p>

 

I'm not too familiar with the inner workings of the = code, but I'm guessing that some part of the code is using an "int" a= nd should be using an "unsigned int" (we are running 32-bit OS's) = and causing anything over the 2GB mark to wrap around to a negative value and causing an uncaught error. I hope this helps anybody working on the code = at this time. I'll see what all code I can dig through of it and see if I ca= n't find the bug.

 

Thanks,

Justin Dailey

Shawnee State University - Cyber Center

Research Assistant 


--- On Sat, 6/26/10, Ivancic, William D. (GRC-RHN0) <william.d.iv= ancic@nasa.gov> wrote:


From: Ivancic, William D. (GRC-RHN0) <william.d.iv= ancic@nasa.gov>
Subject: RE: [dtn-users] Some very interesting results with large bundles= ...
To: "Justin Dailey" <dail8859@yahoo.com>, "stephen.farre= ll@cs.tcd.ie" <stephe= n.farrell@cs.tcd.ie>, "L.Wood@sur= rey.ac.uk" <L.Wood@surre= y.ac.uk>
Cc: "dtn-users@maillists.intel-research.net" <= dtn-users@maillists.intel-research.net>
Date: Saturday, June 26, 2010, 11:43 PM

 

Justin, yoiu had multi-hop.  Was there disconnection such that there was store and forward verses just forward?

Will
________________________________________
From: dtn-users-bounces@maillists.intel-research.net [dtn-users-bounces@maillists.intel-research.net] On = Behalf Of Justin Dailey [dail8859@yahoo.com]
Sent: Friday, June 25, 2010 11:55 AM
To: stephen.farrell@cs.tcd.ie; = L.Wood@surrey.ac.uk
Cc: dtn-users@maillists.intel-research.net
Subject: [dtn-users] Some very interesting results with large bundles...<= br>
First of all, Stephen, I'd be glad to take you up on that offer some time= :)

Lloyd, the 4.4GB file was just a ~1.5GB iso file concatenated together 3 times, so we are not for sure what the 396MB was in relation to it.

However, those attempts were quick tests just to see some results. Now we have come up with some better ways of getting different sized files and w= ays of telling what parts of the file got there. Pretty much the high-tech solution is to make  a file containing the text "1\n2\n3\n4\n..." and so on and make it as large as we want (1G= B, 1.5GB, 2GB...) . That way whenever we get a part of the file, we will be = able to tell what part it is. This makes inspecting the files (ie using the he= ad and tail command and visually inspecting) easy to get an idea of what wen= t wrong.

Note: Testbed is using TCP CL, 4 hops, no delay/corruption

Here are some things we have noticed. We first noticed that sometimes the call to "dtnsend" returned immediately, other times it took mor= e than a minute to return from the command. During the times it took a whil= e to return, the dtnd process was using more CPU than normal (I'm guessing it = is processing the large file at this time) As soon as it returned (whether t= he call returned immediately, or several minutes later), then there will be heavy network traffic as expected. We correlated this "anomaly"= to whether the file got to the endpoint correctly! Any time the dtnsend took= a while, the file would be intact at the receiving node.

Secondly, we've noticed so far that any file under 2GB will cause dtnsend= to take several minutes, and get to the endpoint correctly. (Thus far we hav= e correctly sent 1.5, 1.75, and 1.9GB files over our network).

We have tried a 2GB and 2.2GB file but the data is not correct.

After doing some visual inspection of the received data for the 2.2GB fil= e, it seems that  the whole 2.2GB file is a 4KB chunk of data that has = been duplicated over and over again. The 4KB chunk has some data at the end of= it that includes the sender EID, destination EID, and some unreadable characters. If any body is interested I do have the first 1000, and last = 1000 lines of the received 2.2GB file.

Sorry for such a long message but I feel this is well worth it.

Thanks,
Justin Dailey
Shawnee State University - Cyber Center
Research Assistant



_______________________________________________
dtn-users mailing list
dtn-users@maillis= ts.intel-research.net
http://maillists.intel-research.net/mailman/listinfo/dtn-= users

 

--_000_7BBFF2424089F04FB7D62F800895E2B629A8B36EE7NDJSSCC07ndcn_-- Received: from mail-qy0-f169.google.com (mail-qy0-f169.google.com [209.85.216.169]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o5S7cglW022462 for ; Mon, 28 Jun 2010 00:38:42 -0700 Received: by qyk27 with SMTP id 27so896597qyk.28 for ; Mon, 28 Jun 2010 00:38:42 -0700 (PDT) Received: by 10.224.104.220 with SMTP id q28mr2938478qao.171.1277710721369; Mon, 28 Jun 2010 00:38:41 -0700 (PDT) MIME-Version: 1.0 Sender: demmer@gmail.com Received: by 10.229.238.78 with HTTP; Mon, 28 Jun 2010 00:38:21 -0700 (PDT) In-Reply-To: <644882.38065.qm@web56608.mail.re3.yahoo.com> References: <7BBFF2424089F04FB7D62F800895E2B629A8B79A08@NDJSSCC07.ndc.nasa.gov> <644882.38065.qm@web56608.mail.re3.yahoo.com> From: Michael Demmer Date: Mon, 28 Jun 2010 09:38:21 +0200 X-Google-Sender-Auth: i3qmhqbVmPIg4dtZVM5uMZGIYzI Message-ID: To: Justin Dailey Content-Type: multipart/alternative; boundary=00c09f905c57ac494e048a1235ed Cc: "dtn-users@maillists.intel-research.net" , "L.Wood@surrey.ac.uk" Subject: Re: [dtn-users] Some very interesting results with large bundles... X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 07:38:43 -0000 --00c09f905c57ac494e048a1235ed Content-Type: text/plain; charset=ISO-8859-1 For what it's worth when I wrote DTN2 I did not think to design for >2GB bundles, so I suspect there are multiple places where an int (signed or unsigned) is used to store either a structure length or file offset. Also I'm sure I didn't use the large file options when opening files on a 32 bit platform so that too would need to be fixed. -m On Mon, Jun 28, 2010 at 3:57 AM, Justin Dailey wrote: > There was no disconnection at this time. There seems to be enough issues > just getting it to send a large file as is. Once some bugs are fixed then we > will further test large bundles on a disconnected network to cause it to > store and forward bundles. > > After doing a few more tests we realized something else that was happening. > When sending over a 2GB file and causing it to store it, the dtnd daemon > said that the bundle was the correct size. However, the bundle it has stored > on the hard drive is 0 bytes long!!! Our previous test showed that a 4KB > chuck was getting duplicated. We are pretty sure this data it copied was > leftover in a buffer from the previous bundle being sent. > > I'm not too familiar with the inner workings of the code, but I'm guessing > that some part of the code is using an "int" and should be using an > "unsigned int" (we are running 32-bit OS's) and causing anything over the > 2GB mark to wrap around to a negative value and causing an uncaught error. I > hope this helps anybody working on the code at this time. I'll see what all > code I can dig through of it and see if I can't find the bug. > > Thanks, > Justin Dailey > Shawnee State University - Cyber Center > Research Assistant > > --- On *Sat, 6/26/10, Ivancic, William D. (GRC-RHN0) < > william.d.ivancic@nasa.gov>* wrote: > > > From: Ivancic, William D. (GRC-RHN0) > Subject: RE: [dtn-users] Some very interesting results with large > bundles... > To: "Justin Dailey" , "stephen.farrell@cs.tcd.ie" < > stephen.farrell@cs.tcd.ie>, "L.Wood@surrey.ac.uk" > Cc: "dtn-users@maillists.intel-research.net" < > dtn-users@maillists.intel-research.net> > Date: Saturday, June 26, 2010, 11:43 PM > > > Justin, yoiu had multi-hop. Was there disconnection such that there was > store and forward verses just forward? > > Will > ________________________________________ > From: dtn-users-bounces@maillists.intel-research.net[ > dtn-users-bounces@maillists.intel-research.net] > On Behalf Of Justin Dailey [dail8859@yahoo.com > ] > Sent: Friday, June 25, 2010 11:55 AM > To: stephen.farrell@cs.tcd.ie; > L.Wood@surrey.ac.uk > Cc: dtn-users@maillists.intel-research.net > Subject: [dtn-users] Some very interesting results with large bundles... > > First of all, Stephen, I'd be glad to take you up on that offer some time > :) > > Lloyd, the 4.4GB file was just a ~1.5GB iso file concatenated together 3 > times, so we are not for sure what the 396MB was in relation to it. > > However, those attempts were quick tests just to see some results. Now we > have come up with some better ways of getting different sized files and ways > of telling what parts of the file got there. Pretty much the high-tech > solution is to make a file containing the text "1\n2\n3\n4\n..." and so on > and make it as large as we want (1GB, 1.5GB, 2GB...) . That way whenever we > get a part of the file, we will be able to tell what part it is. This makes > inspecting the files (ie using the head and tail command and visually > inspecting) easy to get an idea of what went wrong. > > Note: Testbed is using TCP CL, 4 hops, no delay/corruption > > Here are some things we have noticed. We first noticed that sometimes the > call to "dtnsend" returned immediately, other times it took more than a > minute to return from the command. During the times it took a while to > return, the dtnd process was using more CPU than normal (I'm guessing it is > processing the large file at this time) As soon as it returned (whether the > call returned immediately, or several minutes later), then there will be > heavy network traffic as expected. We correlated this "anomaly" to whether > the file got to the endpoint correctly! Any time the dtnsend took a while, > the file would be intact at the receiving node. > > Secondly, we've noticed so far that any file under 2GB will cause dtnsend > to take several minutes, and get to the endpoint correctly. (Thus far we > have correctly sent 1.5, 1.75, and 1.9GB files over our network). > > We have tried a 2GB and 2.2GB file but the data is not correct. > > After doing some visual inspection of the received data for the 2.2GB file, > it seems that the whole 2.2GB file is a 4KB chunk of data that has been > duplicated over and over again. The 4KB chunk has some data at the end of it > that includes the sender EID, destination EID, and some unreadable > characters. If any body is interested I do have the first 1000, and last > 1000 lines of the received 2.2GB file. > > Sorry for such a long message but I feel this is well worth it. > > Thanks, > Justin Dailey > Shawnee State University - Cyber Center > Research Assistant > > > > > > > > _______________________________________________ > dtn-users mailing list > dtn-users@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-users > > --00c09f905c57ac494e048a1235ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable For what it's worth when I wrote DTN2 I did not think to design for >= ;2GB bundles, so I suspect there are multiple places where an int (signed o= r unsigned) is used to store either a structure length or file offset.=A0
Also I'm sure I didn't use the large file options wh= en opening files on a 32 bit platform so that too would need to be fixed.
-m

On Mon, Jun 28, 2010= at 3:57 AM, Justin Dailey <dail8859@yahoo.com> wrote:
There was= no disconnection at this time. There seems to be enough issues just gettin= g it to send a large file as is. Once some bugs are fixed then we will furt= her test large bundles on a disconnected network to cause it to store and f= orward bundles.=A0

After doing a few more tests we realized something else that= was happening. When sending over a 2GB file and causing it to store it, th= e dtnd daemon said that the bundle was the correct size. However, the bundl= e it has stored on the hard drive is 0 bytes long!!! Our previous test show= ed that a 4KB chuck was getting duplicated. We are pretty sure this data it= copied was leftover in a buffer from the previous bundle being sent.=A0

I'm not too familiar with the inner workings of the= code, but I'm guessing that some part of the code is using an "in= t" and should be using an "unsigned int" (we are running 32-bit OS's) and cau= sing anything over the 2GB mark to wrap around to a negative value and caus= ing an uncaught error. I hope this helps anybody working on the code at thi= s time. I'll see what all code I can dig through of it and see if I can= 't find the bug.

Thanks,
Justin Dailey
=
Shawnee State University - Cyber Center
Research Assistant= =A0

--- On Sat, 6/26/10, Ivancic, William D. (GRC-RH= N0) <= william.d.ivancic@nasa.gov> wrote:

From: Ivancic, William D. (GRC-RHN0) <william.d.ivancic@nasa= .gov>
Subject: RE: [dtn-users] Some very interesting results with large bundles..= .
To: "Justin Dailey" <dail8859@yahoo.com>, "stephen.farrell@cs.tcd.ie&quo= t; <steph= en.farrell@cs.tcd.ie>, "L.Wood@surrey.ac.uk" <L.Wood@surrey= .ac.uk>
Cc: "dtn-users@maillists.intel-research.net&quo= t; <dtn-users@maillists.intel-research.net>
Date: Saturday, June 26, 2010, 11:43 PM

Justin, yoiu had multi-hop.=A0 Was there disconnection such that= there was store and forward verses just forward?

Will
__________= ______________________________
From: dtn-users-bounces@maillists.intel-research.n= et [dtn-users-bounces@maillists.intel-research= .net] On Behalf Of Justin Dailey [dail8859@yahoo.com]
Sent: Friday, June 25, 2010 11:55 AM
To: stephen.farrell@cs.tcd.ie; L.Wood@surrey.ac.uk
Cc: dtn-users@maillists.intel-research.net
Subject:= [dtn-users] Some very interesting results with large bundles...

Fir= st of all, Stephen, I'd be glad to take you up on that offer some time = :)

Lloyd, the 4.4GB file was just a ~1.5GB iso file concatenated together = 3 times, so we are not for sure what the 396MB was in relation to it.
However, those attempts were quick tests just to see some results. Now we= have come up with some better ways of getting different sized files and wa= ys of telling what parts of the file got there. Pretty much the high-tech s= olution is to make=A0 a file containing the text "1\n2\n3\n4\n..." and so on and make it as l= arge as we want (1GB, 1.5GB, 2GB...) . That way whenever we get a part of t= he file, we will be able to tell what part it is. This makes inspecting the= files (ie using the head and tail command and visually inspecting) easy to= get an idea of what went wrong.

Note: Testbed is using TCP CL, 4 hops, no delay/corruption

Here = are some things we have noticed. We first noticed that sometimes the call t= o "dtnsend" returned immediately, other times it took more than a= minute to return from the command. During the times it took a while to ret= urn, the dtnd process was using more CPU than normal (I'm guessing it i= s processing the large file at this time) As soon as it returned (whether t= he call returned immediately, or several minutes later), then there will be= heavy network traffic as expected. We correlated this "anomaly" = to whether the file got to the endpoint correctly! Any time the dtnsend took a while, the file would be intact at the receiving node.
<= br>Secondly, we've noticed so far that any file under 2GB will cause dt= nsend to take several minutes, and get to the endpoint correctly. (Thus far= we have correctly sent 1.5, 1.75, and 1.9GB files over our network).

We have tried a 2GB and 2.2GB file but the data is not correct.

= After doing some visual inspection of the received data for the 2.2GB file,= it seems that=A0 the whole 2.2GB file is a 4KB chunk of data that has been= duplicated over and over again. The 4KB chunk has some data at the end of = it that includes the sender EID, destination EID, and some unreadable chara= cters. If any body is interested I do have the first 1000, and last 1000 li= nes of the received 2.2GB file.

Sorry for such a long message but I feel this is well worth it.

= Thanks,
Justin Dailey
Shawnee State University - Cyber Center
Rese= arch Assistant







_______________________________________________
dtn-users mailing list
dtn-users@maillis= ts.intel-research.net
http://maillists.intel-research.net/mailman/listinfo/dtn-= users


--00c09f905c57ac494e048a1235ed-- Received: from n6.bullet.re3.yahoo.com (n6.bullet.re3.yahoo.com [68.142.237.91]) by maillists.intel-research.net (8.13.8/8.13.8) with SMTP id o5S1vHAt006195 for ; Sun, 27 Jun 2010 18:57:18 -0700 Received: from [68.142.237.89] by n6.bullet.re3.yahoo.com with NNFMP; 28 Jun 2010 01:57:16 -0000 Received: from [66.196.97.133] by t5.bullet.re3.yahoo.com with NNFMP; 28 Jun 2010 01:57:16 -0000 Received: from [127.0.0.1] by omp106.mail.re3.yahoo.com with NNFMP; 28 Jun 2010 01:57:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 879050.68018.bm@omp106.mail.re3.yahoo.com Received: (qmail 39233 invoked by uid 60001); 28 Jun 2010 01:57:16 -0000 Message-ID: <644882.38065.qm@web56608.mail.re3.yahoo.com> X-YMail-OSG: fipGcAUVM1nOp50PDIT55KoD9qHlMdoODz_FOGY0P51mK.0 eiMQ0OFDqreWz6m3NmLpQUlhJTW9G6P_NHV_4o5D7DoUR4Ges.egshaql.zd ZspzEp.AbvmNzk0ly7hiZ1iENZHm6HR7G45bRq06ISi.pVDCqMbgT8E.tOhk yKAHetBFKAlkR2X5s0sUrPm4uyzRuicwsET6QfWULIEu94P98yoamoi6uh3V JZg5pJkibaZovqboDOHFOy7tXKpqevHU.Uqgsic4qB7f1lU1GUq.HAA3ZLVz P7svepKjlaPihpupBn0zN_70vxv0sg0YElg4x_Zqxbaye0.ecKg-- Received: from [174.101.89.83] by web56608.mail.re3.yahoo.com via HTTP; Sun, 27 Jun 2010 18:57:16 PDT X-Mailer: YahooMailClassic/11.1.4 YahooMailWebService/0.8.104.274457 Date: Sun, 27 Jun 2010 18:57:16 -0700 (PDT) From: Justin Dailey To: "stephen.farrell@cs.tcd.ie" , "L.Wood@surrey.ac.uk" , " William D. \(GRC-RHN0\)Ivancic" In-Reply-To: <7BBFF2424089F04FB7D62F800895E2B629A8B79A08@NDJSSCC07.ndc.nasa.gov> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1563513210-1277690236=:38065" Cc: "dtn-users@maillists.intel-research.net" Subject: Re: [dtn-users] Some very interesting results with large bundles... X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 01:57:19 -0000 --0-1563513210-1277690236=:38065 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable There was no disconnection at this time. There seems to be enough issues ju= st getting it to send a large file as is. Once some bugs are fixed then we = will further test large bundles on a disconnected network to cause it to st= ore and forward bundles.=A0 After doing a few more tests we realized something else that was happening.= When sending over a 2GB file and causing it to store it, the dtnd daemon s= aid that the bundle was the correct size. However, the bundle it has stored= on the hard drive is 0 bytes long!!! Our previous test showed that a 4KB c= huck was getting duplicated. We are pretty sure this data it copied was lef= tover in a buffer from the previous bundle being sent.=A0 I'm not too familiar with the inner workings of the code, but I'm guessing = that some part of the code is using an "int" and should be using an "unsign= ed int" (we are running 32-bit OS's) and causing anything over the 2GB mark= to wrap around to a negative value and causing an uncaught error. I hope t= his helps anybody working on the code at this time. I'll see what all code = I can dig through of it and see if I can't find the bug. Thanks,Justin DaileyShawnee State University - Cyber CenterResearch Assista= nt=A0 --- On Sat, 6/26/10, Ivancic, William D. (GRC-RHN0) wrote: From: Ivancic, William D. (GRC-RHN0) Subject: RE: [dtn-users] Some very interesting results with large bundles..= . To: "Justin Dailey" , "stephen.farrell@cs.tcd.ie" , "L.Wood@surrey.ac.uk" Cc: "dtn-users@maillists.intel-research.net" Date: Saturday, June 26, 2010, 11:43 PM Justin, yoiu had multi-hop.=A0 Was there disconnection such that there was = store and forward verses just forward? Will ________________________________________ From: dtn-users-bounces@maillists.intel-research.net [dtn-users-bounces@mai= llists.intel-research.net] On Behalf Of Justin Dailey [dail8859@yahoo.com] Sent: Friday, June 25, 2010 11:55 AM To: stephen.farrell@cs.tcd.ie; L.Wood@surrey.ac.uk Cc: dtn-users@maillists.intel-research.net Subject: [dtn-users] Some very interesting results with large bundles... First of all, Stephen, I'd be glad to take you up on that offer some time := ) Lloyd, the 4.4GB file was just a ~1.5GB iso file concatenated together 3 ti= mes, so we are not for sure what the 396MB was in relation to it. However, those attempts were quick tests just to see some results. Now we h= ave come up with some better ways of getting different sized files and ways= of telling what parts of the file got there. Pretty much the high-tech sol= ution is to make=A0 a file containing the text "1\n2\n3\n4\n..." and so on = and make it as large as we want (1GB, 1.5GB, 2GB...) . That way whenever we= get a part of the file, we will be able to tell what part it is. This make= s inspecting the files (ie using the head and tail command and visually ins= pecting) easy to get an idea of what went wrong. Note: Testbed is using TCP CL, 4 hops, no delay/corruption Here are some things we have noticed. We first noticed that sometimes the c= all to "dtnsend" returned immediately, other times it took more than a minu= te to return from the command. During the times it took a while to return, = the dtnd process was using more CPU than normal (I'm guessing it is process= ing the large file at this time) As soon as it returned (whether the call r= eturned immediately, or several minutes later), then there will be heavy ne= twork traffic as expected. We correlated this "anomaly" to whether the file= got to the endpoint correctly! Any time the dtnsend took a while, the file= would be intact at the receiving node. Secondly, we've noticed so far that any file under 2GB will cause dtnsend t= o take several minutes, and get to the endpoint correctly. (Thus far we hav= e correctly sent 1.5, 1.75, and 1.9GB files over our network). We have tried a 2GB and 2.2GB file but the data is not correct. After doing some visual inspection of the received data for the 2.2GB file,= it seems that=A0 the whole 2.2GB file is a 4KB chunk of data that has been= duplicated over and over again. The 4KB chunk has some data at the end of = it that includes the sender EID, destination EID, and some unreadable chara= cters. If any body is interested I do have the first 1000, and last 1000 li= nes of the received 2.2GB file. Sorry for such a long message but I feel this is well worth it. Thanks, Justin Dailey Shawnee State University - Cyber Center Research Assistant =0A=0A=0A --0-1563513210-1277690236=:38065 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
=0A=0A=0A=0A=0A=0A=0A=0A --0-1563513210-1277690236=:38065-- Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o5R3ihNJ008647 for ; Sat, 26 Jun 2010 20:44:44 -0700 Received: from ndjsppt04.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 772F92D812E; Sat, 26 Jun 2010 22:44:43 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt04.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o5R3ih9D018234; Sat, 26 Jun 2010 22:44:43 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub04.ndc.nasa.gov ([10.202.202.163]) with mapi; Sat, 26 Jun 2010 22:44:43 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Justin Dailey , "stephen.farrell@cs.tcd.ie" , "L.Wood@surrey.ac.uk" Date: Sat, 26 Jun 2010 22:43:54 -0500 Thread-Topic: [dtn-users] Some very interesting results with large bundles... Thread-Index: AcsUh/HSVp0fR5SPRTSfk8kj+f6S4gBIwU55 Message-ID: <7BBFF2424089F04FB7D62F800895E2B629A8B79A08@NDJSSCC07.ndc.nasa.gov> References: <889967.67242.qm@web56601.mail.re3.yahoo.com> In-Reply-To: <889967.67242.qm@web56601.mail.re3.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-26_01:2010-02-06, 2010-06-26, 2010-06-26 signatures=0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id o5R3ihNJ008647 Cc: "dtn-users@maillists.intel-research.net" Subject: Re: [dtn-users] Some very interesting results with large bundles... X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2010 03:44:44 -0000 Justin, yoiu had multi-hop. Was there disconnection such that there was store and forward verses just forward? Will ________________________________________ From: dtn-users-bounces@maillists.intel-research.net [dtn-users-bounces@maillists.intel-research.net] On Behalf Of Justin Dailey [dail8859@yahoo.com] Sent: Friday, June 25, 2010 11:55 AM To: stephen.farrell@cs.tcd.ie; L.Wood@surrey.ac.uk Cc: dtn-users@maillists.intel-research.net Subject: [dtn-users] Some very interesting results with large bundles... First of all, Stephen, I'd be glad to take you up on that offer some time :) Lloyd, the 4.4GB file was just a ~1.5GB iso file concatenated together 3 times, so we are not for sure what the 396MB was in relation to it. However, those attempts were quick tests just to see some results. Now we have come up with some better ways of getting different sized files and ways of telling what parts of the file got there. Pretty much the high-tech solution is to make a file containing the text "1\n2\n3\n4\n..." and so on and make it as large as we want (1GB, 1.5GB, 2GB...) . That way whenever we get a part of the file, we will be able to tell what part it is. This makes inspecting the files (ie using the head and tail command and visually inspecting) easy to get an idea of what went wrong. Note: Testbed is using TCP CL, 4 hops, no delay/corruption Here are some things we have noticed. We first noticed that sometimes the call to "dtnsend" returned immediately, other times it took more than a minute to return from the command. During the times it took a while to return, the dtnd process was using more CPU than normal (I'm guessing it is processing the large file at this time) As soon as it returned (whether the call returned immediately, or several minutes later), then there will be heavy network traffic as expected. We correlated this "anomaly" to whether the file got to the endpoint correctly! Any time the dtnsend took a while, the file would be intact at the receiving node. Secondly, we've noticed so far that any file under 2GB will cause dtnsend to take several minutes, and get to the endpoint correctly. (Thus far we have correctly sent 1.5, 1.75, and 1.9GB files over our network). We have tried a 2GB and 2.2GB file but the data is not correct. After doing some visual inspection of the received data for the 2.2GB file, it seems that the whole 2.2GB file is a 4KB chunk of data that has been duplicated over and over again. The 4KB chunk has some data at the end of it that includes the sender EID, destination EID, and some unreadable characters. If any body is interested I do have the first 1000, and last 1000 lines of the received 2.2GB file. Sorry for such a long message but I feel this is well worth it. Thanks, Justin Dailey Shawnee State University - Cyber Center Research Assistant Received: from n15.bullet.mail.mud.yahoo.com (n15.bullet.mail.mud.yahoo.com [68.142.206.42]) by maillists.intel-research.net (8.13.8/8.13.8) with SMTP id o5PGtE1r005784 for ; Fri, 25 Jun 2010 09:55:14 -0700 Received: from [68.142.200.227] by n15.bullet.mail.mud.yahoo.com with NNFMP; 25 Jun 2010 16:55:15 -0000 Received: from [66.196.97.153] by t8.bullet.mud.yahoo.com with NNFMP; 25 Jun 2010 16:55:15 -0000 Received: from [127.0.0.1] by omp206.mail.re3.yahoo.com with NNFMP; 25 Jun 2010 16:55:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 101047.19429.bm@omp206.mail.re3.yahoo.com Received: (qmail 68028 invoked by uid 60001); 25 Jun 2010 16:55:14 -0000 Message-ID: <889967.67242.qm@web56601.mail.re3.yahoo.com> X-YMail-OSG: pnEAHjMVM1lFTkJDC6WrY7qvkObrxI9fpmsvXc5v7lbbje9 nmpARyOgkL605w3CcXA3dDY2Dx7NgiXSJWpg_zzLMagl3wgSwPTTAPFA8cpK oQkii_Jcoden0JdxR7yGEAx3985VhXGwE2vKajuhqqOwocQM89MZ.8yGwa4H vIXpumrTMWOIu3Z3c1XY6FWDoZf83y.BtNUjehAWApCYKfv2XJXrLhRRcRpv MS0hkqo4Oju31c0idavQMTQhQR5e9VsjYrZCJvj.Q_h.F6qKVyxsN5dWUFvB VYryvtwvpvU.8YIrMGxbbCZya0uCZvNcjCJbTDEGR Received: from [98.108.71.33] by web56601.mail.re3.yahoo.com via HTTP; Fri, 25 Jun 2010 09:55:14 PDT X-Mailer: YahooMailClassic/11.1.4 YahooMailWebService/0.8.104.274457 Date: Fri, 25 Jun 2010 09:55:14 -0700 (PDT) From: Justin Dailey To: stephen.farrell@cs.tcd.ie, L.Wood@surrey.ac.uk MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-84482628-1277484914=:67242" Cc: dtn-users@maillists.intel-research.net Subject: [dtn-users] Some very interesting results with large bundles... X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 16:55:15 -0000 --0-84482628-1277484914=:67242 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable First of all, Stephen, I'd be glad to take you up on that offer some time := ) Lloyd, the 4.4GB file was just a ~1.5GB iso file=A0concatenated=A0together = 3 times, so we are not for sure what the 396MB was in relation to it. However, those attempts were quick tests just to see some results. Now we h= ave come up with some better ways of getting different sized files and ways= of telling what parts of the file got there. Pretty much the high-tech sol= ution is to make =A0a file=A0containing=A0the text "1\n2\n3\n4\n..." and so= on and make it as large as we want (1GB, 1.5GB, 2GB...) . That way wheneve= r we get a part of the file,=0A we will be able to tell what part it is. Th= is makes inspecting the files (ie using the head and tail command and visua= lly inspecting) easy to get an idea of what went=0A wrong. Note: Testbed is using TCP CL, 4 hops, no delay/corruption Here are some things we have noticed. We first noticed that sometimes the c= all to "dtnsend" returned immediately, other times it took more than a minu= te to return from the command. During the times it took a while to return, = the dtnd process was using more CPU than normal (I'm guessing it is process= ing the large file at this time) As soon as it returned (whether the call r= eturned immediately, or several minutes later), then there will be heavy ne= twork traffic as expected. We=A0correlated=A0this "anomaly" to whether the = file got to the endpoint correctly! Any time the dtnsend took a while, the = file would be intact at the receiving node. Secondly, we've noticed so far that any file under 2GB will cause dtnsend t= o take several minutes, and get to the endpoint correctly. (Thus far we hav= e correctly sent 1.5, 1.75,=0A and 1.9GB=0A files over our network). =A0 We have tried a 2GB and 2.2GB file but the data is not correct.=A0 After doing some visual inspection of the=A0received=A0data for the 2.2GB f= ile, it seems that =A0the whole 2.2GB file is a 4KB chunk of data that has = been duplicated over and over again. The 4KB chunk has some data at the end= of it that includes the sender EID, destination EID, and some unreadable c= haracters. If any body is interested I do have the first 1000, and last 100= 0 lines of the received 2.2GB file. Sorry for such a long message but I feel this is well worth it. Thanks,Justin DaileyShawnee State University - Cyber CenterResearch Assista= nt =0A=0A=0A --0-84482628-1277484914=:67242 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
There was no disconnection at this time. Ther= e seems to be enough issues just getting it to send a large file as is. Onc= e some bugs are fixed then we will further test large bundles on a disconne= cted network to cause it to store and forward bundles. 

=
After doing a few more tests we realized something else that was happe= ning. When sending over a 2GB file and causing it to store it, the dtnd dae= mon said that the bundle was the correct size. However, the bundle it has s= tored on the hard drive is 0 bytes long!!! Our previous test showed that a = 4KB chuck was getting duplicated. We are pretty sure this data it copied wa= s leftover in a buffer from the previous bundle being sent. 

I'm not too familiar with the inner workings of the code, b= ut I'm guessing that some part of the code is using an "int" and should be using an "unsigned int" (we are running 32-bit OS's) and causing anything = over the 2GB mark to wrap around to a negative value and causing an uncaugh= t error. I hope this helps anybody working on the code at this time. I'll s= ee what all code I can dig through of it and see if I can't find the bug.

Thanks,
Justin Dailey
Shawnee S= tate University - Cyber Center
Research Assistant 

--- On Sat, 6/26/10, Ivancic, William D. (GRC-RHN0) <william.= d.ivancic@nasa.gov> wrote:

From:= Ivancic, William D. (GRC-RHN0) <william.d.ivancic@nasa.gov>
Subje= ct: RE: [dtn-users] Some very interesting results with large bundles...
= To: "Justin Dailey" <dail8859@yahoo.com>, "stephen.farrell@cs.tcd.ie"= <stephen.farrell@cs.tcd.ie>, "L.Wood@surrey.ac.uk" <L.Wood@surrey.ac.uk>
Cc: "dtn-users@maillists.intel-research.net= " <dtn-users@maillists.intel-research.net>
Date: Saturday, June 26= , 2010, 11:43 PM

Justin, yoiu had multi-hop= .  Was there disconnection such that there was store and forward verse= s just forward?

Will
________________________________________
= From: dt= n-users-bounces@maillists.intel-research.net [dtn-users-bounces@maillists.intel= -research.net] On Behalf Of Justin Dailey [dail8859@yahoo.co= m]
Sent: Friday, June 25, 2010 11:55 AM
To: stephen.farrell@cs.tcd.ie; L.Wood@s= urrey.ac.uk
Cc: d= tn-users@maillists.intel-research.net
Subject: [dtn-users] Some very= interesting results with large bundles...

First of all, Stephen, I'= d be glad to take you up on that offer some time :)

Lloyd, the 4.4GB= file was just a ~1.5GB iso file concatenated together 3 times, so we are n= ot for sure what the 396MB was in relation to it.

However, those att= empts were quick tests just to see some results. Now we have come up with s= ome better ways of getting different sized files and ways of telling what p= arts of the file got there. Pretty much the high-tech solution is to make&n= bsp; a file containing the text "1\n2\n3\n4\n..." and so on and make it as large as we= want (1GB, 1.5GB, 2GB...) . That way whenever we get a part of the file, w= e will be able to tell what part it is. This makes inspecting the files (ie= using the head and tail command and visually inspecting) easy to get an id= ea of what went wrong.

Note: Testbed is using TCP CL, 4 hops, no del= ay/corruption

Here are some things we have noticed. We first noticed= that sometimes the call to "dtnsend" returned immediately, other times it = took more than a minute to return from the command. During the times it too= k a while to return, the dtnd process was using more CPU than normal (I'm g= uessing it is processing the large file at this time) As soon as it returne= d (whether the call returned immediately, or several minutes later), then t= here will be heavy network traffic as expected. We correlated this "anomaly= " to whether the file got to the endpoint correctly! Any time the dtnsend took a while, the file would be intact at the receiving node.
<= br>Secondly, we've noticed so far that any file under 2GB will cause dtnsen= d to take several minutes, and get to the endpoint correctly. (Thus far we = have correctly sent 1.5, 1.75, and 1.9GB files over our network).

We= have tried a 2GB and 2.2GB file but the data is not correct.

After = doing some visual inspection of the received data for the 2.2GB file, it se= ems that  the whole 2.2GB file is a 4KB chunk of data that has been du= plicated over and over again. The 4KB chunk has some data at the end of it = that includes the sender EID, destination EID, and some unreadable characte= rs. If any body is interested I do have the first 1000, and last 1000 lines= of the received 2.2GB file.

Sorry for such a long message but I fee= l this is well worth it.

Thanks,
Justin Dailey
Shawnee State U= niversity - Cyber Center
Research Assistant





=
<= tr>
= First of all, Stephen, I'd be glad to take you up on that offer some time := )

Lloyd, the 4.4GB file was just a ~1.5GB iso file = concatenated together 3 times, so we are not for sure what the 396MB w= as in relation to it.

However, those attempts were= quick tests just to see some results. Now we have come up with some better= ways of getting different sized files and ways of telling what parts of th= e file got there. Pretty much the high-tech solution is to make  a fil= e containing the text "1\n2\n3\n4\n..." and so on and make it as large as we want (1GB, 1.5GB, 2= GB...) . That way whenever we get a part of the file,=0A we will be able to= tell what part it is. This makes inspecting the files (ie using the head a= nd tail command and visually inspecting) easy to get an idea of what went= =0A wrong.

Note: Testbed is using TCP CL, 4 hops, = no delay/corruption

Here are some things we have n= oticed. We first noticed that sometimes the call to "dtnsend" returned imme= diately, other times it took more than a minute to return from the command.= During the times it took a while to return, the dtnd process was using mor= e CPU than normal (I'm guessing it is processing the large file at this tim= e) As soon as it returned (whether the call returned immediately, or severa= l minutes later), then there will be heavy network traffic as expected. We&= nbsp;correlated this "anomaly" to whether the file got to the endpoint= correctly! Any time the dtnsend took a while, the file would be intact at = the receiving node.

Secondly, we've noticed so far= that any file under 2GB will cause dtnsend to take several minutes, and ge= t to the endpoint correctly. (Thus far we have correctly sent 1.5, 1.75,=0A= and 1.9GB=0A files over our network).  

We h= ave tried a 2GB and 2.2GB file but the data is not correct. 

After doing some visual inspection of the received&nbs= p;data for the 2.2GB file, it seems that  the whole 2.2GB file is a 4K= B chunk of data that has been duplicated over and over again. The 4KB chunk= has some data at the end of it that includes the sender EID, destination E= ID, and some unreadable characters. If any body is interested I do have the= first 1000, and last 1000 lines of the received 2.2GB file.

=
Sorry for such a long message but I feel this is well worth it.<= /div>

Thanks,
Justin Dailey
Shawnee = State University - Cyber Center
Research Assistant

=

=0A=0A --0-84482628-1277484914=:67242-- Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o5OMPB1o022859 for ; Thu, 24 Jun 2010 15:25:12 -0700 X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-6.tower-82.messagelabs.com!1277418310!18260659!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.35] Received: (qmail 18824 invoked from network); 24 Jun 2010 22:25:10 -0000 Received: from unknown (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-6.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 24 Jun 2010 22:25:10 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.69]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Thu, 24 Jun 2010 23:25:10 +0100 From: To: Date: Thu, 24 Jun 2010 23:25:09 +0100 Thread-Topic: [dtn-users] dtn-users Digest, Vol 32, Issue 2 Thread-Index: AcsT7BrZ0dipMpXITvyjvBtOwj4pUQ== Message-ID: <787DE57A-A360-41C5-9430-F8B409EB9B11@surrey.ac.uk> References: <263438.77139.qm@web56602.mail.re3.yahoo.com> <4C23D6A4.9050405@cs.tcd.ie> In-Reply-To: <4C23D6A4.9050405@cs.tcd.ie> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id o5OMPB1o022859 Cc: dtn-users@maillists.intel-research.net, L.Wood@surrey.ac.uk, dail8859@yahoo.com Subject: Re: [dtn-users] dtn-users Digest, Vol 32, Issue 2 X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 22:25:13 -0000 >> Our first try was a 1.5GB file which sent correctly. We have tried it >> multiple times and it has been sent correctly each time. I'd have more confidence once multiple different files of that size were sent correctly, which would be more of an indication that you're not facing an unescaped-bit-pattern type issue. (What's 396MB into the 4.4GB file?) Lloyd Wood L.Wood@surrey.ac.uk http://sat-net.com/L.Wood Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o5OM5SOE021916 for ; Thu, 24 Jun 2010 15:05:28 -0700 Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 97E483E4082; Thu, 24 Jun 2010 23:05:27 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id HNfdCJOshw8u; Thu, 24 Jun 2010 23:05:27 +0100 (IST) Received: from [10.0.0.68] (static-213.50.93.115.addr.tdcsong.se [213.50.93.115]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 0E3FA3E406E; Thu, 24 Jun 2010 23:05:24 +0100 (IST) Message-ID: <4C23D6A4.9050405@cs.tcd.ie> Date: Thu, 24 Jun 2010 23:05:24 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Justin Dailey References: <263438.77139.qm@web56602.mail.re3.yahoo.com> In-Reply-To: <263438.77139.qm@web56602.mail.re3.yahoo.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dtn-users@maillists.intel-research.net Subject: Re: [dtn-users] dtn-users Digest, Vol 32, Issue 2 X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 22:05:28 -0000 Hi Justin, On 06/24/2010 04:32 PM, Justin Dailey wrote: > Stephen, > You got us curious about your question. So we decided to use our testbed > and see what all DTN2 could handle. We tried it over the TCP convergence > layer and over 4 hops. There were no errors or delays introduced into > the network and we used md5sums to verify integrity. > > Our first try was a 1.5GB file which sent correctly. We have tried it > multiple times and it has been sent correctly each time. So I guess for now you hold the world record. I'll buy a beer for whoever gets the biggest bundle delivered next time they catch up with me at some meeting type thing:-) [Competition rules: I'll assume you're honest, so no cheating unless you can be amusingly sneaky, ala obfuscated code competition.] > We then decided to try a 3GB file. However, we've made 2 attempts at > sending the 3GB file. There was an md5sum mismatch each time. The data > was the correct number of bytes but an unforeseen error was introduced > somewhere along the hops each time. :( > > After that we decided to go ahead and try a 4.4GB file. We've made two > attempts so far and each time only 396MB of the file is sent. Interesting. Any debugging you could do on those would be valuable. Cheers, S. > > Justin Dailey > Shawnee State University - Cyber Center > Research Assistant > > > > _______________________________________________ > dtn-users mailing list > dtn-users@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-users Received: from n20.bullet.mail.mud.yahoo.com (n20.bullet.mail.mud.yahoo.com [68.142.206.147]) by maillists.intel-research.net (8.13.8/8.13.8) with SMTP id o5OFWvAx020775 for ; Thu, 24 Jun 2010 08:32:58 -0700 Received: from [68.142.200.227] by n20.bullet.mail.mud.yahoo.com with NNFMP; 24 Jun 2010 15:32:55 -0000 Received: from [66.196.97.135] by t8.bullet.mud.yahoo.com with NNFMP; 24 Jun 2010 15:32:56 -0000 Received: from [127.0.0.1] by omp108.mail.re3.yahoo.com with NNFMP; 24 Jun 2010 15:32:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 375595.50841.bm@omp108.mail.re3.yahoo.com Received: (qmail 77943 invoked by uid 60001); 24 Jun 2010 15:32:56 -0000 Message-ID: <263438.77139.qm@web56602.mail.re3.yahoo.com> X-YMail-OSG: 0Zbyl3wVM1nGGDt1k9ltl7GJEf0ZN6KiMtgtCF3sEK5Xr3t l7hnjKbSLo8fSRUXq8aC9g5RSRfdUDrFbpos82XvMMNLU4D8Bs0BtuawMI2Q 6aLQDcFdvufmFB4kfGQ2K7DzjcwgbSf1g4nsvjRiloHi3butO6BW.vc1a7F5 5ePT6Mr06Nh4k4qWp9JJVOiABWMmsUPgxwHbMpjEhgNXdot_rnJjV_ryfJMy mDCPob4kaQg82vhOHXsUM3Ginj0wVdsg2Sns8uqpY7ryhI69.GMS11O0aNp9 .COwEDb6PzVWeBhZSZJUrr.eP5aspMhneJeo2mx6CuigcSoSxCp6Zycw- Received: from [98.108.71.33] by web56602.mail.re3.yahoo.com via HTTP; Thu, 24 Jun 2010 08:32:56 PDT X-Mailer: YahooMailRC/397.8 YahooMailWebService/0.8.104.274457 References: Date: Thu, 24 Jun 2010 08:32:56 -0700 (PDT) From: Justin Dailey To: dtn-users@maillists.intel-research.net In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1390987873-1277393576=:77139" Subject: Re: [dtn-users] dtn-users Digest, Vol 32, Issue 2 X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 15:33:07 -0000 --0-1390987873-1277393576=:77139 Content-Type: text/plain; charset=us-ascii Stephen, You got us curious about your question. So we decided to use our testbed and see what all DTN2 could handle. We tried it over the TCP convergence layer and over 4 hops. There were no errors or delays introduced into the network and we used md5sums to verify integrity. Our first try was a 1.5GB file which sent correctly. We have tried it multiple times and it has been sent correctly each time. We then decided to try a 3GB file. However, we've made 2 attempts at sending the 3GB file. There was an md5sum mismatch each time. The data was the correct number of bytes but an unforeseen error was introduced somewhere along the hops each time. :( After that we decided to go ahead and try a 4.4GB file. We've made two attempts so far and each time only 396MB of the file is sent. Justin Dailey Shawnee State University - Cyber Center Research Assistant --0-1390987873-1277393576=:77139 Content-Type: text/html; charset=us-ascii
Stephen,
You got us curious about your question. So we decided to use our testbed and see what all DTN2 could handle. We tried it over the TCP convergence layer and over 4 hops. There were no errors or delays introduced into the network and we used md5sums to verify integrity.
 
Our first try was a 1.5GB file which sent correctly. We have tried it multiple times and it has been sent correctly each time.

We then decided to try a 3GB file. However, we've made 2 attempts at sending the 3GB file. There was an md5sum mismatch each time. The data was the correct number of bytes but an unforeseen error was introduced somewhere along the hops each time. :(

After that we decided to go ahead and try a 4.4GB file. We've made two attempts so far and each time only 396MB of the file is sent.

Justin Dailey
Shawnee State University - Cyber Center
Research Assistant

--0-1390987873-1277393576=:77139-- Received: from c.painless.aaisp.net.uk (c.painless.aaisp.net.uk [81.187.30.53]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o5OAYvjS003204 for ; Thu, 24 Jun 2010 03:34:57 -0700 Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247]) by c.painless.aaisp.net.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1ORjlo-0007e0-Ts; Thu, 24 Jun 2010 11:34:57 +0100 Message-ID: <4C233573.9020407@folly.org.uk> Date: Thu, 24 Jun 2010 11:37:39 +0100 From: Elwyn Davies User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Stephen Farrell References: <4C21DFBF.3010209@cs.tcd.ie> <7BBFF2424089F04FB7D62F800895E2B629A79A8DDF@NDJSSCC07.ndc.nasa.gov> <4C228F95.1020403@cs.tcd.ie> <181E0818-8AAB-406A-A7E8-6FB0EE37977F@surrey.ac.uk> <4C23270B.4060905@cs.tcd.ie> In-Reply-To: <4C23270B.4060905@cs.tcd.ie> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dtn-users@maillists.intel-research.net, L.Wood@surrey.ac.uk Subject: Re: [dtn-users] biggest bundle ever... X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: elwynd@folly.org.uk List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 10:34:58 -0000 Stephen Farrell wrote: > > >> (I suspect a 4GB limit might apply to block sizes; dtn2 has a limit of 256 blocks/bundle. The Saratoga specification goes beyond 4GB with 128-bit descriptors, but no-one has yet implemented full support for that afaik.) >> > > I think DTN2 was designed not to have a 32bit limit, but > personally I'd be surprised if that just worked. Maybe > Mike Demmer tested it locally in the past, but I don't > recall hearing about that. > > S. > > Regrettably it appears that DTN2 is limited to 4GB bundles. The variable that holds the bundle length internally is an unsigned 32 bit item (and the code will reject larger bundles). Thinking about it, it would be significantly more complex to handle bundles larger then 4GB in a 32 bit operating system, but it wouldn't be a big deal to handle on a 64 bit OS machine. Next week/year's problem. So Dr Frankenstein: "You'll just have use fragmentation!".. but that won't really help because DTN2 can't cope with fragments that are less than 4GB if the whole bundle is more than 4GB because it can't store the primary block original length even if the fragment is under 4GB. Regards, Elwyn Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o5O9aQNe000366 for ; Thu, 24 Jun 2010 02:36:27 -0700 Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5053C3E4077; Thu, 24 Jun 2010 10:36:27 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Gh5nW8odaBVz; Thu, 24 Jun 2010 10:36:26 +0100 (IST) Received: from [10.154.3.132] (unknown [192.165.126.74]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6F4B63E4072; Thu, 24 Jun 2010 10:36:11 +0100 (IST) Message-ID: <4C23270B.4060905@cs.tcd.ie> Date: Thu, 24 Jun 2010 10:36:11 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: L.Wood@surrey.ac.uk References: <4C21DFBF.3010209@cs.tcd.ie> <7BBFF2424089F04FB7D62F800895E2B629A79A8DDF@NDJSSCC07.ndc.nasa.gov> <4C228F95.1020403@cs.tcd.ie> <181E0818-8AAB-406A-A7E8-6FB0EE37977F@surrey.ac.uk> In-Reply-To: <181E0818-8AAB-406A-A7E8-6FB0EE37977F@surrey.ac.uk> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dtn-users@maillists.intel-research.net Subject: Re: [dtn-users] biggest bundle ever... X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 09:36:27 -0000 On 06/24/2010 08:34 AM, L.Wood@surrey.ac.uk wrote: > how did you verify that the bundle was received reliably? manual inspection:-) The payload was a compressed tarball which exploded fine, but I didn't do anything to check the resulting data so in theory it could have been corrupted. (This wasn't a planned test btw, I just noticed the size and wondered if anyone else had done bigger.) Whether you'd want to apply a single checksum for an entire 4+GB bundle is an interesting question. (I could see an argument for a manifest-of-hashes type ciphersuite instead, say if you wanted to deliver fragments of the entire bundle to the application with e2e integrity before having seen it all.) > (I suspect a 4GB limit might apply to block sizes; dtn2 has a limit of 256 blocks/bundle. The Saratoga specification goes beyond 4GB with 128-bit descriptors, but no-one has yet implemented full support for that afaik.) I think DTN2 was designed not to have a 32bit limit, but personally I'd be surprised if that just worked. Maybe Mike Demmer tested it locally in the past, but I don't recall hearing about that. S. > > On 23 Jun 2010, at 23:49, Stephen Farrell wrote: > >> >> >> On 06/23/2010 04:44 PM, Ivancic, William D. (GRC-RHN0) wrote: >>> Not dumb at all. >> >> Respectfully disagree:-) >> >>> >>> What was the convergence layer? >> >> TCP, but over a crappy NATed setup where the TCP >> sessions drop weirdly (but surprisingly without >> seeing bundle fragmentation, not sure why) >> >>> >>> Was this DTN multi-hop or even IP multi-hop? >> >> Single-hop last night. Will probably try 3 hops >> soonish. (With one hop being a VPN-over-3G link >> and another two being 802,11). >> >>> >>> What was the network topology (delays, errors, back-to-back GigE?) >> >> Crappy NATed stuff over cat5. >> >> S. >> >> >>> >>> >>> >>> >>>> From: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users- >>>> bounces@maillists.intel-research.net] On Behalf Of Stephen Farrell >>>> Sent: Wednesday, June 23, 2010 6:20 AM >>>> To: dtn-users@maillists.intel-research.net >>>> Subject: [dtn-users] biggest bundle ever... >>>> >>>> Definitely a dumb question, but I just ran a test >>>> last night where I sent a 394MB bundle and I >>>> wondered what's the largest bundle that's been >>>> sent with DTN2 or other implementations? >>>> >>>> I also wonder if anyone's looked to see what'd >>>> happen if we tried >4GB with DTN2. >>>> >>>> S. >>>> >>>> _______________________________________________ >>>> dtn-users mailing list >>>> dtn-users@maillists.intel-research.net >>>> http://maillists.intel-research.net/mailman/listinfo/dtn-users >>> >> _______________________________________________ >> dtn-users mailing list >> dtn-users@maillists.intel-research.net >> http://maillists.intel-research.net/mailman/listinfo/dtn-users > > Lloyd Wood > L.Wood@surrey.ac.uk > http://sat-net.com/L.Wood > > > > Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o5O7YeSG027037 for ; Thu, 24 Jun 2010 00:34:41 -0700 X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-6.tower-82.messagelabs.com!1277364881!18098065!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.39] Received: (qmail 12828 invoked from network); 24 Jun 2010 07:34:41 -0000 Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-6.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 24 Jun 2010 07:34:41 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.69]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Thu, 24 Jun 2010 08:34:41 +0100 From: To: Date: Thu, 24 Jun 2010 08:34:39 +0100 Thread-Topic: [dtn-users] biggest bundle ever... Thread-Index: AcsTb7SVhYQMTgJsRWiIpkKuYW2FSA== Message-ID: <181E0818-8AAB-406A-A7E8-6FB0EE37977F@surrey.ac.uk> References: <4C21DFBF.3010209@cs.tcd.ie> <7BBFF2424089F04FB7D62F800895E2B629A79A8DDF@NDJSSCC07.ndc.nasa.gov> <4C228F95.1020403@cs.tcd.ie> In-Reply-To: <4C228F95.1020403@cs.tcd.ie> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id o5O7YeSG027037 Cc: dtn-users@maillists.intel-research.net, L.Wood@surrey.ac.uk Subject: Re: [dtn-users] biggest bundle ever... X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 07:34:42 -0000 how did you verify that the bundle was received reliably? (I suspect a 4GB limit might apply to block sizes; dtn2 has a limit of 256 blocks/bundle. The Saratoga specification goes beyond 4GB with 128-bit descriptors, but no-one has yet implemented full support for that afaik.) On 23 Jun 2010, at 23:49, Stephen Farrell wrote: > > > On 06/23/2010 04:44 PM, Ivancic, William D. (GRC-RHN0) wrote: >> Not dumb at all. > > Respectfully disagree:-) > >> >> What was the convergence layer? > > TCP, but over a crappy NATed setup where the TCP > sessions drop weirdly (but surprisingly without > seeing bundle fragmentation, not sure why) > >> >> Was this DTN multi-hop or even IP multi-hop? > > Single-hop last night. Will probably try 3 hops > soonish. (With one hop being a VPN-over-3G link > and another two being 802,11). > >> >> What was the network topology (delays, errors, back-to-back GigE?) > > Crappy NATed stuff over cat5. > > S. > > >> >> >> >> >>> From: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users- >>> bounces@maillists.intel-research.net] On Behalf Of Stephen Farrell >>> Sent: Wednesday, June 23, 2010 6:20 AM >>> To: dtn-users@maillists.intel-research.net >>> Subject: [dtn-users] biggest bundle ever... >>> >>> Definitely a dumb question, but I just ran a test >>> last night where I sent a 394MB bundle and I >>> wondered what's the largest bundle that's been >>> sent with DTN2 or other implementations? >>> >>> I also wonder if anyone's looked to see what'd >>> happen if we tried >4GB with DTN2. >>> >>> S. >>> >>> _______________________________________________ >>> dtn-users mailing list >>> dtn-users@maillists.intel-research.net >>> http://maillists.intel-research.net/mailman/listinfo/dtn-users >> > _______________________________________________ > dtn-users mailing list > dtn-users@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-users Lloyd Wood L.Wood@surrey.ac.uk http://sat-net.com/L.Wood Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o5NMo0vS001886 for ; Wed, 23 Jun 2010 15:50:01 -0700 Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id DD95E3E4085; Wed, 23 Jun 2010 23:50:00 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id AYLL7psGNm7h; Wed, 23 Jun 2010 23:50:00 +0100 (IST) Received: from [10.0.0.68] (static-213.50.93.115.addr.tdcsong.se [213.50.93.115]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id C15983E4084; Wed, 23 Jun 2010 23:49:58 +0100 (IST) Message-ID: <4C228F95.1020403@cs.tcd.ie> Date: Wed, 23 Jun 2010 23:49:57 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: "Ivancic, William D. (GRC-RHN0)" References: <4C21DFBF.3010209@cs.tcd.ie> <7BBFF2424089F04FB7D62F800895E2B629A79A8DDF@NDJSSCC07.ndc.nasa.gov> In-Reply-To: <7BBFF2424089F04FB7D62F800895E2B629A79A8DDF@NDJSSCC07.ndc.nasa.gov> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dtn-users@maillists.intel-research.net" Subject: Re: [dtn-users] biggest bundle ever... X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 22:50:01 -0000 On 06/23/2010 04:44 PM, Ivancic, William D. (GRC-RHN0) wrote: > Not dumb at all. Respectfully disagree:-) > > What was the convergence layer? TCP, but over a crappy NATed setup where the TCP sessions drop weirdly (but surprisingly without seeing bundle fragmentation, not sure why) > > Was this DTN multi-hop or even IP multi-hop? Single-hop last night. Will probably try 3 hops soonish. (With one hop being a VPN-over-3G link and another two being 802,11). > > What was the network topology (delays, errors, back-to-back GigE?) Crappy NATed stuff over cat5. S. > > > > >> From: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users- >> bounces@maillists.intel-research.net] On Behalf Of Stephen Farrell >> Sent: Wednesday, June 23, 2010 6:20 AM >> To: dtn-users@maillists.intel-research.net >> Subject: [dtn-users] biggest bundle ever... >> >> Definitely a dumb question, but I just ran a test >> last night where I sent a 394MB bundle and I >> wondered what's the largest bundle that's been >> sent with DTN2 or other implementations? >> >> I also wonder if anyone's looked to see what'd >> happen if we tried >4GB with DTN2. >> >> S. >> >> _______________________________________________ >> dtn-users mailing list >> dtn-users@maillists.intel-research.net >> http://maillists.intel-research.net/mailman/listinfo/dtn-users > Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o5NFitI9013939 for ; Wed, 23 Jun 2010 08:44:55 -0700 Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 6D0A6260202; Wed, 23 Jun 2010 10:44:55 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o5NFit4l030246; Wed, 23 Jun 2010 10:44:55 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub04.ndc.nasa.gov ([10.202.202.163]) with mapi; Wed, 23 Jun 2010 10:44:55 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Stephen Farrell , "dtn-users@maillists.intel-research.net" Date: Wed, 23 Jun 2010 10:44:53 -0500 Thread-Topic: [dtn-users] biggest bundle ever... Thread-Index: AcsSvmagph7co7T4TxCDlR6k3wx+2QALCGhw Message-ID: <7BBFF2424089F04FB7D62F800895E2B629A79A8DE1@NDJSSCC07.ndc.nasa.gov> References: <4C21DFBF.3010209@cs.tcd.ie> In-Reply-To: <4C21DFBF.3010209@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-23_02:2010-02-06, 2010-06-23, 2010-06-23 signatures=0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id o5NFitI9013939 Subject: Re: [dtn-users] biggest bundle ever... X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 15:44:55 -0000 Not dumb at all. What was the convergence layer? Was this DTN multi-hop or even IP multi-hop? What was the network topology (delays, errors, back-to-back GigE?) -- Will >From: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users- >bounces@maillists.intel-research.net] On Behalf Of Stephen Farrell >Sent: Wednesday, June 23, 2010 6:20 AM >To: dtn-users@maillists.intel-research.net >Subject: [dtn-users] biggest bundle ever... > >Definitely a dumb question, but I just ran a test >last night where I sent a 394MB bundle and I >wondered what's the largest bundle that's been >sent with DTN2 or other implementations? > >I also wonder if anyone's looked to see what'd >happen if we tried >4GB with DTN2. > >S. > >_______________________________________________ >dtn-users mailing list >dtn-users@maillists.intel-research.net >http://maillists.intel-research.net/mailman/listinfo/dtn-users Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o5NFiaad013915 for ; Wed, 23 Jun 2010 08:44:36 -0700 Received: from ndjsppt04.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 0E11CA848E; Wed, 23 Jun 2010 10:44:36 -0500 (CDT) Received: from ndjshub05.ndc.nasa.gov (ndjshub05.ndc.nasa.gov [198.117.4.164]) by ndjsppt04.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o5NFiQCi005921; Wed, 23 Jun 2010 10:44:35 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub05.ndc.nasa.gov ([198.117.4.164]) with mapi; Wed, 23 Jun 2010 10:44:27 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Stephen Farrell , "dtn-users@maillists.intel-research.net" Date: Wed, 23 Jun 2010 10:44:24 -0500 Thread-Topic: [dtn-users] biggest bundle ever... Thread-Index: AcsSvmagph7co7T4TxCDlR6k3wx+2QALCGhw Message-ID: <7BBFF2424089F04FB7D62F800895E2B629A79A8DDF@NDJSSCC07.ndc.nasa.gov> References: <4C21DFBF.3010209@cs.tcd.ie> In-Reply-To: <4C21DFBF.3010209@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-23_02:2010-02-06, 2010-06-23, 2010-06-23 signatures=0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id o5NFiaad013915 Subject: Re: [dtn-users] biggest bundle ever... X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 15:44:36 -0000 Not dumb at all. What was the convergence layer? Was this DTN multi-hop or even IP multi-hop? What was the network topology (delays, errors, back-to-back GigE?) >From: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users- >bounces@maillists.intel-research.net] On Behalf Of Stephen Farrell >Sent: Wednesday, June 23, 2010 6:20 AM >To: dtn-users@maillists.intel-research.net >Subject: [dtn-users] biggest bundle ever... > >Definitely a dumb question, but I just ran a test >last night where I sent a 394MB bundle and I >wondered what's the largest bundle that's been >sent with DTN2 or other implementations? > >I also wonder if anyone's looked to see what'd >happen if we tried >4GB with DTN2. > >S. > >_______________________________________________ >dtn-users mailing list >dtn-users@maillists.intel-research.net >http://maillists.intel-research.net/mailman/listinfo/dtn-users Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o5NAJjxv030324 for ; Wed, 23 Jun 2010 03:19:46 -0700 Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 59F933E4075 for ; Wed, 23 Jun 2010 11:19:45 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id tadTHF2MumGl for ; Wed, 23 Jun 2010 11:19:45 +0100 (IST) Received: from [10.87.48.6] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 280733E406B for ; Wed, 23 Jun 2010 11:19:44 +0100 (IST) Message-ID: <4C21DFBF.3010209@cs.tcd.ie> Date: Wed, 23 Jun 2010 11:19:43 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: dtn-users@maillists.intel-research.net X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dtn-users] biggest bundle ever... X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 10:19:46 -0000 Definitely a dumb question, but I just ran a test last night where I sent a 394MB bundle and I wondered what's the largest bundle that's been sent with DTN2 or other implementations? I also wonder if anyone's looked to see what'd happen if we tried >4GB with DTN2. S. Received: from bay0-omc2-s14.bay0.hotmail.com (bay0-omc2-s14.bay0.hotmail.com [65.54.190.89]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o5FHAPE1006302 for ; Tue, 15 Jun 2010 10:10:25 -0700 Received: from BAY127-W23 ([65.54.190.125]) by bay0-omc2-s14.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Jun 2010 10:10:26 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_8d054f34-6aa9-4ed2-89a2-e608ba3ac737_" X-Originating-IP: [138.37.2.37] From: yh dt To: Date: Tue, 15 Jun 2010 17:10:25 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 15 Jun 2010 17:10:26.0388 (UTC) FILETIME=[A5FCE140:01CB0CAD] Subject: [dtn-users] configuring bluetooth interface X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 17:10:26 -0000 --_8d054f34-6aa9-4ed2-89a2-e608ba3ac737_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello=2C =20 I have 2 PCs ethernet connected with the dtn2 daemon installed on each of o= ne. I have been playing with dtnsend and dtnrecv=2C and I am able to transfer f= iles of size of about 20MB. =20 Now=2C I have installed also dtn2 on two nokia tablets N810 connected via b= luetooth. I have been able to transfer only small files....72kb. =20 I understand fragmentation is turned on by default. =20 Can anyone please give me a hint on how to configure dtn.conf to be able to= transfer files larger than 72kb? Is it that I have to configure properly the bluetooth interface or enable f= ragmentation somehow? =20 im lost on this help please=2C Diaz =20 =20 _________________________________________________________________ Hotmail: Trusted email with powerful SPAM protection. https://signup.live.com/signup.aspx?id=3D60969= --_8d054f34-6aa9-4ed2-89a2-e608ba3ac737_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello=2C
 =3B
I have 2 PCs ethernet connected with the dtn2 daemon installed on each of o= ne.
I have been playing with dtnsend and dtnrecv=2C and I am able to transfer f= iles of size of about 20MB.
 =3B
Now=2C I have installed also dtn2 on two nokia tablets N810 connected via b= luetooth. I have been able to transfer only small files....72kb.
 =3B
I understand fragmentation is turned on by default.
 =3B
Can anyone please give me a hint on how to configure dtn.conf to be able to= transfer files larger than 72kb?
Is it that I have to configure properly the bluetooth interface or enable f= ragmentation somehow?
 =3B
im lost on this
help please=2C
Diaz
 =3B



Hotmail: Trusted email with pow= erful SPAM protection. Sign up now. = --_8d054f34-6aa9-4ed2-89a2-e608ba3ac737_--