System.Net.Sockets.SocketException: Connection reset by peer

[sprehn-ero]

Hi,

we followed examples on how to close the connection of SMB2Client property and called:
fileStore.Disconnect()

However we noticed that approx. 10 min later a SocketException is thrown on an async background thread, telling us that the client closing the underlying socket.

System.AggregateException: A Task's exception(s) were not observed either by Waiting on the Task or accessing its Exception property. As a result, the unobserved exception was rethrown by the finalizer thread.

System.Net.Sockets.SocketException: Connection reset by peer

It seems as if the socket remains open and times out after some time.

Thus, we tried the following:

if (client.IsConnected && fileStore != null && fileStore.Disconnect() != NTStatus.STATUS_SUCCESS) _logger.LogWarning("Failed to disconnect from fileStore on SMB server {hostname}", `SmbHostname);

if` (client.IsConnected && client.Logoff() != NTStatus.STATUS_SUCCESS) _logger.LogWarning("Failed to log off from SMB server {hostname}", `SmbHostname);`

if` (client.IsConnected) client.Disconnect();

The if statement in the third line still evaluates to true - even after a fileStoreDisconnect().
client.Disconnect() gets called, however this also causes a SocketException to be thrown on a background thread.

It seems as if, either the documentation has to be updated on how to propery close the connection, or the underlying socket must be closed cleanly.

[TalAloni]

The examples for client connections clearly show you have to call both
client.Logoff();
and
client.Disconnect();

[sprehn-ero]

And I suppose filestore.Disconnect() won't hurt

Could it be that there is some background thread which listens for communication with the server, which simply stops with an unhandled socket exception?

The client code to retrieve directory listings and files itself works fine.
We just see many unhandled exceptions in sentry.io, which we use to monitor our system.

[sprehn-ero]

just reading source code and c# docs..
https://learn.microsoft.com/en-US/dotnet/api/system.net.sockets.socket.beginreceive?view=net-7.0
States that Socket.Close() or Socket.EndReceive() are proper ways to close BeginReceive lin 163 in SMB2Client.cs

https://learn.microsoft.com/en-us/dotnet/api/system.net.sockets.socket.disconnect?view=net-7.0
states that disconnect can also be used. but they recommend calling a shutdown first.

If you are using a connection-oriented protocol, you can use this method to close the socket. This method ends the connection and sets the Connected property to false. However, if reuseSocket is true, you can reuse the socket.

To ensure that all data is sent and received before the socket is closed, you should call Shutdown before calling the Disconnect method.

If you need to call Disconnect without first calling Shutdown, you can set the DontLingerSocket option to false and specify a nonzero time-out interval to ensure that data queued for outgoing transmission is sent. Disconnect then blocks until the data is sent or until the specified time-out expires. If you set DontLinger to false and specify a zero time-out interval, Close releases the connection and automatically discards outgoing queued data.

https://learn.microsoft.com/en-us/dotnet/api/system.net.sockets.socket.close?view=net-7.0

The Close method closes the remote host connection and releases all managed and unmanaged resources associated with the Socket. Upon closing, the Connected property is set to false.

For connection-oriented protocols, it is recommended that you call Shutdown before calling Close. This ensures that all data is sent and received on the connected socket before it is closed.

So maybe a Shutdown should be called, or the async callback deregisterd. I am not sure.

I only have 6months of experience in C#, so appologies if anything here is real basic stuff.

[sprehn-ero]

A small update: Today, we created a fork of this project and tested locally socket.Shutdown, socket.Close, even calling EndReceive

Unfortunately, none of our tests made any difference. The socket exception is still being thrown on the background thread.

[TalAloni]

It's not clear what the action item is here nor a clear indication that there is an issue with current implementation. Closing the issue.