NFD

@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()?

https://gerrit.named-data.net/#/c/3152/

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.

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.

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?

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?

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.

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

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.

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