Hi Marc,
it’s good to know that to close the connection should be the correct behaviour if an error occurs during deserialisation.
Does that mean that for NetworkComms any exception during deserialisation is reason enough to assume that the connection is closed?
Isn’t there any further attempt to ensure that the connection is really closed?
Then this could be the reason, because NetworkComms says the connection is closed, but TCPView reports that the connection is still there, at least on OS level.