Hello again.
The logs tell me that the tcp connection has been closed by the dtn
application. What about the RAM of the Machines? The dtnrecv application
loads the whole bundle into the memory and AFTER that it puts the
payload into the file or print it out. Was node 2 out of memory during
the receive call?
Kind regards,
Johannes
Am 20.06.2012 14:15, schrieb Sergey Sireskin:
> Hi Johannes.
>
> Both nodes are HVM Xen virtual machines. Xen host runs CentOS 5.5, linux kernel 2.6.18-194.3.1.el5xen
> on an IBM System x 3550 server with Intel Xeon E5530 CPU. Nodes run RHEL 6 based OS, linux kernel
> 2.6.32-131.0.15.el6_x86_64.
>
> IBR-DTN version 0.8.0 was compiled on the nodes with GCC 4.4.5.
>
> Here is ldd output for dtnd:
> ldd /usr/local/sbin/dtnd
> linux-vdso.so.1 => (0x00007fff8a7ff000)
> libibrdtn-0.8.so.1 => /usr/local/lib/libibrdtn-0.8.so.1
> (0x00007f90ed16c000)
> libibrcommon-0.8.so.1 => /usr/local/lib/libibrcommon-0.8.so.1
> (0x00007f90ecef8000)
> libssl.so.10 => /usr/lib64/libssl.so.10 (0x0000003e8de00000)
> libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x0000003e8b600000)
> libdl.so.2 => /lib64/libdl.so.2 (0x0000003f42200000)
> libz.so.1 => /lib64/libz.so.1 (0x0000003e83e00000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003e83600000)
> librt.so.1 => /lib64/librt.so.1 (0x0000003e84200000)
> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003e86a00000)
> libm.so.6 => /lib64/libm.so.6 (0x0000003e83a00000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003e86600000)
> libc.so.6 => /lib64/libc.so.6 (0x0000003e83200000)
> libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x0000003e8be00000)
> libkrb5.so.3 => /lib64/libkrb5.so.3 (0x0000003e89a00000)
> libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000003e87a00000)
> libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x0000003e8aa00000)
> libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003e85200000)
> /lib64/ld-linux-x86-64.so.2 (0x0000003e82a00000)
> libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x0000003e8a200000)
> libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x0000003e8a600000)
> libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003e84600000)
>
> Best regards,
> Sergey Sireskin
>
> Wed, 20 Jun 2012 13:25:08 +0200 от Johannes Morgenroth <morgenro(a)ibr.cs.tu-bs.de>:
>> Hi Sergey.
>>
>> I've tested a 1.3G filetransfer with two daemons and can not reproduce
>> your issue with my nodes. Please tell me more details about your system
>> (software / hardware, if special) you used and send me the logfiles of
>> the daemons. For a better analysis of what happens here, I need logfiles
>> with enabled debugging. Parameter "-d 99" on startup.
>>
>> Kind regards,
>> Johannes
>>
>>
>> Am 19.06.2012 16:07, schrieb Sergey Sireskin:
>>> I am unable to send a large (~ 1.3GB file) between two directly connected nodes.
>>> Free disk space on both nodes is about 6GB.
>>> On the receiving node dtn://node-2.domain I start dtnrecv --name file --file /tmp/1.iso.
>>> On the sending node dtn://node-1.domain I start dtnsend dtn://node-2.domain/file ./1.iso.
>>> The file is successfully transferred to the receiving node and is stored as a bundle, then it
>>> is being transferred to dtnrecv, as I suppose. After some time I get the following error:
>>>
>>> dtnrecv --name file --file /tmp/1.iso
>>> Wait for incoming bundle...
>>> Aborted.
--
Johannes Morgenroth Institut fuer Betriebssysteme und Rechnerverbund
Tel.: +49-531-391-3249 Muehlenpfordtstrasse 23
Fax.: +49-531-391-5936 TU Braunschweig D-38106 Braunschweig
