Re: [dtn-users] A problem with dtntunnel

"ssireskin@gmail.com" <ssireskin@gmail.com> Mon, 17 December 2012 13:43 UTC

Return-Path: <ssireskin@gmail.com>
X-Original-To: dtn-users@ietfa.amsl.com
Delivered-To: dtn-users@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F3D21F86D9 for <dtn-users@ietfa.amsl.com>; Mon, 17 Dec 2012 05:43:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.049
X-Spam-Level:
X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60x9o8kaBqJy for <dtn-users@ietfa.amsl.com>; Mon, 17 Dec 2012 05:43:23 -0800 (PST)
Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id CE74021F84CD for <dtn-users@irtf.org>; Mon, 17 Dec 2012 05:43:22 -0800 (PST)
Received: by mail-vb0-f54.google.com with SMTP id l1so7091494vba.13 for <dtn-users@irtf.org>; Mon, 17 Dec 2012 05:43:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gMX3Ud3T+1UQ1ecZ5z2hLHJ151aBQA3JXcUzNeYssjo=; b=xb4U852BPKmfRzwFiOQ325Kr9IPMY9mp9IO+JZCS8J4WIunJ1EGmJ0u6Tx/3utIYMU qC/Ycr5sZZaLc8zaNrFaFZTo5L5AtPbpc6ffBDuy/lW6QmIiFLTsqw3WkPTHK1QGzWNE +W6RLmkS5lHGrJpZlHLDDy8gyGdFgIiJJbRWe9XwJJAaQv8zzXOuVuQWDZWkEZyuHhEl msPiFTcXH4LM33qrQD/szvwFFEWigzdDjgvDc50Lq8aCloWr83HHSoDhPiucAOOAIRCh vndPdpQxxMNFNB1U4xV6vWMkq3p7fZ3wbfm39bYqMM0Rc9aP0Tx8ekkHPyzFJ63fxTY1 U8YA==
MIME-Version: 1.0
Received: by 10.58.198.135 with SMTP id jc7mr23440487vec.51.1355751802344; Mon, 17 Dec 2012 05:43:22 -0800 (PST)
Received: by 10.58.219.65 with HTTP; Mon, 17 Dec 2012 05:43:22 -0800 (PST)
In-Reply-To: <04E3D99A62496240BCD6A576813E6E31E0BDF5C59C@NDMSSCC05.ndc.nasa.gov>
References: <CA+X1Codj6FoKWPDj+giFK-6oa-pbCZ8LF2x9cZyW1OzBJNTAYw@mail.gmail.com> <CAJR8z99v9XUDZyCzy6uhg7zYHrig8B4E6SPW+i-FfSU2LJT6zA@mail.gmail.com> <04E3D99A62496240BCD6A576813E6E31E0BDF5C59C@NDMSSCC05.ndc.nasa.gov>
Date: Mon, 17 Dec 2012 16:43:22 +0300
Message-ID: <CAJR8z99AhqDfdNgF_Xfym+_8yh+3hVhyvurMFGFGcvaRwabP9g@mail.gmail.com>
From: "ssireskin@gmail.com" <ssireskin@gmail.com>
To: "Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]" <david.a.zoller@nasa.gov>
Content-Type: multipart/mixed; boundary="047d7b5d8cd795139a04d10c9019"
Cc: David Zoller <zollerd@gmail.com>, "dtn-users@irtf.org" <dtn-users@irtf.org>
Subject: Re: [dtn-users] A problem with dtntunnel
X-BeenThere: dtn-users@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." <dtn-users.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dtn-users>, <mailto:dtn-users-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/dtn-users>
List-Post: <mailto:dtn-users@irtf.org>
List-Help: <mailto:dtn-users-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dtn-users>, <mailto:dtn-users-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Dec 2012 13:43:28 -0000

David,

I added this code and a log_debug inside the if-clause. According to the
log, this condition doesn't get true.
A have attached my logs and tcpdumps. Please, see dtntunnel_T.log - it's a
receiving dtntunnel log.
There are 4 bundles after a eof bundle. This doesn't happen with the
original dtntunnel.

-- 
Best regards,
Sergey Sireskin


2012/12/17 Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT] <
david.a.zoller@nasa.gov>

> Hi Sergey,****
>
> I don’t have your setup and this has not been tested but give this a try.
> In TCPTunnel::Connection::handle_bundle in the while(1) loop add the test
> to see if the next_seqno_ is a match:****
>
> ** **
>
>     while (1) {****
>
>         iter = reorder_table_.find(next_seqno_);****
>
>         if (iter == reorder_table_.end()) {****
>
>             break;****
>
>         }****
>
> ** **
>
>         // add this code:****
>
>         // if seqno does not match then still a bundle missing****
>
>         if (iter->first != next_seqno_) {****
>
>             break;****
>
>         }****
>
> ** **
>
>         bundle = iter->second;****
>
>         log_debug("delivering %zu byte bundle with seqno %d (from reorder
> table)",****
>
>                   bundle->payload_.len(), next_seqno_);****
>
>     ****
>
>         reorder_table_.erase(iter);****
>
>         next_seqno_++;****
>
>     ****
>
>         queue_.push_back(bundle);****
>
>     }   ****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> David Zoller****
>
> COLSA Corporation****
>
> HOSC / C107  ****
>
> (Office: (256) 544-1820
> *EMail: david.a.zoller@nasa.gov****
>
> ** **
>
> *From:* dtn-users-bounces@irtf.org [mailto:dtn-users-bounces@irtf.org] *On
> Behalf Of *ssireskin@gmail.com
> *Sent:* Monday, December 17, 2012 6:40 AM
> *To:* David Zoller
>
> *Cc:* dtn-users@irtf.org
> *Subject:* Re: [dtn-users] A problem with dtntunnel****
>
> ** **
>
> Hi David,
>
>
> Thanks for your patch, it works! :) Connection is cleanly terminated now.
>
> However, there still seems to be a problem. I run dtntunnel over a link
> with high latency and about 30% packet loss. The receiving nc sometimes
> gets FIN packet before it receives all the data. If I understand it right,
> on a lossy link bundles may come out of order. In this case the EOF bundle
> may come too early. I think that the reordering procedure in dtntunnel
> should be reviewed. Just for information, pure TCP performs better that DTN
> over this link.****
>
> 2012/12/14 David Zoller <zollerd@gmail.com>****
>
> Hi Sergey,****
>
> I can't stay away from a problem that is nagging at me so I made some time
> this morning. Going back to the original TCPTunnel.cc code, when a bundle
> is received that has the EOF indication, an empty bundle with the same EOF
> flag set needs to be returned to close the loop (the second FIN). There may
> still be some loose ends or clean up needed but try the code below at the
> end of the while loop.****
>
> ** **
>
> I did not do a packet capture but I saw that if the receiving nc is not
> running when you start the sender nc then the receiving dtntunnel logs an
> error on the failed connect and returns an EOF bundle which closes the
> sender nc. The EOF bundle could possibly be enhanced to include an error
> message.****
>
> ** **
>
> I agree that some applications could benefit from a "pretend to be a
> receiver" option with the default working as a bidirectional end-to-end TCP
> connection.****
>
> ** **
>
> Thanks for dragging me along kicking and screaming on this lesson in DTN
> and TCP tunneling. I've only been using dtntunnel as a one way UDP
> transmitter. I see a good fit for the TCP tunnel in an upcoming project and
> I'll try to make the pitch to use it. This is a pretty cool little app.***
> *
>
> Best regards,****
>
> DZ****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> 484             delete b_recv;****
>
> 485 ****
>
> 486             if (recv_hdr->eof_) {****
>
> 487                 log_info("bundle had eof bit set... closing
> connection");****
>
> 488 ****
>
> 489                 if ( !sock_eof ) {****
>
> 490                     sock_eof = true;****
>
> 491                     // send an empty bundle back since we did not
> initiate the close****
>
> 492                     dtn::APIBundle* b = new dtn::APIBundle();****
>
> 493                     hdr.eof_ = 1;****
>
> 494                     hdr.seqno_ = ntohl(send_seqno++);****
>
> 495                     memcpy(b->payload_.buf(sizeof(hdr)), &hdr,
> sizeof(hdr));****
>
> 496                     b->payload_.set_len(sizeof(hdr));****
>
> 497                     int err;****
>
> 498                     if ((err = tunnel->send_bundle(b, &dest_eid_)) !=
> DTN_SUCCESS) {****
>
> 499                         log_err("error sending final socket closed
> packet bundle: %s",****
>
> 500                                 dtn_strerror(err));****
>
> 501                         tcptun_->kill_connection(this);****
>
> 502                         exit(1);****
>
> 503                     }****
>
> 504                     delete b;****
>
> 505                 }****
>
> 506                 sock_.close();****
>
> 507                 goto done;****
>
> 508             }****
>
> 509         }****
>
> 510     }****
>
> 511 ****
>
> 512  done:****
>
> ** **
>
>
>
>
> --
> Best regards,
> Sergey Sireskin
>
> ****
>