False Connection close

[Anonymous]

Hi, I observed that NetworkComms sometimes reports that a connection is closed, but it isn’t as for example TCPView shows. Afterwards the application is no more able to reconnect.
The problem seems to be when there is an exception during deserialization.
You can reproduce this behaviour like this in ProtobufSerializer.cs:

        static int counter = 0;
        /// <inheritdoc />
        protected override object DeserialiseDataObjectInt(Stream inputStream, Type resultType, Dictionary<string, string> options)
        {
            counter++;
            if (counter == 500) // Handle the first messages 99 proper, the provoke an exception
            {
                System.Diagnostics.Debug.WriteLine("Provoke exception");
                throw new InvalidOperationException("Test network connection");
            }

            return ProtoBuf.Serializer.NonGeneric.Deserialize(resultType, inputStream);
        }

When the exception is thrown, NetworkComms reports that the connection is closed, but this is not the case.
The original reason why I got an exception here, was due to an initialization problem of protobuf, but the exception was hidden by NetworkComms and therefore hard to find.

[Anonymous]

Heya Ekki,

Not quite sure I know what you mean, can you elaborate what you mean by TCPView reporting that the connection is still open. AFAIK the correct behaviour should be to close the connection is an error during deserialisation occurs. If you could elaborate that would be greatly appreciated.

Kind regards,
Marc

[Anonymous]

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.

[Anonymous]

Yes, I think that is the case.

Does the connection stay open indefinitely, as seen by TCPView, when the deserialisation error occurs? There can sometimes be a delay when a connection is closed and that close is finalised by the operating system.

[Author]

Posts