수안이의 컴퓨터 연구실

Network programming in windows is possible with sockets. A socket is like a handle to a file. Socket programming resembles the file IO as does the Serial Communication. You can use sockets programming to have two applications communicate with each other. The application are typically on the different computers but they can be on same computer. For the two applications to talk to each either on the same or different computers using sockets one application is generally a server that keeps listening to the incoming requests and the other application acts as a client and makes the connection to the server application.

The server application can either accept or reject the connection. If the server accepts the connection, a dialog can begin with between the client and the server.  Once the client is done with whatever it needs to do it can close the connection with the server. Connections are expensive in the sense that servers allow finite connections to occur.  During the time client has an active connection it can send the data to the server and/or receive the data.

The complexity begins here. When either side (client or server) sends data the other side is supposed to read the data. But how will the other side know when data has arrived. There are two options - either the application needs to poll for the data at regular intervals or there needs to be some sort of mechanism that would enable application to get notifications and application can read the data at that time. Well , after all Windows is an event driven system and the notification system seems an obvious and best choice and it in fact is.

As I said the two applications that need to communicate with each other   need to make a connection first. In order for the two application to make connections the two applications need to identify each other ( or each other's computer ). Computers on network have a unique identifier called  I.P. address which is represented in dot-notation like 10.20.120.127 etc. Lets see how all this works in .NET.

System.Net.Sockets Namespace

Before we go any further, download the source code attached with this article. Extract the zip file to a folder say c:\Temp you will see following two folders :

• Server
• Client

In the Server folder there will be one EXE . And in the client there will be the source code in C# that is our client. There will be one file called SocketClient.sln  which the solution file . If you double click that your VS.NET will be launched and you will see the  project SocketClientProj in the solution. Under this project you will have SocketClientForm.cs file.  Now build the code ( by pressing Ctrl-Shift-B) and run the code you will see the following dialog box:

As you can see the dialog box has a field for Host IP address ( which is the IP address of the machine on which you will run the Server Application ( located under Server folder) ). Also there is a field where you can specify port number at which the Server is listening. The server app I have provided here listens at port 8221. So I have specified port to be 8221.

After specifying these parameters we need to connect to the server. So pressing Connect will connect to the server and to close the connection press Close. To send some data to the server type some data in the field near the button name Tx and if you press Rx the application will block unless there is some data to read.
With this info lets now try to check the code behind this:

Socket programming in .NET is made possible by Socket class present inside the System.Net.Sockets namespace.
Socket class  has several method and properties and a constructor.
The first step is to create an object of this class.
Since there is only one constructor we have no choice but to use it.

Here is how to create the socket:

m_socListener = new Socket(AddressFamily.InterNetwork,SocketType.Stream,ProtocolType.IP);

The first parameter is the address family which we will use interNetwork - other options include Banyan NetBios etc.
AddressFamily is an enum defined in Sockets namespace.
Next we need to specify socket type: and we would use reliable two way connection-based sockets (stream) instead of un-reliable Connectionless sockets ( datagrams) . So we obviously specify stream as the socket type and finally we are using TCP/IP so we would specify protocol type as Tcp.

Once we have created a Socket we need to make a connection to the server since we are using connection-based communication.
To connect to the remote computer  we need to know the IP Address and port at which to connect.
In .NET there is a class under System.Net namespace called IPEndPoint which represents a network computer  as an IP address and a port number.

The IPEndPoint has two  constructors - one that takes a IP Address and Port number  and one that takes long and port number. Since we have computer IP address we would use the former

public IPEndPoint(System.Net.IPAddress address, int port);

As you can see the first parameter takes a IPAddress object. If you examine the IPAddress class you will see that it has a static method called Parse that returns IPAddress given a string ( of dot notation ) and second parameter will be the port number. Once we have endpoint ready we can use Connect method of Socket class to connect to the end point  ( remote server computer ).
Here is the code:

System.Net.IPAddress ipAdd = System.Net.IPAddress.Parse("10.10.101.200");
System.Net.IPEndPoint remoteEP = new IPEndPoint (iAdd,8221);
m_socClient.Connect (remoteEP);

These three lines of code will make a connection to the remote host running on computer with IP 10.10.101.200 and listening at port 8221. If the Server is running and started ( listening ), the connection will succeed. If however the server is not running an exception called SocketException will be thrown. If you catch the   exception and check the Message property of the exception in this case you see following text:

"No connection could be made because the target machine actively refused it."

Similarly if you already have made a connection and the server somehow dies , you will get following exception if you try to send data.

"An existing connection was forcibly closed by the remote host"

Assuming that the connection is made, you can send data to other side using the Send method of the Socket class.
Send method has several overloads. All of them take a byte array . For example if you want to send "Hello There" to host you can use following call:

try
{
String szData = "Hello There";
byte[] byData = System.Text.Encoding.ASCII.GetBytes(szData);
m_socClient.Send(byData);
}
catch (SocketException se)
{
MessageBox.Show ( se.Message );
}

Note that the Send method is blocking. What it means the call will block till the data has been sent or an exception has been thrown. There is an non-blocking version of the send which we will discuss in the next part of this article.
Similar to Send there is a Receive method on the Socket class. You can receive data using following call:

byte [] buffer = new byte[1024];
int iRx = m_socClient.Receive (buffer);

The Receive method again is blocking. It means that if there is no data available the call will block until some data arrives or an exception   is thrown.

Non-blocking version of Receive method is more useful than the non-blocking version of Send because if we opt for block Receive , we are effectively doing polling. There is no events about data arrival. This model does not work well for serious applications. But all that is the subject of our next part of this article. For now we will settle with the blocking version.
In order to use the source code and application here you would need to run the Server first:

Here is the way Server looks like:

When you launch the Server, click Start to start listening. The Server listens at port 8221. So make sure you specify the port number 8221 in the port field of our client application. And in the IPAddress field of Client App enter the IP Address of the machine on which the Server is running. If you send some data to server from the client by pressing Tx button, you will see that data in the grayed out edit box.

Socket Programming in C# - Part II
(Page 1 of 2 )

This is the second part of Ashish's two part series about handling sockets in the C# language. Read this article to learn how to use sockets with the .Net framework.This is the second part of the previous article about the socket programming. In the earlier article we created a client but that client used to make blocking IO calls ( Receive ) to read data at regular intervals (via clicking the Rx button). But as I said in my earlier article, that model does not work very well in a real world application. Also since Windows is an events-based system, the application (client) should get notifications of some kind whenever the data is received so that client can read it rather than client continuously polling for data.

Well that is possible with a little effort. If you read the first part of this article, you already know that the  Socket class in  the Systems.Net.Sockets namespace has several methods like  Receive and Send which are blocking calls. Besides there are also functions like BeginReceive , BeginSend etc. These are meant for asynchronous IO . For example , there are at least two problems with the blocking Receive:

1. When you call Receive function the call blocks if no data is present, the call blocks till some data arrives.
2. Even if there is data when you made the receive call , you don't know when to call next time. You need to do  polling  which is not an efficient way.

Although you can argue that one can overcome these shortcomings by multithreading meaning that one can spawn a new thread and let that thread do the polling and notifies the main thread of the data. Well this concept will work well. But even if you create a new thread it would require your main thread to share the CPU time with this new thread. Windows operating system (Windows NT /2000 /XP) provide what is called Completion Port IO model for doing overlapped ( asynchronous) IO.

The details of IO Completion port are beyond the scope of the current discussion, but to make it simple you can think of IO Completion Ports as the most efficient mechanism for doing asynchronous IO in Windows that is provided by the Operating system. Completion Port model can be applied to any kind of IO including the file read /write and serial communication.  

The .NET asynchronous socket programming helper class's Socket provides the similar model.  

BeginReceive  

.NET framework's Socket class provides BeginReceive method to receive data asynchronously i.e., in an non-blocking manner The BeginReceive method has following signature:

public IAsyncResult BeginReceive( byte[] buffer, int offset, int size, SocketFlags socketFlags, AsyncCallback callback, object state );

The way BeginReceive function works is that you pass the function a buffer , a callback function (delegate)   which will be called whenever data arrives.

The last parameter,  object,   to the BeginReceive can be any class derived from object  ( even null ) .
When the callback function is called it means that the BeginReceive function completed which means that the data has arrived.
The callback function needs to have the following signature:

void AsyncCallback( IAsyncResult ar);

As you can see the callback returns void and is passed in one parameter , IAsyncResult interface , which contains  the status of the asynchronous receive  operation.

The IAsyncResult interface has several properties. The first parameter - AsyncState - is an object which is same as the last parameter that you passed to BeginReceive(). The second  property is AsyncWaitHandle which we will discuss in a moment. The third property indicates whether the receive was really asynchronous or it finished synchronously. The important thing to follow here is that it not necessary for an asynchronous function to always  finish asynchronously - it can complete immediately if the data is already present. Next parameter is IsComplete   which indicates whether the operation has completed or not.

If you look at the signature of the BeginReceive again you will note that the function also returns IAsyncResult. This is interesting. Just now I said that I will talk about the second peoperty of the IAsyncResult  in a moment. Now is that moment. The second parameter is called AsyncWaitHandle.

The AsyncWaitHandle is of type WaitHandle, a class defined in the System.Threading namespace. WaitHandle class encapsulates a Handle (which is a pointer to int or handle ) and provides a way to wait for that handle to become signaled. The class has several static methods like WaitOne ( which is similar to WaitForSingleObject ) WaitAll ( similar to WaitForMultipleObjects with waitAll true ) , WaitAny etc. Also there are overloads of these functions available with timeouts.

Coming back to our discussion of IAsyncResult interface, the handle in AsyncWaitHandle (WaitHandle) is signalled when the receive operation completes. So if we wait on that handle infinitely we will be able to know when the receive completed. This means if we pass that WaitHandle to  a different thread, the different thread can wait on that handle and can notify us of the fact that the data has arrived and so that we can read the data. So you must be wondering if we use this mechanism why would we use callback function. We won't. Thats right. If  we choose to use this mechanism of the WaitHandle then the callback function parameter to the BeginReceive can be null as shown here:

//m_asynResult is  declared of type IAsyncResult and assumming that m_socClient has made a connection.
m_asynResult = m_socClient.BeginReceive(m_DataBuffer,0,m_DataBuffer.Length,SocketFlags.None,null,null);
if ( m_asynResult.AsyncWaitHandle.WaitOne () )
{
int iRx = 0 ;
iRx = m_socClient.EndReceive (m_asynResult);
char[] chars = new char[iRx + 1];
System.Text.Decoder d = System.Text.Encoding.UTF8.GetDecoder();
int charLen = d.GetChars(m_DataBuffer, 0, iRx, chars, 0);
System.String szData = new System.String(chars);
txtDataRx.Text = txtDataRx.Text + szData;
}

Even though this mechanism will work fine using multiple threads, we will for now stick to our callback mechanism where the system notifies us of the completion of asynchronous operation which is Receive in this case .
Lets say we made the call to BeginReceive and after some time the data arrived and our callback function got called.Now question is where's the data? The data is now available in the buffer that you passed as the first parameter while making call to BeginReceive() method . In the following example the data will be available in m_DataBuffer :

BeginReceive(m_DataBuffer,0,m_DataBuffer.Length,SocketFlags.None, pfnCallBack,null);

But before you access the buffer you need to call EndReceive() function on the socket. The EndReceive will return the number of bytes received . Its not legal to access the buffer before calling EndReceive.
To put it all together  look at the following simple code:

MULTIPLE SOCKETS

Now lets say you have two sockets connecting to either two different servers or same server(which is valid) . One way is to create two different delegates and attach a different delegate to different BeginReceive function. What if you have 3 sockets or for that matter n sockets , this approach of creating multiple delegates does not fit well in such cases. So the solution should be to use only one delegate callback. But then the problem is how do we know what socket completed the operation.

Fortunately there is a better solution. If you look at the BeginReceive function again, the last parameter is  a state is an object. You can pass anything here . And whatever you pass here will be passed back to you later as the part of parameter to the callback function. Actually this object will be passed to you later as a IAsyncResult.AsyncState. So when your callback gets called, you can use this information to identify the socket that completed the operation. Since you can pass any thing to this last parameter, we can pass a class object that contains as much information as we want. For example we can declare a class as follows:

public class CSocketPacket
{
public System.Net.Sockets.Socket thisSocket;
public byte[] dataBuffer = new byte[1024];
}

and call BeginReceive as follows:

CSocketPacket theSocPkt = new CSocketPacket ();
theSocPkt.thisSocket = m_socClient;
// now start to listen for any data...
m_asynResult = m_socClient.BeginReceive (theSocPkt.dataBuffer ,0,theSocPkt.dataBuffer.Length , SocketFlags.None,pfnCallBack,theSocPkt);

and in the callback function we can get the data like this:

public void OnDataReceived(IAsyncResult asyn)
{
  try
  {
CSocketPacket theSockId = (CSocketPacket)asyn.AsyncState ;
//end receive...
int iRx = 0 ;
iRx = theSockId.thisSocket.EndReceive (asyn);
char[] chars = new char[iRx + 1];
System.Text.Decoder d = System.Text.Encoding.UTF8.GetDecoder();
int charLen = d.GetChars(theSockId.dataBuffer, 0, iRx, chars, 0);
System.String szData = new System.String(chars);
txtDataRx.Text = txtDataRx.Text + szData;
WaitForData();
  }
  catch (ObjectDisposedException )
  {
System.Diagnostics.Debugger.Log(0,"1","\nOnDataReceived: Socket has been closed\n");
  }
  catch(SocketException se)
  {
MessageBox.Show (se.Message );
  }
}

To see the whole application download the code and you can see the code.

There is one thing which you may be wondering about. When you call BeginReceive , you have to pass a buffer and the number of bytes to receive. The question here is how big should the buffer be. Well, the answer is it depends. You can have a very small buffer size say, 10 bytes long and if there are 20 bytes ready to be read, then you would require 2 calls to receive the data. On the other hand if you specify the length as 1024 and you know you are always going to receive data in 10-byte  chunks you are unnecessarily wasting memory. So the length depends upon your application.

Server Side

If you have understood whatever I have described so far, you will easily understand the Server part of the socket application. So far we have been talking about a client making connection to a server and sending and receiving data.

On the Server end, the application has to send and receive data. But in addition to adding and receiving data, server has to allow the clients to make connections by listening at some port. Server does not need to know client I.P. addresses. It really does not care where the client is because its not the server but client who is responsible for making connection. Server's responsibility is to manage client connections.

On the server side there has to be one socket called the Listener socket that listens at a specific port number for client connections. When the client makes a  connection, the server needs to accept the connection and then in order for the server to send and receive data from that connected client it needs to talk to that client through the socket that it got when it accepted the connection . Following code illustrates how server listens to the connections and accepts the connection:

public Socket m_socListener;
public void StartListening()
{
try
{
//create the listening socket...
m_socListener = new Socket(AddressFamily.InterNetwork,SocketType.Stream,ProtocolType.Tcp);
IPEndPoint ipLocal = new IPEndPoint ( IPAddress.Any ,8221);
//bind to local IP Address...
m_socListener.Bind( ipLocal );
//start listening...
m_socListener.Listen (4);
// create the call back for any client connections...
m_socListener.BeginAccept(new AsyncCallback ( OnClientConnect ),null);
cmdListen.Enabled = false;
}
catch(SocketException se)
{
MessageBox.Show ( se.Message );
}
}

If you look at the above code carefully you will see that its similar to we did in the asynchronous client. First of all the we need to create a listening socket and bind it to a local IP address. Note that we have given Any as the IPAddress . I will explain what it means later. and also we have passed port number as 8221. Next we made a call to Listen function. The 4 is a parameter indicating backlog indicating the maximum length of the queue of pending connections.

Next we made a call to BeginAccept passing it a delegate callback. BeginAccept is a non-blocking method that returns immediately and when a client has made requested a connection, the callback routine is called and you can accept the connection by calling EndAccept. The EndAccept returns a socket object which represents the incoming connection. Here is the code for the callback delegate:

public void OnClientConnect(IAsyncResult asyn)
{
try
{
  m_socWorker = m_socListener.EndAccept (asyn);
WaitForData(m_socWorker);
}
catch(ObjectDisposedException)
{
             System.Diagnostics.Debugger.Log(0,"1","\n OnClientConnection: Socket has been closed\n");
}
catch(SocketException se)
{
MessageBox.Show ( se.Message );
}
}

Here we accept the connection and call WaitForData which in turn calls BeginReceive for the m_socWorker.

If we want to send data  some data to client we use m_socWorker socket for that purpose like this:

Object objData = txtDataTx.Text;
byte[] byData = System.Text.Encoding.ASCII.GetBytes(objData.ToString ());
m_socWorker.Send (byData);

Here is how our client looks like

Here is how our server looks like

That is all there is to the socket programming.

The .NET framework provides two namespaces, System.Net and System.Net.Sockets for network programming. The classes and methods of these namespaces help us to write programs, which can communicate across the network. The communication can be either connection oriented or connectionless. They can also be either stream oriented or data-gram based. The most widely used protocol TCP is used for stream-based communication and UDP is used for data-grams based applications. 

The System.Net.Sockets.Socket is an important class from the System.Net.Sockets namespace. A Socket instance has a local and a remote end-point associated with it. The local end-point contains the connection information for the current socket instance. 

There are some other helper classes like IPEndPoint, IPADdress, SocketException etc, which we can use for Network programming. The .NET framework supports both synchronous and asynchronous communication between the client and server. There are different methods supporting for these two types of communication.

A synchronous method is operating in blocking mode, in which the method waits until the operation is complete before it returns. But an asynchronous method is operating in non-blocking mode, where it returns immediately, possibly before the operation has completed.

Dns Class

The System.net namespace provides this class, which can be used to creates and send queries to obtain information about the host server from the Internet Domain Name Service (DNS). Remember that in order to access DNS, the machine executing the query must be connected to a network. If the query is executed on a machine, that does not have access to a domain name server, a System.Net.SocketException is thrown. All the members of this class are static in nature. The important methods of this class are given below. 

public static IPHostEntry GetHostByAddress(string address)

Where address should be in a dotted-quad format like "202.87.40.193". This method returns an IPHostEntry instance containing the host information. If DNS server is not available, the method returns a SocketException. 

public static string GetHostName()

This method returns the DNS host name of the local machine.

In my machine Dns.GetHostName() returns vrajesh which is the DNS name of my machine. 

public static IPHostEntry Resolve(string hostname)

This method resolves a DNS host name or IP address to a IPHostEntry instance. The host name should be in a dotted-quad format like 127.0.01 or www.microsoft.com. 

IPHostEntry Class

This is a container class for Internet host address information. This class makes no thread safety guarantees. The following are the important members of this class. 

AddressList Property

Gives an IPAddress array containing IP addresses that resolve to the host name. 

Aliases Property

Gives a string array containing DNS name that resolves to the IP addresses in AddressList property. 

The following program shows the application of the above two classes.

using System;
using System.Net;
using System.Net.Sockets;
class MyClient
{
           public static void Main()
           {
                       IPHostEntry IPHost = Dns.Resolve("www.hotmail.com");
                       Console.WriteLine(IPHost.HostName);
                       string []aliases = IPHost.Aliases;
                       Console.WriteLine(aliases.Length);
                       IPAddress[] addr = IPHost.AddressList;
                       Console.WriteLine(addr.Length);
                       for(int i= 0; i < addr.Length ; i++)
                       {
                                   Console.WriteLine(addr[i]);
                       }
           }
}

IPEndPoint Class

This class is a concrete derived class of the abstract class EndPoint. The IPEndPoint class represents a network end point as an IP address and a port number. There is couple of useful constructors in this class: 

IPEndPoint(long addresses, int port)
IPEndPoint (IPAddress addr, int port) 
IPHostEntry IPHost = Dns.Resolve("www.c-sharpcorner.com");
Console.WriteLine(IPHost.HostName);
string []aliases = IPHost.Aliases;
IPAddress[] addr = IPHost.AddressList;
Console.WriteLine(addr[0]);
EndPoint ep = new IPEndPoint(addr[0],80);

Socket Programming: Synchronous Clients 

The steps for creating a simple synchronous client are as follows.

1. Create a Socket instance.
2. Connect the above socket instance to an end-point.
3. Send or Receive information.
4. Shutdown the socket
5. Close the socket 

The Socket class provides a constructor for creating a Socket instance. 

public Socket (AddressFamily af, ProtocolType pt, SocketType st)

Where AddressFamily, ProtocolType and SocketTYpe are the enumeration types declared inside the Socket class.

The AddressFamily member specifies the addressing scheme that a socket instance must use to resolve an address. For example AddressFamily.InterNetwork indicates that an IP version 4 addresses is expected when a socket connects to an end point. 

The SocketType parameter specifies the socket type of the current instance. For example SocketType.Stream indicates a connection-oriented stream and SocketType.Dgram indicates a connectionless stream.

The ProtocolType parameter specifies the ptotocol to be used for the communication. For example ProtocolType.Tcp indicates that the protocol used is TCP and ProtocolType.Udp indicates that the protocol using is UDP. 

public Connect (EndPoint ep)

The Connect() method is used by the local end-point to connect to the remote end-point. This method is used only in the client side. Once the connection has been established the Send() and Receive() methods can be used for sending and receiving the data across the network. 

The Connected property defined inside the class Socket can be used for checking the connection. We can use the Connected property of the Socket class to know whether the current Socket instance is connected or not. A property value of true indicates that the current Socket instance is connected.

IPHostEntry IPHost = Dns.Resolve("www.c-sharpcorner.com");
Console.WriteLine(IPHost.HostName);
string []aliases = IPHost.Aliases;
IPAddress[] addr = IPHost.AddressList;
Console.WriteLine(addr[0]);
EndPoint ep = new IPEndPoint(addr[0],80);
Socket sock = new                             
Socket(AddressFamily.InterNetwork,SocketType.Stream,ProtocolType.Tcp);
sock.Connect(ep);
if(sock.Connected)
Console.WriteLine("OK");

The Send() method of the socket class can be used to send data to a connected remote socket.

public int Send (byte[] buffer, int size, SocketFlags flags)

Where byte[] parameter storing the data to send to the socket, size parameter containing the number of bytes to send across the network. The SocketFlags parameter can be a bitwise combination of any one of the following values defined in the System.Net.Sockets.SocketFlags enumerator.
        
SocketFlags.None
SocketFlags.DontRoute
SocketFlags.OutOfBnd 

The method Send() returns a System.Int32 containing the number of bytes send.Remember that there are other overloaded versions of Send() method as follows. 

public int Send (byte[] buffer,  SocketFlags flags)
public int Send (byte[] buffer)
public int Send (byte[] buffer,int offset, int size, SocketFlags flags) 

The Receive() method can be used to receive data from a socket.        

public int Receive(byte[] buffer, int size, SocketFlags flags) 

Where byte[] parameter storing the data to send to the socket, size parameter containing the number of bytes to send across the network. The SocketFlags parameter can be a bitwise combination of any one of the following values defined in the System.Net.Sockets.SocketFlags enumerator explained above. 

The overloaded versions of Receive() methods are shown below. 

public int Receive (byte[] buffer,  SocketFlags flags)
public int Receive (byte[] buffer)
public int Receive (byte[] buffer,int offset, int size, SocketFlags flags) 

When the communication across the sockets is over, the connection between the sockets can be terminated by invoking the method ShutDown() 

public void ShutDown(SocketShutdown how)

Where ‘how’ is one of the values defined in the SocketSHutdown enumeration. The value SoketShutdown.Send means that the socket on the other end of the connection is notified that the current instance would not send any more data.

The value SoketShutdown.Receive means that the socket on the other end of the connection is notified that the current instance will not receive any more data and the value SoketShutdown.Both means that both the action are not possible. 

Remember that the ShutDown() method must be called before the Close(0 method to ensure that all pending data is sent or received. 

A socket can be closed by invoking the method Close(). 

public void Close()

This method closes the current instance and releases all managed and un-managed resources allocated by the current instance. This method internally calls the Dispose() method with an argument of ‘true’ value, which frees both managed and un-managed resources used by the current instance. 

protected virtual void Dispose(bool)

The above method closes the current instance and releases the un-managed resources allocated by the current instance and exceptionally release the managed resources also. An argument value of ‘true’ releases both managed and un-managed resources and a value of ‘false’ releases only un-managed resources. 

The source code for a simple synchronous client by using the sockets is show below. The following program can send an HTTP request to a web server and can read the response from the web server. 

using System;
using System.Net;
using System.Net.Sockets;
using System.Text; 
class MyClient
{
           public static void Main()
           {
                       IPHostEntry IPHost = Dns.Resolve("www.google.com");
                       Console.WriteLine(IPHost.HostName);
                       string []aliases = IPHost.Aliases; 
                       IPAddress[] addr = IPHost.AddressList;
                       Console.WriteLine(addr[0]);
                       EndPoint ep = new IPEndPoint(addr[0],80); 
  Socket sock = new Socket(AddressFamily.InterNetwork,SocketType.Stream,ProtocolType.Tcp);
                       sock.Connect(ep);
                       if(sock.Connected)
                        Console.WriteLine("OK");
                       Encoding ASCII = Encoding.ASCII;
                       string Get = "GET / HTTP/1.1\r\nHost: " + "www. google.com" +
                       "\r\nConnection: Close\r\n\r\n";
                       Byte[] ByteGet = ASCII.GetBytes(Get);
                       Byte[] RecvBytes = new Byte[256];
                       sock.Send(ByteGet, ByteGet.Length, 0);
                       Int32 bytes = sock.Receive(RecvBytes, RecvBytes.Length, 0);
                       Console.WriteLine(bytes);
                       String strRetPage = null;
                       strRetPage = strRetPage + ASCII.GetString(RecvBytes, 0, bytes);
                       while (bytes > 0)
                       {
                                   bytes = sock.Receive(RecvBytes, RecvBytes.Length, 0);
                                   strRetPage = strRetPage + ASCII.GetString(RecvBytes, 0, bytes);
                                   Console.WriteLine(strRetPage );
                       }
                       sock.ShutDown(SocketShutdown.Both);
                       sock.Close();
           }
}

When building server based applications in C#, it is important to have the ability to create thread pools.  Thread pools allow our server to queue and perform work in the most efficient and scalable way possible.  Without thread pooling we are left with two options. 

The first option is to perform all of the work on a single thread.  The second option is to spawn a thread every time some piece of work needs to be done.  For this article, work is defined as an event that requires the processing of code.  Work may or may not be associated with data, and it is our job to process all of the work our server receives in the most efficient and fastest way possible.

As a general rule, if you can accomplish all of the work required with a single thread, then only use a single thread.   Having multiple threads performing work at the same time does not necessarily mean our application is getting more work done, or getting work done faster. This is true for many reasons. 

For example, if you spawn multiple threads which attempt to access the same resource bound to a synchronization object, like a monitor object, these threads will serialize and fall in line waiting for the resource to become available.  As each thread tries to access the resource, it has the potential to block, and wait for the thread that owns the resource to release the resource. 

At that point, these waiting threads are put to sleep, and not getting any work done.  In fact, these waiting threads have caused more work for the operating system to perform.  Now the operating system must task another thread to perform work, and then determine which thread, waiting for the resource, may access the resource next, once it becomes available. 

If the threads that need to perform work are sleeping, because they are waiting for the resource to become available, we have actually created a performance problem.  In this case it would be more efficient to queue up this work and have a single thread process the queue. 

Threads that start waiting for a resource before other threads, are not guaranteed to be given the resource first.  In diagram A, thread 1 requests access to the resource before thread 2, and thread 2 requests access to the resource before thread 3.  The operating system however decides to give the resource to thread 1 first, then thread 3, and then thread 2.  This scenario causes work to be performed in an undetermined order.  The possible issues are endless when dealing with multi-threaded applications.

If work received can be performed independent of each other, we could always spawn a thread for processing that piece of work.  The problem here is that an operating system like Windows has severe performance problems when a large number of threads are created or running at the same time, waiting to have access to the CPU. 

The Windows operating system needs to manage all of these threads, and compared to the UNIX operating system, it just doesn’t hold up.  If large amounts of work are issued to the server, this model will most likely cause the Windows operating system to become overloaded.  System performance will degrade drastically.<>

This article is a case study comparing thread performance between Windows NT and Solaris.

http://www.usenix.org/publications/libr ··· tta.html

In the .NET framework, the “System.Threading” namespace has a ThreadPool class.  Unfortunately, it is a static class and therefore our server can only have a single thread pool.  This isn’t the only issue.  The ThreadPool class does not allow us to set the concurrency level of the thread pool. 

The concurrency level is the most important setting when configuring a thread pool.  The concurrency level defines how many threads in the pool may be in an “active state” at the same time.  If we set this parameter correctly, we will have the most efficient, performance enhanced thread pool for the work being processed.

Imagine we have a thread pool with 4 threads and a concurrency level of 1. Then, three pieces of work are queued up for processing in the pool. Since the concurrency level for the thread pool is 1, only a single thread from the pool is activated and given work from the queue.  Even though there are two pieces of work queued up, no other threads are activated.  This is because the concurrency level is set to 1.  If the concurrency level was set to 2, then another thread would have been activated immediately and given work from the queue.  In diagram B we have thread 1 running and all of the other threads sleeping with two pieces of work queued.

So the question exists, why have more than 1 thread in the pool if the concurrency level is set to 1?  If thread 1 in diagram B ever goes to sleep before it completes its work, another thread from the pool will be activated.  When thread 1 goes to sleep, there are 0 threads “active” in the pool and it is ok to activate a new thread based on the concurrency level.  In diagram C, we now have thread 1 sleeping and thread 4 running with one piece of work queued.

Eventually, thread 1 will wake up, and it is possible for thread 4 to still be active.  We have 2 threads active in the pool, even though the concurrency level is set to 1.  In diagram D, we now have thread 1 and thread 4 running and one piece of work still queued.

The last piece of work in the queue will need to wait until both threads return to a sleeping state.  This is because the concurrency level is set to 1.  As we can see, even though the concurrency level restricts the number of active threads in the pool at any given time, we could have more active threads then the concurrency level allows.  It all depends on the state of the threads in the pool and how fast the threads can complete the work they are processing.

A good rule of thumb is to set the concurrency level to match the number of CPU’s in the system.  If the machine our server is running on only has one CPU, then only one thread can be executing at any given time. It will require a task swap to have another thread get CPU time.  We want to reduce the number of active threads at any given time to maximize performance.  This also leads to scalability.  As the number of CPU’s increase, we can increase the concurrency level because there is a CPU to execute that thread.  This is a general rule and is always a good starting point for configuring our thread pools.

The bottom line is, if the CPU is available, and there is work to perform, activate a thread.  If the CPU is not available, do not activate a thread.  One other thing, we need to be careful that we don’t cause a situation where the threads in the pool are constantly being put to sleep for long periods of time during the processing of work.  This may cause all of the threads in the pool to constantly be in an active state, defeating the efficiency of the pool and the performance of the server.

The remaining scope of this article will show you how to add IOCP thread pools to your C# server based applications.  How to configure the thread pools for your specific application will not be covered.  It is suggested to use the general rules as discussed.

This Win32 API call is used to create an IOCP thread pool.  The first argument will always be set to INVALID_HANDLE_VALUE, which is 0xFFFFFFFF.  This tells the operating system this IOCP thread pool is not linked to a device.  The second argument will always be set to 0. There is no existing IOCP thread pool because we are creating this for the first time.  The third argument will always be null.  IOCP Thread Pooling in C# - Part I - The Article
(Page 2 of 3 )

System Requirements

A basic understanding of C# is required to follow through the examples and the classes.  Basic concepts of type, properties, threading, synchronization, and delegates are required.

Defining the Problem

IOCP thread support has not been made available to C# developers through the “System.Threading” namespace.  We need to access the Win32 API calls from the Kernel32.dll.  This requires us to write unsafe code.  This is really not a problem, but something that needs to be discussed.  Let’s take a look at the Win32 API calls we need to implement an IOCP thread pool.

We do not require a key because we have not associated this IOCP thread pool with a device.  The last argument is the important argument.  Here we define the concurrency level of the thread pool.  If we pass a 0 for this argument the operating system will set the concurrency level to match the number of CPU’s in the machine. 

This option gives us our best chance to be scalable and take advantage of the number of CPU’s present in the machine.  This API call will return a handle to the newly created IOCP thread pool.  If the API call fails, it will return null.

[DllImport("Kernel32", CharSet=CharSet.Auto)]
private unsafe static extern Boolean CloseHandle(UInt32 hObject);

This Win32 API call is used to close our thread pool.  The only argument is the handle to the IOCP thread pool.  This API call will return TRUE or FALSE if the handle can not be closed.

[DllImport("Kernel32", CharSet=CharSet.Auto)]
private unsafe static extern Boolean PostQueuedCompletionStatus(UInt32 hCompletionPort, UInt32 uiSizeOfArgument, UInt32* puiUserArg, OVERLAPPED* pOverlapped);

This Win32 API call is used to post work in the IOCP thread pool queue. Other threads in our application will make this Win32 API call.  The first argument is the handle to the IOCP thread pool.  The second argument is the size of the data we are posting to the queue.  The third argument is a value or a reference to an object or data structure we are posting to the queue.  The last argument will always be null. The following diagram shows how the data is associated with the posted work.

In diagram E, we have two threads actively processing posted work and one piece of work on the queue waiting for its data to be processed.  The thing to note here is that each piece of work was given a reference to its specific data.  I am calling this variable pData to help describe what is happening in the IOCP thread pool.  The actual name or structure of this variable is undocumented.

When we make this API call in a C++ application, we can pass the address of any object in memory we wish, as in diagram E.  In C#, we don’t have the same luxury because of the managed heap.  The managed heap is a contiguous region of address space that contains all of the memory allocated for reference variables.  The heap maintains a pointer that indicates where the next object is to be allocated, and all allocations are contiguous from that point.  This is much different from the C-runtime heap. 

The C-runtime heap uses a link list of data structures to reference available memory blocks.  For the C-runtime heap to allocate memory, it must walk through the link list until a large enough block of free memory is found.  Then the free block of memory must be resized, and the link list adjusted. 

If objects are allocated consecutively in a C++ application, those objects could be allocated anywhere on the heap.  This can never happen with the managed heap.  Objects that are allocated consecutively in a C# application will always be allocated consecutively on the managed heap.  The catch is that the managed heap must be compacted to guarantee the heap does not run out of memory.  That is the job of garbage collection.

For more information on garbage collection, try these links:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconautomaticmemorymanagement.asp

http://msdn.microsoft.com/msdnmag/issues/1100/GCI/default.aspx

http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/default.aspx

pClass2 = null;

Diagram G shows what happens to the managed heap after garbage collection takes place and the managed heap is compacted.

The Class 2 object has been removed from the managed heap and the Class3 and Class 4 objects have been moved.  Now the value of pClass3 is FDDO and the value of pClass4 is FDCO.  The value that the pointer points to has changed.  The garbage collection process changes the values of all reference variables to make sure they are pointing to the correct objects after the managed heap is compacted.

So what does this mean for our IOCP thread pool implementation?  If we pass the reference of a managed object as the data for the work, there is a chance the reference is no longer valid when a thread in the pool is chosen to work on the data.

In diagram H, we have passed a reference to the Class 3 object as the data for the work posted to the IOCP thread pool.  This object is at address FDCO.  Before the work is given to thread 1, the Class 2 object is marked for deletion.  Then the garbage collection process runs, and the managed heap is compacted.  Now in diagram I, the work has been given to thread 1 for processing.  The value of pData is still FDCO, but Class 3 is no longer at address FDCO, it is at address FDDO.  The thread will perform the work, but using Class 4 instead of Class 3.

The garbage collection process can not change the value of pData, as it does with other variables, because this variable is not a managed variable.  It is a variable owned by the IOCP thread pool and exists outside the scope of the CLR.  The garbage collector has no knowledge of this variable or access to this variable.  The variable is set during the unsafe call to PostQueuedCompletionStatus.

Unfortunately, pinning the objects we want to pass as the data for the work posted to the IOCP thread pool is not a possible solution.  Pinning provides the ability to prevent an object from being moved on the manage heap during the garbage collection process.  We can not pin these objects because there is no way to pin an object in one thread and unpin the object in a different thread.  To pin an object, we need to use the fixed keyword.  This keyword can only be used in the context of a single method. Here is a quick example of pinning.

Int32 iArray = new Int32[5] {12, 34, 56, 78, 90};
unsafe
{
  fixed (Int32* piArray = iArray)
  {
   // Do Something
  }
}

The safest thing we can do is pass a value to the IOCP thread pool.  This value could be the index from a managed array, containing a reference to an object on the managed heap.   If the garbage collection process does compact the heap, the index values of the array will not change. In diagram J and K, we can see one way to properly pass data for the work posted to the IOCP thread pool.  After the garbage collection process compacts the heap, the values of pData change, but the index positions to the pData variables do not change.

[DllImport("Kernel32", CharSet=CharSet.Auto)]
private static extern Boolean GetQueuedCompletionStatus(UInt32 hCompletionPort, UInt32* pSizeOfArgument, UInt32* puiUserArg, OVERLAPPED** ppOverlapped, UInt32 uiMilliseconds);

The final Win32 API call is used to add threads to the IOCP thread pool. Any thread that makes this Win32 API call will become part of the IOCP thread pool.  This is a blocking call and the method will return when the IOCP thread pool chooses the thread to perform work. 

The first argument is the handle to the IOCP thread pool.  The second argument is the size of the data associated with the work.  This value was provided when the work was posted.  The third argument is the data value or data reference associated with the work.  This value was provided when the work was posted.  The forth argument is the address to a pointer of type OVERLAPPED. 

This address is returned after the call.  The last argument is the time in milliseconds the thread should wait to be activated to perform work. We will always pass INFINITE or 0xFFFFFFFF.

These are the Win32 API calls we need to add IOCP thread pool support to our C# server based applications.  We need to encapsulate these Win32 API calls using .NET threads and minimize the sections of unsafe code.  We need to prevent the application developer from passing a reference variable into the IOCP thread pool, by restricting them to passing only integer values.