Project

General

Profile

Actions
Copy link

Bug #4099

closed

StreamTransport should not go into FAILED state when remote host gracefully closes the connection

Added by Davide Pesavento over 7 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Davide Pesavento
Category:
Faces
Target version:
v0.6
Start date:
Due date:
% Done:

100%

Estimated time:

Description

Seeing

1496093845.757178 INFO: [Transport] [id=260,local=unix:///run/nfd.sock,remote=fd://26] setState UP -> FAILED
1496093845.757266 INFO: [Transport] [id=260,local=unix:///run/nfd.sock,remote=fd://26] setState FAILED -> CLOSED

in the logs every time a local application closes its socket is unexpected and confusing.

According to the following doxygen

enum class TransportState {
  ...
  CLOSING, ///< the transport is requested to be closed
  FAILED, ///< the transport is being closed due to a failure
  ...

FAILED is definitely wrong, because there is no failure, in fact the connection is being closed gracefully by the remote host or application (we get an EOF on the socket). The description of CLOSING is ambiguous (requested by who?), but is more appropriate than FAILED.

Another option is introducing an additional REMOTE_CLOSE state, but I believe this would be overkill.

Yet another option is using CLOSING for on-demand faces, and keep FAILED for persistent faces.

Actions
Copy link

Also available in: Atom PDF