Develop Reference

C# Socket exception when Shutdown in called on the client

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.

How to Process Multiple Requests at the Same Time With a Server

Alright, so here's my thinking:
If two requests were made to one server at the same time, would one be denied, and if so, how could you keep something like that from happening?
I currently have a server set up for a chat application I'm making, and it basically starts a TCP/IP connection, waits for a client, reads the data sent from them, sends something back, disconnects, and repeats. That way, the server never stops running, and as many requests as you want could be made.
However, what if a client was starting up while another program was using the server. If one program was getting a file from the server while the other one was starting up, and the starting up one needed data from the server, but it was already busy, what would happen?
Would the startup wait until the server was available, or would it just go straight to an error (since no connection was available). If so, this could be really bad, since then the user wouldn't have all the data, like the list of his friends, or a few chats. How could you fix this?
My idea would be that you could have a while loop set up so that it keeps queuing the server until it gets a response. Is this the right way to go about this?

No, the client should assume that the server is always available. You'll see that the basic Socket.Listen(int32) method (which TcpListener acts as a wrapper for) takes one parameter, backlog:
Listen causes a connection-oriented Socket to listen for incoming connection attempts. The backlog parameter specifies the number of incoming connections that can be queued for acceptance. To determine the maximum number of connections you can specify, retrieve the MaxConnections value. Listen does not block.
Most server implementations start with something like the following:
socket.Listen(10); // You choose the number
while (true)
{
var client = socket.Accept();
// Spawn a thread (or Task if you prefer), and have that do all the work for the client
var thread = new Thread(() => DoStuff(client));
thread.Start();
}
With this implementation, there is always a thread listening for new connections. When a client connects, a new thread is created for it, so the processing for that client doesn't delay/prevent more connections from being accepted on the main thread.
Now, if a few new connections come in faster than the server can create new threads, then the new connections will be put in the backlog automatically (I think at the OS level) - the backlog parameter determines how many pending connections can be in the backlog at once.
What if the backlog fills up completely? At this point, you need a second server, and a load balancer to act as a middle-man, directing half the requests to the first server, and half the requests to the second server.

Logic here is simple.
Server starts listening and begins accept clients.
Client tries to connect to the server. You can simply do nothing if server isn't running or you can implement some reconnect logic notifying client about unsuccessful connection attempts.
Lets assume that server was running when client tried to connect. You are talking about multi client application. You shouldn't disconnect the client. You should add connected client to the list of connected clients.
Then, when some of the clients connects to the server and there are some other already connected clients and sends some message. You receive that message via client socket and then you broadcast the message to all other connected clients except one that is sending the data.

Tcp socket suddenly closing connection

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).

Determine if server is listening when using udp

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.

What is the preferred way to handle this TCP connection in C#?

I have a server application (singleton, simple .NET console application) that talks to a GlobalCache GC-100-12 for the purpose of routing IR commands. Various .NET WinForm clients on the local network connect to my server application and send ASCII commands to it. The server application queues these ASCII commands and then sends them to the GC-100-12 via a TCP connection.
My question is, what is the best way to handle this connection from the server's point of view? I can think of two ways:
Create and Open a new TcpClient for each individual request. Close the TcpClient when the request is done.
Create and Open one TcpClient when the server starts and use a keep-alive (if necessary) to keep the connection open for the lifetime of the server object.
I ask this question because I wonder about the overhead of creating a new TcpClient for each request. Is it an expensive operation? Is this a bad practice?
Currently I am doing #1, and printing the results of each transmission to the console. Occasionally some connections timeout and the command doesn't get routed, and I was wondering if that was because of the overhead of creating a new TcpConnection each time, or if it is due to something else.
I can see #2 being more complicated because if the connection does drop it has to be recreated, and that will require a bit more code to handle that circumstance.
I'm looking for any general advice on this. I don't have a lot of experience working with the TcpClient class.

We had a simillar case of opening a telnet session to an old PICK based system. We found that the cost of opening the TCP connection each time a request came in was fairly expensive, and we decided to implement a no-op routine to keep the connection open. It is more complex, but as long as your end point is not trying to serve many many clients then pinning a connection sounds like a viable solution.
You could also set it up to have a timeout, if you want to prevent keeping a connection open when there is no traffic. Five minutes of no activity then shut down the connection.