Re: [dtn-users] A problem with dtntunnel

["[e-mail]" <[e-mail]>]

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 [e-mail] <[e-mail]>

> 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] <
> [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]****
>>
>> ** **
>>
>> *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]>****
>>
>> 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