Re: [dtn-users] A problem with dtntunnel

["Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]" <[e-mail]>]

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: [phone]
*EMail: [e-mail]<mailto:[e-mail]>

From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Monday, December 17, 2012 6:40 AM
To: David Zoller
Cc: [e-mail]
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 <[e-mail]<mailto:[e-mail]>>
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