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@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.