Project

General

Profile

Actions

Feature #3167

closed

TcpTransport: persistency=permanent

Added by Junxiao Shi over 8 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Faces
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
6.00 h

Description

Support persistency=permanent in TcpTransport.

In a TcpTransport created with persistency=permanent,

  • Whenever the TCP connection is severed, it should change FaceState to DOWN, and attempt to reestablish connection with the same remote endpoint.
  • If connection cannot be reestablished, it should stay as DOWN, and retry connection periodically.

Files

20161108201251.tgz (176 KB) 20161108201251.tgz integ 3152,24 Junxiao Shi, 11/08/2016 01:51 PM

Related issues 1 (0 open1 closed)

Blocked by NFD - Feature #3166: TcpTransportClosedYukai Tu

Actions
Actions #1

Updated by Junxiao Shi over 8 years ago

Actions #2

Updated by Junxiao Shi over 7 years ago

  • Assignee set to Weiwei Liu
  • Estimated time changed from 3.00 h to 6.00 h

Weiwei agreed to work on this issue.

Actions #3

Updated by Weiwei Liu over 7 years ago

  • Status changed from New to In Progress
Actions #4

Updated by Weiwei Liu over 7 years ago

@Davide, I'm confused about the code design of this problem. To implement the permanent persistency, the TcpTransport needs to have its own logic for to process error, but for now processErrorCode() is in the base class StreamTransport. Originally I was thinking that maybe we could move the processErrorCode() to subclass, but Junxiao suggests not to do that, since it will affect other subclasses. Then I'm currently trying to add an empty virtual method handleError() in 'StreamTransport', and implement it in TcpTransport and call it somewhere in processErrorCode() to make it go into TcpTransport-specific error process logic, but this still won't work because the other code (which is undesired for TcpTransport with permanent persistency) in processErrorCode() will still be executed.. Could you suggest me what would be the most appropriate way to override processErrorCode()?

Actions #6

Updated by Davide Pesavento over 7 years ago

I have a question on the requirements of this feature: what should happen if the local endpoint changes? For example if the local IP of the default interface changes, or if the routing table changes so that a different interface (and thus a different IP) is used to reach the default gateway.

Actions #7

Updated by Junxiao Shi over 7 years ago

Answer to note-6:

TcpTransport currently has no means to detect a local IP change.
In this feature, it would not attempt to reconnect.
However, if there's a socket error, the socket will be re-created, and the source endpoint is likely the new local IP and a new random port number.

#3521 will bring a better solution to this situation.

Actions #8

Updated by Davide Pesavento over 7 years ago

Junxiao Shi wrote:

TcpTransport currently has no means to detect a local IP change.

Yes sure, I wasn't implying that it should.

In this feature, it would not attempt to reconnect.

Why not? I would guess that if the local IP changes, the connection will eventually break and the socket will then return an error.

However, if there's a socket error, the socket will be re-created, and the source endpoint is likely the new local IP and a new random port number.

Indeed. And is it ok to change the local URI of the transport in that case?

Actions #9

Updated by Davide Pesavento over 7 years ago

What should happen to the send queue when the transport goes UP and DOWN? In particular:

  • Should we clear the queue when the transport goes down?
  • If not, should we try sending from the queue (if not empty) when the transport comes back up?
Actions #10

Updated by Junxiao Shi over 7 years ago

Answer to note-9:

There's no requirement on what happens to the queue when a permanent face goes DOWN.
For simplicity, clearing the queue (and drop any outgoing packets if someone is still sending during DOWN) is a good idea.

Actions #11

Updated by Weiwei Liu over 7 years ago

In the case that we get a "boost::asio::error::eof" error, do we still attempt to reestablish the connection?

Actions #13

Updated by Junxiao Shi over 7 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 70

NFD devguide "TCP transport" section shall be updated as part of this issue.

Actions #14

Updated by Junxiao Shi over 7 years ago

  • Status changed from Feedback to Closed
  • Target version changed from v0.5 to v0.6
  • % Done changed from 70 to 100

nfd-docs:commit:61b5e01d8056f92e4ea4e68fdbd87bca5ead6cbb

Actions #15

Updated by Davide Pesavento almost 7 years ago

The patch to TcpTransport landed quite some time ago, however TcpFactory was not changed to accept FACE_PERSISTENCY_PERMANENT, therefore this feature cannot be used in practice.

Actions #16

Updated by Davide Pesavento almost 7 years ago

Davide Pesavento wrote:

The patch to TcpTransport landed quite some time ago, however TcpFactory was not changed to accept FACE_PERSISTENCY_PERMANENT, therefore this feature cannot be used in practice.

https://gerrit.named-data.net/3835

Actions

Also available in: Atom PDF