Click here to Skip to main content
Click here to Skip to main content

Working with Sockets in C#

, 31 May 2013
Rate this:
Please Sign up or sign in to vote.
This article shows how to use sockets to send messages

Introduction

Sockets are getting more and more used nowadays. They provide a simple way to exchange data over the network. It's used, as an example, to exchange messages between users. You can go further more to transfer files and play "distributed" games and communicate multiple programs. Thanks to its powerful features, sockets are becoming a must to learn technology for developers.

As sockets are based on client/server architecture, this application is composed of a server and a client. The server will reserve a port number. Then it will listen to any upcoming client. The client then will attempt to connect to the server. When the connection succeeds, it will be possible to exchange text messages. When finished, the connection will be closed.

Using the code

To use sockets in .NET applications, we have to add the following using statements:

using System.Net; 
using System.Net.Sockets; 

Now we can create a socket object:

Socket sListener;    

Programming the server

Let's create a click event that will enable the created socket to set its IpEndPoint and the protocol type.

But before that, a socket needs permission to work, because it will use a closed port number. A window will appear demanding permission to allow sending data.

permission = new SocketPermission(NetworkAccess.Accept, 
                   TransportType.Tcp, "", SocketPermission.AllPorts);

As sockets use a network to transmit data, it uses protocols. The most known in this context are UDP which is fast but not reliable, and TCP which is reliable but not fast. Reliability is recommended when sending messages. That's why I use TCP.

sListener = new Socket(ipAddr.AddressFamily, SocketType.Stream, ProtocolType.Tcp); 

The socket needs to have an address. It's of type IpEndPoint. Each socket is identified through the IP address, which is useful to locate the host's machine, and the port number to identify which program is using the socket inside the machine.

IPHostEntry ipHost = Dns.GetHostEntry(""); 
IPAddress ipAddr = ipHost.AddressList[0]; 
ipEndPoint = new IPEndPoint(ipAddr, 4510);  

Now we will associate our socket with the IpEndPoint:

sListener.Bind(ipEndPoint);  

So that our socket is ready to use, let's start listening on the chosen port number (4510). You can choose another port number. But the client has to be aware about that. Listening will be handled through this button's event:

Place a socket in a listening state and specify how many client sockets could connect to it:

sListener.Listen(10); 

The server will begin an asynchronous operation to accept an attempt. One of the powerful features of sockets is the use of the asynchronous programming model. Thanks to it, our program can continue running while the socket is performing actions.

AsyncCallback aCallback = new AsyncCallback(AcceptCallback);
sListener.BeginAccept(aCallback, sListener); 

If there is any attempt from the client to connect, the following code will be executed:

Socket listener = (Socket)ar.AsyncState; 
Socket handler  = listener.EndAccept(ar);  

To begin to asynchronously receive data, we need an array of type Byte for the received data, the zero-based position in the buffer, and the number of bytes to receive.

handler.BeginReceive(buffer, 0, buffer.Length, 
          SocketFlags.None, new AsyncCallback(ReceiveCallback), obj); 

If the client sends any message, the server will try to get it. As sockets send data in binary type, converting  them to string type is necessary. It's good to know also that the server, and even the client, don't know anything about the length of the message or the time needed for listening to all of it. That's why we use a special string "<Client Quit>" to put in the end of the message to tell that the text message ends there. To receive data, BeginReceive is called:

byte[] buffernew = new byte[1024];
obj[0] = buffernew;
obj[1] = handler;
handler.BeginReceive(buffernew, 0, buffernew.Length, 
        SocketFlags.None, new AsyncCallback(ReceiveCallback), obj);  

After receiving the client's messages, the server may want to reply. But it has to convert the string message in str to bytes data, because sockets manipulate bytes only.

byte[] byteData = Encoding.Unicode.GetBytes(str);  

The server now will send data asynchronously to the connected socket:

handler.BeginSend(byteData, 0, byteData.Length, 0, new AsyncCallback(SendCallback), handler); 

When using the asynchronous programming model to build this sample, there's no risk of application or interface blocking. It will seem like we are using multiple threads.

After writing code, you want to handle the different methods through a user interface. So you may have a UI like this:

Programming the client

The client will try to connect to the server. But it has to know its address.

After creating a SocketPermission for socket access restrictions and creating a socket with a matching IpEndPoint, we have to establish a connection to the remote server host:

senderSock.Connect(ipEndPoint);

We have to note here that the created IpEndPoint will not be used to identify the client. But it'll be used to identify the server socket.

To send messages, the client adds "<Client Quit>" to mark the end of message and must transform the text message to binary format, as the server did. After that, the socket will send the message by invoking the method Send which will take the binary message as a parameter.

byte[] msg = Encoding.Unicode.GetBytes(theMessageToSend + "<Client Quit>"); 
int bytesSend = senderSock.Send(msg);    

For receiving data from the server, it converts the byte array to string and continues to read the data till data isn't available:

String theMessageToReceive = Encoding.Unicode.GetString(bytes, 0, bytesRec);
while (senderSock.Available > 0)
{
  bytesRec = senderSock.Receive(bytes);
  theMessageToReceive += Encoding.Unicode.GetString(bytes, 0, bytesRec);
} 

To close the connection, we should use Socket.Shutdown(SocketShutdown.Both) and Socket.Close().

After matching events with button's click, the client side user interface will look like this:

Conclusion

I provided here an application that is a sample to use and easy to integrate in your projects. So give yourself a chance to try taking benefit of socket's features to build a more rich and powerful software.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

Houssem Dellai
Student
Tunisia Tunisia
Studying Software Engineering in the National Engineering School of Sfax (ENIS), IEEE ENIS SB co chair of publicity, DotNet Enis Club manager, ImagineCup2012 competitor.
I like spending my free time developing open source .NET applications. I want to be an architect.
Mail : houssem.dellai@ieee.org
Phone : +216 95 325 964

Comments and Discussions

 
Questionsource code Pinmemberbehnam haji8-Jul-14 21:09 
QuestionClient in Windows, Server in Linux PinmemberThomhert Suprapto Siadari18-Aug-13 16:41 
AnswerRe: Client in Windows, Server in Linux Pinmemberwatsonsimler1-Jun-14 20:41 
QuestionClient stand by mode. PinmemberMeryem gömeç17-Jun-13 22:18 
GeneralMy vote of 5 PinmemberCornelius Henning1-Jun-13 1:30 
GeneralAwesome article PinmemberBarun Kumar Jha29-May-13 13:30 
QuestionMultiple messages Pinmemberzanatos12-Apr-13 5:41 
AnswerRe: Multiple messages PinmemberHoussem_Dellai12-Apr-13 23:55 
GeneralRe: Multiple messages Pinmemberzanatos14-Apr-13 6:19 
GeneralRe: Multiple messages PinmemberHoussem_Dellai14-Apr-13 7:28 
GeneralMy vote of 5 Pinmembercsharpbd3-Dec-12 0:53 
GeneralMy vote of 4 PinmemberAl-Samman Mahmoud2-Dec-12 1:19 
GeneralRe: My vote of 4 PinmemberHoussem Dellai2-Dec-12 5:13 
GeneralA good intro Pinmemberpt14011-Dec-12 19:41 
GeneralRe: A good intro PinmemberDellai Houssem1-Dec-12 22:21 
GeneralRe: A good intro [modified] Pinmemberpt14011-Dec-12 22:33 
QuestionA good article. PinmemberPHS24130-Nov-12 23:06 
AnswerRe: A good article. PinmemberHoussem Dellai1-Dec-12 2:30 
GeneralMy vote of 5 Pinmemberdavide-pro-99917-Oct-12 6:48 
SuggestionSuggested Reading PinmemberNick Hounsome24-Sep-12 21:04 
GeneralRe: Suggested Reading PinmemberHoussem Dellai25-Sep-12 6:26 
GeneralRe: Suggested Reading PinmemberIgor Ladnik2-Jun-13 0:08 
GeneralMy vote of 5 PinmemberUnque24-Sep-12 16:21 
Question[My vote of 2] Does not handle network splitting and joining PinmemberNick Hounsome24-Sep-12 2:49 
This has the bug common to a huge number of TCP programs. Fortunately (or unfortunately depending on your view point) it will almost always work for trivial demos especially if run on a single machine or a LAN but if sending sizable or rapid messages over a WAN or any messages to a heavily loaded receiver it will run into the problem that the number of bytes sent in a call to "Send" by a client bears no defined relationship whatsoever to the number received in each call to "Receive" by the receiver.
The code partially acknowledges this with the looping call in the client but it is still wrong on a number of counts:
 
1) The client send can be split over several packets AND NEED NOT BE SPLIT ON AN EVEN BYTE BOUNDARY. When we consider that we are sending UTF16 (Unicode encoding) we must consider that we might receive only the first half of a character. In this case the decode routine will throw an exception.
 
2) !socket.Available only tells you that no more data is available now NOT that there never will be any more data.
 
Bomb proof TCP programming is hard. Using asynchronous I/O as well is VERY hard to get right.
 
In practice the only good way to handle TCP streams is to have messages with a well defined header containing a length. You should then read bytes until you have at least a header full; calculate how many more you need given the length and then keep reading until you have accumulated the entire message into a buffer. Only then should you analyze the message itself.
 
It is possible to make some simplifications in the client if the stream is closed by the sender as in this case the end of stream (signified by reading 0 bytes) can be used in place of a length but the multi-byte char problem still stands.
 
The program as it stands makes no real use of TCP and would probably be better implemented in UDP where Send and Receive match 1 to 1.
AnswerRe: [My vote of 2] Does not handle network splitting and joining PinmemberHoussem Dellai24-Sep-12 19:27 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web03 | 2.8.140709.1 | Last Updated 31 May 2013
Article Copyright 2012 by Houssem Dellai
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid