I am writing a C# client to connect with an embedded system (server). Initially i am able to connect to the server and send data. Then i reboot the server (with the client not being shutdown) and on the server coming to ready state, I first try to disconnect (shutdown) client and reconnect the same. Now during client shutdown i am getting the socket exception 10053 - An established connection was aborted by the software in your host machine.
Can you help me in understanding what could be the issue?
Note: if i try to reconnect without trying to shutdown (after the server reboot) then the connect is working fine and i am able to transmit data.
The socket probably uses a TCP protocol. TCP is designed to keep a constant line of communication between the two. This means that in order to close the connection, both client and server say to each other that the connection will be ended. But as you only get the error after a restart I believe that when you shutdown the server, the server did not get a chance to properly shut down the connection too. So, when trying to restart the connection on the client, it already 'lost' its connection without knowing it as it didn't hear it from the server. Thus, it cannot officially close the socket as the server does not communicate to the socket anymore.
You have two options: accept the exception and use a try catch, which might be less neat. The other option is to try and force the server to officially close the socket before or during shutdown, so that the client is informed. Then, the client will retry starting a connection every few minutes.
I can't go into specifics as I haven't worked much with the code yet, but I hope this seems clear to you.
Related
I've created a server-client communicate program in .NET (c# or vb.net) using TCPListener - Socket on port 8080. In simple words, the program work like a chat software, client connect to server, and both wait for message from each other and then process it.
To retrieve packet from client, i using are using a "While" method like this :
While true
Dim Buffer(4096) As Byte
s.Receive(Buffer)
Dim strDataReceived As String = System.Text.Encoding.ASCII.GetString(Buffer)
ProcessData(strDataReceived) 'Process data received...........
End while
When testing both server.exe-client.exe in local, the software work fine for several hours without any problem.
But when i start to run the server.exe in my real server, the connection between server-client usually become lost each other when client connected after a few dozen minutes. The symptom is client send packet to server but server does not receive the packet from client when server is still standing in 'sck.receive(Buffer)' command. I have tested many times but i still have no lucky to keep the connection run over 1 hour.
I have investigated about this problem but it still very strange :
The server did not installed any firewall software.
The client did not using any proxy and antivirus, firewall software
I using a bandwidth logging software on server to make sure the internet in my server is stable.
I make a 'ping -t' from my client computer to the server and keep looking on it to sure there are no connection lost between client and server . The ping command indicate that the ping time is usually range from 5ms to 50ms and no connection time out occur.
Even I try to unplug the network cable in the client computer for a few seconds, and then replug again to simulation the disconnect event. I've awesome that my connection between server-client is still maintain and it's not the problem that cause my symptom.
I was thinking to write a code for auto reconnect if received timeout. But it could make my software usually delay when reconnecting if the above symptom still there. I really want to know what wrong with my code and which is the solution for me to fix the above symptom?
Likely the server is behind some sort of firewall (Cisco ASA, etc.) which has idle connection timeouts. When you "punch" through a firewall / NAT device, a "session" is created within the firewall kernel. There is an associated resource that has to be reclaimed, so firewalls do not usually allow unlimited connection timeout, but firewalls do support things like dead connection detection.
Adding a keepalive packet / activity every 5 minutes, or disconnecting / reconnecting is the only way around that. Few network admins are going to change their configs to accomodate this. It is pretty simple to implement a "ping" or "keepalive" command in custom TCP application protocols. Just send the string and consume it, you don't even have to respond to the packet to accomplish resetting the idle timer within the firewall, though that would probably be best practice.
When I say keepalive, I don't mean the TCP keepalive socket option. That is a zero-length packet, and is detectable by a good firewall, like Cisco. Cisco admins can setup rules to quietly deny your keepalive packet, so the solution is to implement it above the TCP layer, in the Application layer, by sending a small string of data like "KEEPALIVE\r\n".
I am developing one tcp server application using tcp listener in Windows service using c#.
After starting my service it works fine and accepts new clients. After some time when ever the new client is trying to connect to server it gives the following exception:
connection failed, is the server running? No connection could be made
because the target machine actively refused it.
At that time the service is in running state only.
How can I verify the tcp server is in listening state or not?
netstat -ab
This command will give you information about all active connections with name of the programs.
Another option is TcpView from Mark Russinovich
If your server is still running and hasn't close the listening socket, it is still in listening state. However if the platform is Windows and your server's backlog queue is full, a windows will refuse further connections. That means that your server is slow accepting new connections.
Not sure if you mean programatically or not, but for the latter, you can try telnet: telnet host port
telnet yahoo.com 80
telnet localhost 3306
etc.
If you want to check if the server is listening, and the server is Windows, you can simply use (e.g. 8888 is your listening port)
netstat -ano|findstr "8888"
Then you'll see the PID of your server instance.
In addition, if you want to check why the TCP connection attempt is fail, you could use Wireshark to capture all the TCP packets between server & client, then the reason will be quite clear.
E.g. if the server has reached the limitation of open socket number, you'll see a SIN from client to server, and how the server is responding.
I have a chat site (http://www.pitput.com) that connects user via socket connections.
I have in the client side a flash object that opens a connection to a port in my server.
In the server i have a service that is listening to that port in an async matter.
All is working fine except when i talk to someone after an unknown period of time(about couple of minutes) the server is closing my connection and i get an error in the server :
" A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond".
I dont know how exactly the tcp socket works. does it checking for "live" connection every couple of seconds? how does it decide when to close the connection? Im pretty sure that the close operation is not coming from the client side.
Thanks.
Sounds like the server is handling the connection but not responding. This is the point where I usually pull out WireShark to find out what's going on.
TCP/IP does have an option for checking for live connections; it's called "keepalive." Keepalives are hardly ever used. They're not enabled by default. They can be enabled on a system-wide basis by tweaking the Registry, but IIRC the lowest timeout is 1 hour. They can also be enabled on a single socket (with a timeout in minutes), but you would know if your application does that.
If you are using a web service and your client is connecting to an HTTP/HTTPS port, then it may be getting closed by the HTTP server (which usually close their connections after a couple minutes of idle time). It is also possible that an intermediate router may be closing it on your behalf after an amount of idle time (this is not default behavior, but corporate routers are sometimes configured with such "helpful" settings).
If you are using a Win32 service, then it does in fact sound like the client side is dropping the connection or losing their network (e.g., moving outside the range of a wireless router). In the latter case, it's possible that the client remains oblivious to the fact that the connection has been closed (this situation is called "half-open"); the server sees the close but the client thinks the connection is still there.
Is this an ASP web service hosted with some company? If so, the server generally recycles apps every 10 to 20 minutes. You cannot have a web service running indefinitely, unless it's your own server (I believe).
The setting: I want to write a point-to-point Connection class that, when used, does not differentiate between server and client. The first host which calls connect() shall become the server waiting for the client to connect and the second shall become the client that connects to the server.
In order to do that the connect() method first needs to check for a listening server. a) The first time this happens no server is found and the party calling connect() starts listening on localhost and the configured port for an incoming connection. b) The second party calling connect() also checks the remote host on the given port, recognizes the server and connects to it.
This is not too hard using TCP since TcpClient.Connect() throws an exception when no connection could be established. Therefore I know when I'm the first. Since I use reliable LAN only, I wanted to use UDP, however.
My problem: How can I determine whether an UDP server socket is waiting for incoming data.
Ideally I would like to use the asynchronous network API directly afterwards. Instead of dealing with listening threads all by myself.
With UDP, the communication model is akin to a message in a bottle: you know you sent it, but there's no way to know if anyone ever received it.
You need to manually establish a communication protocol to determine if the remote party is listening (e.g. have them send a "Yes, I 'm here" response). This would require both endpoints to accept UDP datagrams.
As Jon and Andrew said you can't see if a listener is open, but you can implement a ping/pong protocol. Send a ping first time you connect if no pong back then set this up like a server.
If you got pong back then that's your server.
I don't think you can check for a listening server, short of sending a packet and waiting to see if you get a reply.
I was wondering how to handle a situation where you successfully connected two processes through named pipe (one server and one client), and suddenly (for some reason) the server process ends.
What happens to the pipe? Does it close?
What happens to information being sent by the client to the server? Does it get lost?
How can the client know if the server is down?
All The Best,
Gil
If you are using System.IO.Pipes and NamedPipeServerStream for example, you would get IOException when a pipe is broken or disconnected.
When you are using NamedPipeClientStream for reading in information from server, I believe the client would wait till a connection is established on the NamedPipeClientStream.Connect() call alternative you could use NamedPipeClientStream.Connect(Int32) option to timeout a connection after a predetermined period. Apart from that the StreamReader.ReadLine() is also capable of throwing IOException when something does not go well.
The NamedPipeClientStream.IsConnected would be a simple way to determine if the client is connected successfully to the server or if it is disconnected, closed, or broken.