this is my first post here so please be gentle =)
I'm writing an asynchronuos server/client application for the management of a DB for my office, i tested it locally on my computer and it worked fine. When I uploaded the server tool on another machine I found something that is driving me crazy: the server/client handle only the first query, when I send another query both server and client crash.
After going through lines in debug mode I found the problem: after the beginconnect() (during the second query) the socket is connected but when the debugger reaches the beginsend() line the socket is disconnected (this happens only on client side, the socket on server side seems connected).
I can't figure how it can happen, the socket is re-instantiated every time I send a new query and of course is shutted down and disposed after the query process (send/receive) is completed. My idea is that the disposal of the socket doesn't happen immediately but after a while (but why always between the new beginconnect() and beginsend()?). Do you have any clue on this? Or I should reserve a room in a mental hospital?
* NEW PART (EDITED) *
well..here again! This time the socket on client side remains open for the entire session (socket closure occurs only on client tool closure) but i receive another kind of error: "System.Net.Sockets.SocketException (0x80004005): An existing connection was forcibly closed by the remote host at System.Net.Sockets.Socket.EndReceive(IAsyncResult asyncResult)"
After some googling I discovered that this kind of error is generally triggered by the server on the other side of the connection so I tryed to "mine" server code lines to figure where this connection closure command is. I found that the problem may be in the following piece of code:
private static void SendCallback(IAsyncResult ar)
{
Console.WriteLine("send callback");
try
{
// Retrieve the socket from the state object.
Socket handler = (Socket)ar.AsyncState;
// Complete sending the data to the remote device.
int bytesSent = handler.EndSend(ar);
Console.WriteLine("\nQuery answer sent to client");
handler.Shutdown(SocketShutdown.Both);
//handler.Disconnect(true);
//handler.Dispose();
state.content = new List<byte[]>();
}
catch (Exception e)
{
Console.WriteLine(e.ToString());
Console.ReadKey();
}
}
deleting the handler.shutdown line the client is no more able to detect the end of transmission (not a real problem, is the last part of the sent packet so it is possible to use that as trigger..at least I think). Any suggestion? I read something about the keepalive but I can't understand how to set it and if it is really necessary in this situation. Thanks in advance for all your effort.
I would recommend not to open and close sockets like you do.Keep a socket open if possible, because it needs to get freed by your program and the OS.
Related
I'd like to wait for a slow response from a client with TcpClient but get a timeout after about 20s no matter how I configure it. This is my attempt:
using (var client = new TcpClient { ReceiveTimeout = 9999999, SendTimeout = 9999999 })
{
await client.ConnectAsync(ip, port);
using (var stream = client.GetStream())
{
// Some quick read/writes happen here via the stream with stream.Write() and stream.Read(), successfully.
// Now the remote host is calculating something long and will reply if finished. This throws the below exception however instead of waiting for >20s.
var bytesRead = await stream.ReadAsync(new byte[8], 0, 8);
}
}
The exception is an IOException:
Unable to read data from the transport connection: 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.
...which contains a SocketException inside:
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
SocketErrorCode is TimedOut.
The 20s seems to be an OS default on Windows but isn't it possible to override it from managed code by interacting with TcpClient? Or how can I wait for the response otherwise?
I've also tried the old-style BeginRead-EndRead way and the same happens on EndRead. The problem is also not caused by Windows Firewall or Defender.
I'd like to wait for a slow response from a client
It's important to note that it's the connection that is failing. The connection timeout is only for establishing a connection, which should always be very fast. In fact, the OS will accept connections on behalf of an application, so you're literally just talking about a packet round-trip. 21 seconds should be plenty.
Once the connection is established, then you can just remove the ReceiveTimeout/SendTimeout and use asynchronous reads to wait forever.
It turns out that the remote host wasn't responding in a timely manner, hence the problem. Let me elaborate, and though this will be a solution very specific to my case maybe it will be useful for others too.
The real issue wasn't a timeout per se, as the exception indicated, but rather what exceptions thrown on subsequent Read() calls have shown: "An existing connection was forcibly closed by the remote host"
The remote host wasn't purposely closing the connection. Rather what happened is that when it was slow to respond it was actually so busy that it wasn't processing any TCP traffic either. While the local host wasn't explicitly sending anything while waiting for a response this still was an issue: the local host tried to send ACKs for previous transmissions of the remote host. Since these couldn't be delivered the local host determined that the remote host "forcibly closed" the connection.
I got the clue from looking at the traffic with Wireshark (always good to try to look at what's beneath the surface instead of guessing around): it was apparent that while the remote host was busy it showed complete radio silence. At the same time Wireshark showed retransmission attempts carried out by the local host, indicating that this is behind the issue.
Thus the solution couldn't be implemented on the local host either, the behavior of the remote host needed to be changed.
I have an TCP asynchronous project and there's a problem when it comes to reconnect the client to the server if the connection was closed.(wasn't closed by the server).
When the server is closed the client gets the following error :
An existing connection was forcibly closed by the remote host at EndReceive(IAyncResult ar) at ReceiveCallback(IAsyncResult ar)
PS:The client can only receive streams from the server.
Things being said , I understand that I need somehow to reconnect to the server .
I have tried to do something but it didn't worked because the client was not responding and exiting.
What I did was , in the catch block of the Receiving callback which contains the steps below , I set the ClientSocket to Disconnected(true) and in a while loop (!ClientSocket.Connected) , I was recalling the main method which starts the asynchronous operation again and the last line of code was Thread.Sleep(n);
These things are done in the receive callback
Getting the string from the buffer
Doing whatever.. with the string
Calling again BeginReceive
PS: I don't want to use another port.
You must catch that exception (you can look for specific error code) and then close that socket and get rid of it. Then create a new one from scratch.
What I have:
I have two socket client programs written in C#.
I have one socket server program (not written by me but it works) in Python.
The problem:
The first c# socket client I wrote works fine and can communicate with the python server client. I can send data over with no issue. However I wanted to rewrite the code to make it more object oriented, so I made the second program which is the same as the first in terms of what is done.
The issue is the second one won't connect, saying this:
System.Net.Sockets.SocketException: An attempt was made to access a socket in a forbidden way by its access permissions.
I googled this and I have come to the realization that the connection from the first connection hasn't been completely unbound.
When I did a netstat -a, I actually saw the connection and it said TIME_WAIT at the end.
The question is, how do I unbind it? Is it on the C#/client side?
FYI I have already tried closing/disconnecting/shutting down the socket and none of that worked. I also put in this command
connection.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true);
upon instantiation of the socket connection but that did not work either.
Would I have to do something on the server side to unbind the connection?
I know you said you already calling close or disconnect.
But are you reinitializing the socket variable.
eg: connection = new System.Net.Sockets.Socket(...
If you are using an older version of .Net you may also have to call Dispose() after call Close().
eg:
connection.Close();
connection.Dispose();
connection = new System.Net.Sockets.Socket(...
Be sure to always work with sockets within try statements as any calls to send and receive data or close the socket could result it an error at which stage, you should log the error and call Close() and then if applicable Dispose() on the socket instance to clear the resources. Once this has been done, you can then reinitialize a new instance of the socket to attempt a new connection to the server.
I've just started learning Sockets through various Google searches but I'm having some problems figuring it out how to properly use Sockets in C# and I'm in the need of some help.
I have a test application (Windows Forms) and on a different class (which is actually in it's own .dll, but that's irrelevant) I have all the server/client code for my sockets code.
Question 1)
On my test application, on the server part, the user can click the "start listening" button and the server part of my sockets application should start listening for connections on the specified address and port, so far so good.
However, the application will be blocked and I can't do anything until someone connects to the server. What if no one connects? How should I handle that? I could specify a receive timeout but what then? It throws an exception, what can I do with that? What I would like is to have some sort of activity on the main application so the user knows the application didn't froze and is waiting for connections. But if a connection doesn't come, it should timeout and close everything.
Maybe I should use asynchronous calls to send/receive methods but they seem confusing and I was not able to make it work, only synchronous work (I'll post my current code below).
Question 2)
Do I need to close anything when some send/receive call times out. As you'll see on my current code, I have a bunch of closes on the socket, but this doesn't feel right somehow. But it also doesn't feel right when an operation times out and I don't close the socket.
In conclusion of my two questions.... I would like an application that doesn't block so the user knows the server is waiting for a connection (with a little marquee animation for instance). If a connection is never established after a period of time, I want to close everything that should be closed. When a connection is established or if it doesn't happen after a period of time, I would like to inform the main application of the result.
Here's some of my code, the rest is similar. The Packet class is a custom class that represents my custom data unit, it's just a bunch of properties based on enums for now, with methods to convert them to bytes and back into properties.
The function that starts to listen for connections is something like this:
public void StartListening(string address, int port) {
try {
byte[] bufferBytes = new byte[32];
if(address.Equals("0.0.0.0")) {
udpSocket.Bind(new IPEndPoint(IPAddress.Any, port));
} else {
udpSocket.Bind(new IPEndPoint(IPAddress.Parse(address), port));
}
remoteEndPoint = new IPEndPoint(IPAddress.Any, 0);
int numBytesReceived = udpSocket.ReceiveFrom(bufferBytes, ref remoteEndPoint);
if(numBytesReceived == 0) {
udpSocket.Close();
return;
}
Packet syncPacket = new Packet(bufferBytes);
if(syncPacket.PacketType != PacketType.Control) {
udpSocket.Close();
return;
}
} catch {
if(udpSocket != null) {
udpSocket.Close();
}
}
}
I'm sure that I have a bunch of unnecessary code but I'm new at this and I'm not sure what do, any help fixing up my code and how to solve the issues above is really appreciated.
EDIT:
I should probably have stated that my requirements are to use UDP and implement these things myself in the application layer. You can consider this as homework but I haven't tagged as such because the code is irrelevant and will not be part of my grade and my problem (my question) is in "how to code" as my Sockets experience is minimal and it's not taught.
However I must say that I solved my problem for now I think... I was using threading on the demo application which was giving me some problems, now I'm using it in the protocol connections, makes more sense and I can easily change my custom protocol class properties and read those from the demo application.
I have specified a timeout and throw a SocketException if it reaches the timeout. Whenever an exception like this is caught, the socket connection is closed. I'm just talking about the connection handshake, nothing more. If no exceptions are caught, the code probably went smooth and the connection is established.
Please adapt your answers accordingly. Right now it doesn't make sense for me to marky any of them as the accepted answer, hope you understand.
You have got stuff a bit wrong.
First of all, UDP is connection-less. You do not connect or disconnect. All you do is to send and receive (must specify destination each time). You should also know that the only thing UDP promises is that a complete message arrives on each read. UDP do not guarantee that your messages arrive in the correct order or that they arrive at all.
TCP on the other hand is connection-based. You connect, send/receive and finally disconnect. TCP is stream-based (while UDP is message-based) which means that you can get a half message in the first read and the other half at the second read. TCP promises you that everything will arrive and in the correct order (or will die trying ;). So using TCP means that you should have some kind of logic to know when a complete message has arrived and a buffer that you use to build the complete message.
The next big question was about blocking. Since you are new at this, I recommend that you use Threads to handle sockets. Put the listener socket in one thread and each connecting socket in a separate thread (5 connected clients = 5 threads).
I also recommend that you use TCP since it's easier to build complete messages than ordering messages and build a transaction system (which will needed if you want to make sure that all messages arrives to/from clients).
Update
You still got UDP wrong. Close doesn't do anything other than cleaning up system resources. You should do something like this instead:
public void MySimpleServer(string address, int port)
{
try
{
byte[] bufferBytes = new byte[32];
if(address.Equals("0.0.0.0")) {
udpSocket.Bind(new IPEndPoint(IPAddress.Any, port));
} else {
udpSocket.Bind(new IPEndPoint(IPAddress.Parse(address), port));
}
remoteEndPoint = new IPEndPoint(IPAddress.Any, 0);
while (serverCanRun)
{
int numBytesReceived = udpSocket.ReceiveFrom(bufferBytes, ref remoteEndPoint);
// just means that one of the clients closed the connection using Shutdown.
// doesnt mean that we cant continue to receive.
if(numBytesReceived == 0)
continue;
// same here, loop to receive from another client.
Packet syncPacket = new Packet(bufferBytes);
if (syncPacket.PacketType != PacketType.Control)
continue;
HandlePacket(packet, endPoint);
}
} catch {
if(udpSocket != null) {
udpSocket.Close();
}
}
}
See? since there are no connection it's just waste of time to close a UDP socket to start listening from another one. The same socket can receive from ALL udp clients that know the correct port and address. That's what the remoteEndPoint is for. It tells which client that send the message.
Update 2
Small update to make a summary of all my comments.
UDP is connectionless. You can never detect if a connection have been established or disconnected. The Close method on a UDP socket will only free system resources. A call on client.Close() will not notify the server socket (as it will with TCP).
The best way to check if a connection is open is to create a ping/pong style of packet. i.e. the client sends a PING message and the server responds with a PONG. Remember that UDP will not try to resend your messages if they do not arrive. Therefore you need to resend the PING a couple of times before assuming that the server is down (if you do not receive a PONG).
As for clients closing you need to send your own message to the server telling it that the the client is going to stop talking to the server. For reliability the same thing goes here, keep resending the BYE message until you receive a reply.
imho it's mandatory that you implement a transactional system for UDP if you want reliability. SIP (google rfc3261) is an example of a protocol which uses transactions over UDP.
From your description I feel you should use TCP sockets instead of UDP. The difference is
TCP - You wait for a connection at a particuler IP:Port some user can connect to it and until the socket is closed can communicate by sending and receiveing information. This is like calling someone on phone.
UDP - you wait for a message at some IP:Port. User who wants to communicate just sends a message through UDP. You will receive the message through UDP. The order of delivery is not guaranteed. This is more like sending a snail mail to someone. There is no dedicated communication channel established.
Now coming to your problem
Server
Create a Socket with TCP family.
Either create a thread and accept the connection in that thread or use the BeginAccept apis of Socket.
In the main thread you can still display the ticker or whatever you want to do.
Client
Connect to the server.
Communicate by sending and receiving data.
I have written a TCPIP server that implements a FileSystemWatcher and fills a queue with data parsed from new files acquired by the FSW.
A single client will connect to this server and ask for data from the queue (no other client will need to connect at any time). If no data exists, the client will wait (1 second) and try again.
Both client and server are written asynchronously - my question is: should the client create a new socket for each transaction (inside the while loop), or just leave the socket open (outside the while loop)?
client.Connect()
while(bCollectData)
{
... communicate ...
Thread.Sleep(1000);
}
client.Shutdown(SocketShutdown.Both);
client.Close();
I would suggest you to leave socket open and even better to block it on the server, so that you didn't have to do Thread.Sleep. When the server will have some data he will send the message to the client.
The code will look something like this
while(bCollectData)
{
_socket.recv(...); //this line will wait for response from server
//... process message and start another wait in the next iteration.
}
using this approach you will get all messages immediately and avoid unneeded messages sent between client and server(the messages which return that server has no data).
I would leave the socket open outside the loop, reconnecting every iteration seems like a waste of resources.
I would not close the socket. Every time you connect you have some handshake.