I have created an asynchronous server that can read in messages from any number of clients. My server code is closely related to this example: http://msdn.microsoft.com/en-us/library/fx6588te.aspx
After a client connects I would like to periodically send out data to that client, maybe 2 or 3 times per second. I can't think of a good way to achieve this with an asynchronous send(). I'm assuming that some sort of timing mechanism would need to be added to my AcceptCallback() method because that is where the connection to the client happens.
In the previous version of my server I used blocking sockets and just looped my send() method in an infinite while() loop and called sleep() to get the timing down.
Here's what I'm thinking:
public void AcceptCallback(IAsyncResult ar)
{
allDone.Set(); // Signal the main thread to continue.
// Get the socket that handles the client request.
Socket listener = (Socket)ar.AsyncState;
Socket handler = listener.EndAccept(ar);
IPEndPoint remotePoint = (IPEndPoint)handler.RemoteEndPoint;
IPAddress remoteAddress = remotePoint.Address;
Console.WriteLine("Connected to {0}!", remoteAddress.ToString());
// Create the state object.
StateObject state = new StateObject();
state.workSocket = handler;
//Start periodically sending here??
handler.BeginReceive(state.buffer, 0, StateObject.BufferSize, 0,
new AsyncCallback(ReadCallback), state);
}
I would set up a Timer object to send data to the client. Instantiate and start the timer in the AcceptCallback method at your comment. You'll have to keep track of information to allow that timer callback to send data to the client (like the socket, and some sort of test to allow it to stop--although you can simply turn the timer off, but you'd have to keep track of the timer in that case).
BTW, never call Sleep in situations like this because that commits your thread to sitting around for some period of time and you can't easily abort it to get the thread back (to exit or use for something else).
Related
I have an application that is reading data from a Udp server on 32 different ports that I need to process. I'm using the UdpClient.BeginReceive that is calling itself because I want to listen all the time :
private void ProcessEndpointData(IAsyncResult result)
{
UdpClient client = result.AsyncState as UdpClient;
// points towards whoever had sent the message:
IPEndPoint source = new IPEndPoint(0, 0);
// schedule the next receive operation once reading is done:
client.BeginReceive(new AsyncCallback(this.ProcessEndpointData), client);
// get the actual message and fill out the source:
this.DecodeDatagram(new DatagrammeAscb()
{
Datagramme = this.ByteArrayToStructure<Datagram>(client.EndReceive(result, ref source))
});
}
When I stop the server side, the function is waiting for data (that is normal behavior). What I would like to do is to detect when the server is disconnected and then close all my clients.
I'm asking myself if I should use sockets class to have more controls or just maybe I'm missing something here.
Anyway thanks for your help.
I'm rewriting an ancient VB6 program in C# (.Net Framework 4.0). It communicates with a piece of industrial equipment on the factory floor. VB6 used some old COM-based socket software; I'm using the .Net Socket class.
When I send a message to the equipment I expect a response back so I know to listen for one then. But the equipment can also send messages asynchronously without warning (say, to indicate a failure or problem). So I always have to receive those. So what I'd really like is an event handler that gets called whenever anything comes in from the equipment.
The Socket class seems to use a BeginReceive/EndReceive scheme for receive event handling. Can I just do a BeginReceive once at the start of my program to define an event-handler for all incoming messages, or do I have to constantly be doing BeginReceive/EndReceive's throughout my program?
Thanks in advance for clarifying the correct way to do this.
Are you the server?
If you are the server, you will listen for a socket connection, and then accept the socket connection and store it. You will then call BeginReceive with the stored socket. In the BeginReceive method, you will provide a callback function to receive, and handle the data.
Once you receive data, the callback happens. The callback function will call EndReceive on the stored connection. This is where you get/handle the data. You will also call BeginReceive again to wait for more data.
This way, the BeginReceive and EndReceive will run in a circle: you are always receiving data, and waiting for more data.
Here is an example:
void WaitForData(SocketState state)
{
try
{
state.Socket.BeginReceive(state.DataBuffer, 0, state.DataBuffer.Length, SocketFlags.None, new AsyncCallback(ReadDataCallback), state);
}
catch (SocketException se)
{
//Socket has been closed
//Close/dispose of socket
}
}
public void ReadDataCallback(IAsyncResult ar)
{
SocketState state = (SocketState)ar.AsyncState;
try
{
// Read data from the client socket.
int iRx = state.Socket.EndReceive(ar);
//Handle Data....
WaitForData(state);
}
catch (ObjectDisposedException)
{
//Socket has been closed
//Close/dispose of socket
}
catch (SocketException)
{
//Socket exception
//Close/dispose of socket
}
}
EDIT:
As per your comment, here is an example of a C# asynchronous client: http://msdn.microsoft.com/en-us/library/bbx2eya8.aspx.
The BeginReceive/EndReceive work similar to the server.
I need to write some code that uses TcpListener. The object that using the TcpListener has 3 possibilities: Listen, Stop Listen, Send message. This is how my code looks:
public class someClass
{
public bool listenerEnable {get; set; }
public void StartListen()
{
.
.
.
while (listenerEnable)
{
// Block until client connected
TcpClient client = server.AcceptTcpClient();
// code that doing something with the client message ...
}
}
}
Now, I'm not sure I know how I can keep the thread safe when I want to stop the listener state (change the listenerEnable to be false).
Also I'm not sure I know how to keep this thread safe when I want to send some message to the client (in some separated method) without stopping the server listener state.
Thanks for any help.
I would suggest waiting on an event rather than waiting on a variable. In your current scheme, consider the case when your loop test for whether listener variable is true. If it is it enters the loop and waits for a incoming connection, and blocks. So now even if another thread sets the listener variable to be false, your loop will not exit till someone connects to it and it processes that connection.
One way of working around the problem above will be to have code like:
WaitHandle[] waitHandles = new WaitHandle[] {endlLoopEvent};
while(true)
{
int ret = WaitHandle.WaitAny(waitHandles, 100);
if(WaitTimeout == ret) continue;
else if(0 == ret) break; //our event has been signaled.
else
{
if(!server.Pending()) continue; //Go back to the loop if no connection pending
TcpClient client = server.AcceptTcpClient();
// You can spawn a thread to service the request.
}
}
Sending would not affect the loop above, provided it is not in response to a request for connection above.
Writing a correct, scalable socket server is not simple - I suggest you find / buy one - this has been done many times before.
To answer your question, your problem is that AcceptTcpClient is a blocking call. You will want to use the APM ( Asyncronous Programming Model ) methods that start with BeginXXX and EndXXXlike MSDN BeginAcceptTcpClient.
These methods don't block threads, but you will have to handle the concurrency.
We have an application in production that is supposed to be a multithreaded socket listener. I am starting to have my doubts because the logs the app generates makes it appear as if it is processing the streams it receives synchronously. In an effort of trying not to paste a wall of code here, I will supply the first portion of supposedly asynch tcp code: Is this proper practice?
/// <summary>
/// Start an Asynchronous Socket to listen for connections.
/// </summary>
public static void StartListening()
{
Socket listenerSocket = null;
try
{
var ipHostInfo = Dns.GetHostEntry(Dns.GetHostName());
var ipAddress = ipHostInfo.AddressList[Socket.OSSupportsIPv6 ? 1 : 0];
//Create TCP/IP Socket
listenerSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
listenerSocket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, 1);
listenerSocket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.KeepAlive, 1);
//Bind the socket to the local endpoint and listen for incoming connections.
//listenerSocket.Bind(new IPEndPoint(ipAddress, m_client.RemotePort));
listenerSocket.Bind(new IPEndPoint(ipAddress, Int32.Parse(ConfigurationManager.AppSettings["ListenerPort"])));
listenerSocket.Listen(m_maxSocketConnections);
while (true)
{
//Set the event to nonsignaled state
m_pAllDone.Reset();
//Start an asynchronous socket
listenerSocket.BeginAccept(new AsyncCallback(AcceptCallback), listenerSocket);
//Wait until a connection is made and processed before continuing
m_pAllDone.WaitOne();
}
}
This call is not multithreaded, it is simply asynchronous. From the docs:
When your application calls BeginAccept, the system usually uses a separate thread to execute the specified callback method and blocks on EndAccept until a pending connection is retrieved.
The BeginAccept method creates one other thread that blocks and processes the incoming packets asynchronously. It does not spawn a NEW thread every time a message comes in.
Socket.BeginAccept is documented as "Begins an asynchronous operation to accept an incoming connection attempt.", so this part of the operation (the acceptance of the socket connect request) is asynchronous. That isn't to say that what you do in AcceptCallback is guaranteed to be multithreaded- there are plenty of ways in which you could make that synchronous or even single-threaded, even with async sockets.
I'm currently in the process of developing a C# Socket server that can accept multiple connections from multiple client computers. The objective of the server is to allow clients to "subscribe" and "un-subscribe" from server events.
So far I've taken a jolly good look over here: http://msdn.microsoft.com/en-us/library/5w7b7x5f(v=VS.100).aspx and http://msdn.microsoft.com/en-us/library/fx6588te.aspx for ideas.
All the messages I send are encrypted, so I take the string message that I wish to send, convert it into a byte[] array and then encrypt the data before pre-pending the message length to the data and sending it out over the connection.
One thing that strikes me as an issue is this: on the receiving end it seems possible that Socket.EndReceive() (or the associated callback) could return when only half of the message has been received. Is there an easy way to ensure each message is received "complete" and only one message at a time?
EDIT: For example, I take it .NET / Windows sockets does not "wrap" the messages to ensure that a single message sent with Socket.Send() is received in one Socket.Receive() call? Or does it?
My implementation so far:
private void StartListening()
{
IPHostEntry ipHostInfo = Dns.GetHostEntry(Dns.GetHostName());
IPEndPoint localEP = new IPEndPoint(ipHostInfo.AddressList[0], Constants.PortNumber);
Socket listener = new Socket(localEP.Address.AddressFamily, SocketType.Stream, ProtocolType.Tcp);
listener.Bind(localEP);
listener.Listen(10);
while (true)
{
// Reset the event.
this.listenAllDone.Reset();
// Begin waiting for a connection
listener.BeginAccept(new AsyncCallback(this.AcceptCallback), listener);
// Wait for the event.
this.listenAllDone.WaitOne();
}
}
private void AcceptCallback(IAsyncResult ar)
{
// Get the socket that handles the client request.
Socket listener = (Socket) ar.AsyncState;
Socket handler = listener.EndAccept(ar);
// Signal the main thread to continue.
this.listenAllDone.Set();
// Accept the incoming connection and save a reference to the new Socket in the client data.
CClient client = new CClient();
client.Socket = handler;
lock (this.clientList)
{
this.clientList.Add(client);
}
while (true)
{
this.readAllDone.Reset();
// Begin waiting on data from the client.
handler.BeginReceive(client.DataBuffer, 0, client.DataBuffer.Length, 0, new AsyncCallback(this.ReadCallback), client);
this.readAllDone.WaitOne();
}
}
private void ReadCallback(IAsyncResult asyn)
{
CClient theClient = (CClient)asyn.AsyncState;
// End the receive and get the number of bytes read.
int iRx = theClient.Socket.EndReceive(asyn);
if (iRx != 0)
{
// Data was read from the socket.
// So save the data
byte[] recievedMsg = new byte[iRx];
Array.Copy(theClient.DataBuffer, recievedMsg, iRx);
this.readAllDone.Set();
// Decode the message recieved and act accordingly.
theClient.DecodeAndProcessMessage(recievedMsg);
// Go back to waiting for data.
this.WaitForData(theClient);
}
}
Yes, it is possible you'll have only part of message per one receiving, also it can be even worse during transfer only part of message will be sent. Usually you can see that during bad network conditions or under heavy network load.
To be clear on network level TCP guaranteed to transfer your data in specified order but it not guaranteed that portions of data will be same as you sent. There are many reasons for that software (take a look to Nagle's algorithm for example), hardware (different routers in trace), OS implementation, so in general you should never assume what part of data already transferred or received.
Sorry for long introduction, below some advices:
Try to use relatevely "new" API for high-performance socket server, here samples Networking Samples for .NET v4.0
Do not assume you always send full packet. Socket.EndSend() returns number of bytes actually scheduled to send, it can be even 1-2 bytes under heavy network load. So you have to implement resend rest part of buffer when it required.
There is warning on MSDN:
There is no guarantee that the data
you send will appear on the network
immediately. To increase network
efficiency, the underlying system may
delay transmission until a significant
amount of outgoing data is collected.
A successful completion of the
BeginSend method means that the
underlying system has had room to
buffer your data for a network send.
Do not assume you always receive full packet. Join received data in some kind of buffer and analyze it when it have enough data.
Usually, for binary protocols, I add field to indicate how much data incoming, field with message type (or you can use fixed length per message type (generally not good, e.g. versioning problem)), version field (where applicable) and add CRC-field to end of message.
It not really required to read, a bit old and applies directly to Winsock but maybe worth to study: Winsock Programmer's FAQ
Take a look to ProtocolBuffers, it worth to learn: http://code.google.com/p/protobuf-csharp-port/, http://code.google.com/p/protobuf-net/
Hope it helps.
P.S. Sadly sample on MSDN you refer in question effectively ruin async paradigm as stated in other answers.
Your code is very wrong. Doing loops like that defeats the purpose of asynchronous programming. Async IO is used to not block the thread but let them continue doing other work. By looping like that, you are blocking the thread.
void StartListening()
{
_listener.BeginAccept(OnAccept, null);
}
void OnAccept(IAsyncResult res)
{
var clientSocket = listener.EndAccept(res);
//begin accepting again
_listener.BeginAccept(OnAccept, null);
clientSocket.BeginReceive(xxxxxx, OnRead, clientSocket);
}
void OnReceive(IAsyncResult res)
{
var socket = (Socket)res.Asyncstate;
var bytesRead = socket.EndReceive(res);
socket.BeginReceive(xxxxx, OnReceive, socket);
//handle buffer here.
}
Note that I've removed all error handling to make the code cleaner. That code do not block any thread and is therefore much more effecient. I would break the code up in two classes: the server handling code and the client handling code. It makes it easier to maintain and extend.
Next thing to understand is that TCP is a stream protocol. It do not guarentee that a message arrives in one Receive. Therefore you must know either how large a message is or when it ends.
The first solution is to prefix each message with an header which you parse first and then continue reading until you get the complete body/message.
The second solution is to put some control character at the end of each message and continue reading until the control character is read. Keep in mind that you should encode that character if it can exist in the actual message.
You need to send fixed length messages or include in the header the length of the message. Try to have something that allows you to clearly identify the start of a packet.
I found 2 very useful links:
http://vadmyst.blogspot.com/2008/03/part-2-how-to-transfer-fixed-sized-data.html
C# Async TCP sockets: Handling buffer size and huge transfers