jndn

If a Face is connected to a remote NFD using TcpTransport, an NFD restart will break the TCP socket. If the default constructor is used, the user does not have a reference to the transport to call transport.connect() and re-connect the TCP socket; repeated calls to face.processEvents() will fail without attempting to reconnect. Don't know if this is a bug or a feature request and haven't tested with other transport types. Possible solutions:

1) make transport.processEvents() attempt to reconnect the broken socket
2) allow users access to the transport from the face so that they can re-connect it
3) force users to pass in a transport instance and keep a reference to it alongside the face reference; write code to trap a face.processEvents() error and trigger a transport.connect (I don't like this option as much)