Develop Reference

TCP connection forcibly closed by ShipModul's Miniplex-3Wi

We have been developing a .NET Framework 4.6.1 app with C# that has as one of its tasks to send NMEA 0183 sentences to a multiplexer via local area network connection (Wi-Fi or Ethernet). The app can be configured to connect using TCP or UDP. The communication between the app and the multiplexer works over UDP for hours without any problems, but TCP connection has this problem that a ShipModul's multiplexer that I have been using in my own testing scenarios forcibly closes the connection after about 10 or 15 minutes. Also, other users of the app have confirmed that other multiplexers might not work at all when the app is configured to use TCP, but that UDP connection still works without a problem. The communication is one-way from the .NET Framework app to multiplexer.
What might be the reason for the premature closing of the TCP connection? Is there some requirement and mechanism to actively keep the connection alive, and not just that it is assumed to be alive when IP packets arrive from the PC? And if the connection needs to be actively maintained, then how you do it with .NET TcpClient object?
Simplyt put, the code is something like (executed only when using TCP):
// connection initilization
tcpClient = new TcpClient(new IPEndPoint(unicastAddress.Address, port));
tcpClient.Connect(ipAddress, port);
networkStream = tcpClient.GetStream();
// ..prepare the NMEA sentence data..
networkStream.Write(asciiEncodedNmeaData, 0, asciiEncodedNmeaData.Length);
The corresponding UDP protocol version of the code (executed only when using UDP):
// connection initialization
udpClient = new UdpClient(new IPEndPoint(unicastAddress.Address, port));
udpClient.Connect(ipAddress, port);
// ..prepare the NMEA sentence data..
udpClient.Send(asciiEncodedNmeaData, asciiEncodedNmeaData.Length);
Also, when the app is closed/paused, the Close() method is called on either of the above client object depending on which protocol is used (and everything restarts as above when the app is unpaused):
tcpClient.Close();
networkStream.Close();
or:
udpClient.Close();
Then, after about 15 minutes there appears this exception:
System.IO.IOException: 'Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host.'

It's a standard situation. TCP connection is stateful, i.e. consumes finite resources like memory. That's why network equipment usually discards inactive connections. In your case connection is considered idle "after about 10 or 15 minutes".
To avoid this, you can send "keep alive packets". Just write any data (the less the better) to networkStream by timer, e.g. every 5 minutes.

Asynchronous Server Socket error: An existing connection was forcibly closed by the remote host

I am using msdn Asynchronous Server Socket Example. link
On this server i am getting data in string format from a device.
The problem is after some time of getting data successfully i get below error and application hang:-
socket exception was unhandled:
An existing connection was forcibly closed by the remote host.
c# debug shows error in this part of code.
listener.BeginAccept(
new AsyncCallback(AcceptCallback),
listener);
how to resolve the error.

As i understand, server established connection with the client and start sending the data. If this is right than server created socket, bind it and start tcp transmission correctly. Afterwords server destroys the socket due to exception, and connection is lost.
All I can think of is that this problem is related to the message size. You can check buffer-size, and the time-out intervals.

To help resolve error:
Verify you are not having network issues.
Confirm the remote host is not closing the connection (most common cause of this error).
Confirm you are providing a sufficient backlog to handle all your users:
listener.Listen(100);
where 100 = the maximum length of the pending connections in queue.
You can catch the remote host disconnect in your ReadCallback:
SocketError errorCode;
int bytesRead = handler.EndReceive(ar, out errorCode);
if (errorCode != SocketError.Success)
{
bytesRead = 0;
//handle remote host disconnect...
}
If these all check out, then you may have issues else where in your code. You may need to post more details about how you create, start, stop your listener and how the remote host is handling the connection.

What are the possible reasons of SocketError.ConnectionReset in TCP Socket

I have a TCP socket based client server system.
Everything works fine but when network is disconnected form client end and reconnect it again i get automatically SocketError.ConnectionReset send form client and regarding this command the socket is closed in the server side. this is also fine.
but when i look in to the client side it shows the socket is still connected with server. (regarding socket is still connected with server [It does not happen every time], sometime it shows disconnected and some times shows connected)
Does it make sense that "server get a SocketError.ConnectionReset from
client end but client is still connected"?
So i want to know what is the possible reasons of SocketError.ConnectionReset and how to handle such type of problem i have mentioned?
Again i say, Everything is working fine in normal environment (e.g if i exit the client it is disconnected the socket same for the server)
Thanks in advance.
EDIT:
Here is the code in the client side. actually it's a timer that tick every 3 second through programs lifetime and check if Socket is connected or not if its disconnected then it tries to reconnect again through a new socket instance
private void timerSocket_Tick(object sender, EventArgs e)
{
try
{
if (sck == null || !sck.Connected)
{
ConnectToServer();
}
}
catch (Exception ex)
{
RPLog.WriteDebugLog("Exception occcured at: "+ System.Reflection.MethodBase.GetCurrentMethod().ToString()+"Message: "+ex.Message);
}
}
In normal situation (without network disconnect/reconnect) if TCP server get a
SocketError.ConnectionReset form any client, in the client side i see
clients socket is disconnected and it tries to reconnect it again
through the code shown. but when situation happen explained earlier,
server gets a SocketError.ConnectionReset but client shows it still
connected. though the TCP server shows the reset command is send form the exact client
side.

There are several causes but the most common is that you have written to a connection that has already been closed but he other end. In other words, an application protocol error. When it happens you have no choice but to close the socket, it is dead. However you can fix the underlying cause.

When discussing a TCP/IP issue like this, you must mention the network details between the client and the server.
When one side says the connection is reset, it simply means that on the wire a RST packet appears. But to know who sends the RST packet and why, you must utilize network packet captures (by using Wireshark and any other similar tools),
https://en.wikipedia.org/wiki/Transmission_Control_Protocol
You won't easily find out the cause at .NET Framework level.

The problem with using Socket.Connected as you are is that it only gives you the connected state as at the last Send or Receive operation. i.e. It will not tell you that the socket has disconnected unless you first try to send some data to it or receive data from it.
From MSDN description of the Socket.Connected property:
Gets a value that indicates whether a Socket is connected to a remote host as of the last Send or Receive operation.
So in your example, if the socket was functioning correctly when you last sent or received any data from it, the timerSocket_Tick() method would never call ConnectToServer(), even if the socket was now not connected.

how to handle such type of problem i have mentioned?
Close the socket and initiate a new connection.

Closing System.Net.Sockets.TcpClient kills the connection for other TCPClients at the same IP Address

Just to be clear, all of the TCPClients I'm referring to here are not instances of my own class, they are all instances of System.Net.Sockets.TcpClient from Mono's implementation of .NET 4.0.
I have a server that is listening for client connections, as servers do. Whenever it gets a new client it creates a new TCPClient to handle the connection on a new thread. I'm keeping track of all the connections and threads with a dictionary. If the client disconnects, it sends a disconnect message to the server, the TCPClient is closed, the dictionary entry is removed and the thread dies a natural death. No fuss, no muss. The server can handle multiple clients with no problem.
However, I'm simulating what happens if the client gets disconnected, doesn't have a chance to send a disconnect message, then reconnects. I'm detecting whether a client has reconnected with a username system (it'll be more secure when I'm done testing). If I just make a new TCPClient and leave the old one running, the system works just fine, but then I have a bunch of useless threads lying around taking up space and doing nothing. Slackers.
So I try to close the TCPClient associated with the old connection. When I do that, the new TCPClient also dies and the client program throws this error:
E/mono (12944): Unhandled Exception: System.IO.IOException: Write failure ---> System.Net.Sockets.SocketException: The socket has been shut down
And the server throws this error:
Unable to write data to the transport connection: An established connection was aborted by the software in your host machine.
Cannot read from a closed TextReader.
So closing the old TCPClient with a remote endpoint of say: 192.168.1.10:50001
Also breaks the new TCPClient with a remote endpoint of say:192.168.1.10:50002
So the two TCPClient objects have the same remote endpoint IP address, but different remote endpoint ports. But closing the one seems to stop the other from working. I want to be able to close the old TCPClient to do my cleanup, without closing the new TCPClient.
I suspect this is something to do with how TCPClient works with sockets at a low level, but not having any real understanding of that, I'm not in a position to fix it.

I had a similar issue on my socket server. I used a simple List instead of a dictionary to hold all of my current connections. In a continuous while loop that listens for new streams, I have a try / catch and in the catch block it kills the client if it has disconnected.
Something like this on the sever.cs:
public static void CloseClient(SocketClient whichClient)
{
ClientList.Remove(whichClient);
whichClient.Client.Close();
// dispose of the client object
whichClient.Dispose();
whichClient = null;
}
and then a simple dispose method on the client:
public void Dispose()
{
System.GC.SuppressFinalize(this);
}
EDIT: this paste is the OPs resolution which he or she found on their own with help from my code.
So to clarify, the situation is that I have two TCPClient objects TCPClientA and TCPClientB with different remote endpoints ports, but the same IP:
TCPClientA.Client.RemoteEndPoint.ToString();
returns: 192.168.1.10:50001
TCPClientB.Client.RemoteEndPoint.ToString();
returns: 192.168.1.10:50002
TCPClientA needs to be cleaned up because it's no longer useful, so I call
TCPClientA.Close();
But this closes the socket for the client at the other end of TCPClientB, for some reason. However, writing
TCPClientA.Client.Close();
TCPClientA.Close();
Successfully closes TCPClientA without interfering with TCPClientB. So I've fixed the problem, but I don't understand why it works that way.

Looks like you have found a solution but just so you are aware there are many similar pitfalls when writing client/server applications in .net. There is an open source network library (which is fully supported in mono) where these problems have already been solved, networkComms.net. A basic sample is here.
Disclaimer: This is a commercial product and I am the founder.

This is clearly an error in your code. Merely closing one inbound connection cannot possibly close another one. Clearly something else is happening elsewhere in your code.

How to recover gracefully from a C# udp socket exception

Context: I'm porting a linux perl app to C#, the server listens on a udp port and maintains multiple concurrent dialogs with remote clients via a single udp socket. During testing, I send out high volumes of packets to the udp server, randomly restarting the clients to observe the server registering the new connections. The problem is this: when I kill a udp client, there may still be data on the server destined for that client. When the server tries to send this data, it gets an icmp "no service available" message back and consequently an exception occurs on the socket.
I cannot reuse this socket, when I try to associate a C# async handler with the socket, it complains about the exception, so I have to close and reopen the udp socket on the server port. Is this the only way around this problem?, surely there's some way of "fixing" the udp socket, as technically, UDP sockets shouldn't be aware of the status of a remote socket?
Any help or pointers would be much appreciated. Thanks.

I think you are right in saying: 'the server should not be aware'. If you send an UDP packet to some IP/port which may or may not be open, there is no way of knowing for the server if it reached it's destination.
The only way for the server to know is to have the client send an ACK back. (Also both the client and server must have resend mechanisms in place in cases of lost packages).
So clearly something else is going on in your code (or with the .Net udp implementation)
EDIT:
After Nikolai's remark I checked the docs. And indeed there is a distinction in .Net to about being 'connected' or 'connectionless' when using UDP.
If you use code like this:
UdpClient udpClient = new UdpClient(11000); //sourceport
try{
udpClient.Connect("www.contoso.com", 11000); //'connect' to destmachine and port
// Sends a message to the host to which you have connected.
Byte[] sendBytes = Encoding.ASCII.GetBytes("Is anybody there?");
udpClient.Send(sendBytes, sendBytes.Length);
then apparently you are 'connected'
However if you use code like this:
UdpClient udpClientB = new UdpClient();
udpClientB.Send(sendBytes, sendBytes.Length, "AlternateHostMachineName", 11000);
then you can send to whomever you choose without 'connecting'.
I'm not sure what your code looks like, but it might be worthwhile to check if you are using the correct set of commands which doesn't assume a 'connection'