Re: [dtn-users] A problem with dtntunnel
"ssireskin@gmail.com" <ssireskin@gmail.com> Tue, 18 December 2012 07:40 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 D54C321F8880 for <dtn-users@ietfa.amsl.com>; Mon, 17 Dec 2012 23:40:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.043
X-Spam-Level:
X-Spam-Status: No, score=-3.043 tagged_above=-999 required=5 tests=[AWL=-0.045, 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 RpF-LhNrkZur for <dtn-users@ietfa.amsl.com>; Mon, 17 Dec 2012 23:40:21 -0800 (PST)
Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id 30CFD21F8856 for <dtn-users@irtf.org>; Mon, 17 Dec 2012 23:40:21 -0800 (PST)
Received: by mail-vc0-f174.google.com with SMTP id d16so417260vcd.19 for <dtn-users@irtf.org>; Mon, 17 Dec 2012 23:40:20 -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=Tp2OANx6aQxqy67Y4JijljgEGXCfRbwGy1BJKfQcRhY=; b=UpapuRla1eQ7wWXSfdGYQBui5Q+ywxGenM8HW0EFQa40efc38AavrUZmXMHrMDvqEX VciKy94ynRAjxH4mqVExPnHoIpnQsnceIVw8YQvGvgpkD2/FMWB0etsAREQRSZ5wAt+i FBloz29mVk4KaFaxvoxe7Vil/MlW1M0mg5yTrUooSxyEn+QVk71tlgKDt2VnVUVciL15 bxSqmdagzNWVpMj6sDrKD7BT0QA/e534u/HDp54Z/kupYJ36LdCytDoD4Fbhf2usGK4f IGFLd6eusLWnfoydzV4m0f8a9sPTNqqiydGOA1xxD/Jl0Z7jccw1EwvKNlwjjfSY8ziu Oe1g==
MIME-Version: 1.0
Received: by 10.220.149.69 with SMTP id s5mr1585491vcv.23.1355816420577; Mon, 17 Dec 2012 23:40:20 -0800 (PST)
Received: by 10.58.219.65 with HTTP; Mon, 17 Dec 2012 23:40:20 -0800 (PST)
In-Reply-To: <04E3D99A62496240BCD6A576813E6E31E0BDF5C999@NDMSSCC05.ndc.nasa.gov>
References: <CA+X1Codj6FoKWPDj+giFK-6oa-pbCZ8LF2x9cZyW1OzBJNTAYw@mail.gmail.com> <CAJR8z99v9XUDZyCzy6uhg7zYHrig8B4E6SPW+i-FfSU2LJT6zA@mail.gmail.com> <04E3D99A62496240BCD6A576813E6E31E0BDF5C59C@NDMSSCC05.ndc.nasa.gov> <CAJR8z99AhqDfdNgF_Xfym+_8yh+3hVhyvurMFGFGcvaRwabP9g@mail.gmail.com> <CAJR8z98k0XLRQoWNKcPYSv7Mr2AV2y3e=3yBnHFkpEXTupYtdg@mail.gmail.com> <04E3D99A62496240BCD6A576813E6E31E0BDF5C999@NDMSSCC05.ndc.nasa.gov>
Date: Tue, 18 Dec 2012 10:40:20 +0300
Message-ID: <CAJR8z9-1w=7zXiHTGoPP8kLhYabEz3CKqhaycReXc4Ze1Rh0pQ@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/alternative; boundary="f46d042fd8982112f104d11b9cde"
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: Tue, 18 Dec 2012 07:40:23 -0000
Hi David, Now it works like a charm, thank you very much! 2012/12/17 Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT] < david.a.zoller@nasa.gov> > Sergey,**** > > That was my bad. In the patch below I moved the *“delete b_recv;”* line > above the *“if (recv_hdr->eof_) {”* block as a short cut to delete it > before the possible exit. Move it back down below the if block and you > should be okay.**** > > Sorry, that was one of those possible loose ends I mentioned J,**** > > DZ**** > > ** ** > > David Zoller**** > > COLSA Corporation**** > > HOSC / C107 **** > > (Office: (256) 544-1820 > *EMail: david.a.zoller@nasa.gov**** > > ** ** > > *From:* ssireskin@gmail.com [mailto:ssireskin@gmail.com] > *Sent:* Monday, December 17, 2012 8:05 AM > *To:* Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT] > *Cc:* David Zoller; dtn-users@irtf.org > > *Subject:* Re: [dtn-users] A problem with dtntunnel**** > > ** ** > > David, > > The problem is probably not with the reordering. Can it be, that "if > (recv_hdr->eof_)" is not the right condition to close a connection? Or > maybe it is not a sufficient condition? Which connection is recv_hdr about? > Can it be a local TCP connection on the receiving side (dtntunnel <-> nc)? > If it is, then IMO this condition becomes true when the receiving > application doesn't send any data to the sending application, please see > line 406 of the original code.**** > > 2012/12/17 ssireskin@gmail.com <ssireskin@gmail.com>**** > > 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**** > > ** ** > > > > > -- > Best regards, > Sergey Sireskin > > **** > -- Best regards, Sergey Sireskin
- [dtn-users] A problem with dtntunnel ssireskin@gmail.com
- Re: [dtn-users] A problem with dtntunnel Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
- Re: [dtn-users] A problem with dtntunnel ssireskin@gmail.com
- Re: [dtn-users] A problem with dtntunnel Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
- [dtn-users] Fwd: A problem with dtntunnel ssireskin@gmail.com
- [dtn-users] A problem with dtntunnel ssireskin@gmail.com
- Re: [dtn-users] A problem with dtntunnel Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
- Re: [dtn-users] A problem with dtntunnel ssireskin@gmail.com
- Re: [dtn-users] A problem with dtntunnel David Zoller
- Re: [dtn-users] A problem with dtntunnel Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
- Re: [dtn-users] A problem with dtntunnel ssireskin@gmail.com
- Re: [dtn-users] A problem with dtntunnel Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
- Re: [dtn-users] A problem with dtntunnel ssireskin@gmail.com
- Re: [dtn-users] A problem with dtntunnel ssireskin@gmail.com
- Re: [dtn-users] A problem with dtntunnel ssireskin@gmail.com
- Re: [dtn-users] A problem with dtntunnel ssireskin@gmail.com
- Re: [dtn-users] A problem with dtntunnel Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
- Re: [dtn-users] A problem with dtntunnel ssireskin@gmail.com
- Re: [dtn-users] A problem with dtntunnel ssireskin@gmail.com
- Re: [dtn-users] A problem with dtntunnel ssireskin@gmail.com
- Re: [dtn-users] A problem with dtntunnel Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
- Re: [dtn-users] A problem with dtntunnel ssireskin@gmail.com
- Re: [dtn-users] A problem with dtntunnel ssireskin@gmail.com
- Re: [dtn-users] A problem with dtntunnel Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
- Re: [dtn-users] A problem with dtntunnel Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
- Re: [dtn-users] A problem with dtntunnel ssireskin@gmail.com
- Re: [dtn-users] A problem with dtntunnel Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
- Re: [dtn-users] A problem with dtntunnel ssireskin@gmail.com
- Re: [dtn-users] A problem with dtntunnel Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
- Re: [dtn-users] A problem with dtntunnel ssireskin@gmail.com