Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
home articles quick answers discussions features community help Search for articles, questions, tips
Introduces a couple of cover classes to provide event-driven interaction with TCP/IP sockets and simple message protocols
Introduction
Sockets are an important part of the modern programmer's armory. To read this article, you are making extensive use of sockets – the article itself, and each image,
come down a socket to your machine, and perhaps two, if you're reading this at work, behind a router. Communicating with other machines lets you spread
computationally expensive tasks, share data and so on. Yet the Framework doesn't provide as good a toolkit as it does for, for example, Windows Forms (unless you
are doing something 'standard' like making HTTP requests). If someone sends me some data, or connects to my server, I want an event to be thrown, just like if
someone presses a button on my form.
There are also problems with networks, and specifically with TCP. Connections can be lost at any time, so an OnDisconnect event would be nice so that we can
take appropriate action if this happens. (The appropriate action varies from a message box to cleaning up information stored on a server about the client who
disappeared.) What I send as one message can arrive as several, or vice versa; while TCP guarantees that data arrives in the right order (if it arrives at all), it has no
concept of individual messages.
I have written a small assembly which provides event-driven client-server communication over TCP (using the tools provided in System.Net.Sockets). It also
specifies a simple message-based protocol so that you can keep your messages together, although you don't have to use it.
Creating a client socket with ordinary .NET functions is slightly messy, so I provide a cover. And once you have the socket, you need to create an instance of
ClientInfo to get event-driven access to the data.
Hide Copy Code
class SimpleClient{
ClientInfo client;
void Start(){
Socket sock = Sockets.CreateTCPSocket("www.myserver.com", 2345);
client = new ClientInfo(sock, false); // Don't start receiving yet
client.OnReadBytes += new ConnectionReadBytes(ReadData);
client.BeginReceive();
}
Et voilà, you can receive data! (Assuming you have a server that sends you some, of course.) To send text data, use client.Send("text"). ClientInfo
exposes the socket it is using, so to send binary data, use client.Socket.Send().
Messaged Communication
Receiving data with OnReadBytes doesn't guarantee your messages arrive in one piece, though. ClientInfo provides two ways to keep messages together,
one suitable for simplistic text messaging and one suitable for arbitrary message-based communication.
Text Messages
Often, being able to pass text with a suitable end marker, often a new line, is all we need in an application. Similar things can then be done with data received like
this as with command strings. To do this, assign a handler to the OnRead event:
class TextClient{
ClientInfo client;
void Start(){
Socket sock = Sockets.CreateTCPSocket("www.myserver.com", 2345);
client = new ClientInfo(sock, false); // Don't start receiving yet
client.OnRead += new ConnectionRead(ReadData);
client.Delimiter = '\n'; // this is the default, shown for illustration
client.BeginReceive();
}
Now, any data received will be interpreted as text (UTF8 text, to be precise), and ReadData() will be called whenever a newline is found. Note that if the data is
not text (and is not valid UTF8), invalid characters will be replaced with '?' – so don't use this method unless you know you are always handling text.
Binary Messages
For more advanced applications, you may want to pass a byte stream (which can represent anything), but still keep the message together. This is typically done by
sending the length first, and ClientInfo does the same thing. To use this protocol, you need to put the client into a messaged mode and use
OnReadMessage():
Hide Copy Code
class MessageClient{
ClientInfo client;
void Start(){
Socket sock = Sockets.CreateTCPSocket("www.myserver.com", 2345);
client = new ClientInfo(sock, false); // Don't start receiving yet
client.MessageMode = MessageMode.Length;
client.OnReadMessage += new ConnectionRead(ReadData);
client.BeginReceive();
}
In the current version, a 4-byte length parameter is sent before the data (big-endian); for example, a message containing the word "Bob" would have the byte form
00 00 00 03 42(B) 6F(o) 62(b). Obviously, the other end of the connection needs to be using the same protocol! You can send messages, in the same
format, using client.SendMessage(code, bytes).
By now, you're probably wondering what that uint code is all about. As well as MessageType.Length, there is also a
MessageType.CodeAndLength which lets you specify a 4-byte code to be sent with each message. (It is sent before the length.) The event handler in this
type of an application will typically be something like:
If I were to send the message "Bob" with the tag 0x12345678, its byte stream would be 12 34 56 78 00 00 00 03 42 6F 62.
Being a Server
As well as receiving and sending information (just like a client), a server has to keep track of who is connected to it. It is also useful to be able to broadcast
messages, that is send them to every client currently connected (for example, a message indicating the server is about to be taken down for maintenance).
Below is a simple server class which simply 'bounces' messages back where they came from, unless they start with '!' in which case it broadcasts them.
class SimpleServer{
Server server;
ClientInfo client;
void Start(){
server = new Server(2345, new ClientEvent(ClientConnect));
}
As you can see, the Connect handler is passed a ClientInfo, which you can treat in the same way as a client (assign the appropriate OnReadXxx handler and
MessageType). You can also reject a connection by returning false from Connect. In addition to Broadcast(), there is a BroadcastMessage() if
you are using messaged communication.
ClientInfos are assigned an ID when they are created, controlled by the static NextID property. They will be unique within a running application unless you
reset NextID at any time after creating one. A server application will often want to keep track of a client's transactions. You can do this in two ways:
1. There is a Data property of ClientInfo, to which you can assign any data you like. The data is maintained until the ClientInfo is disposed of
(guaranteed to be after the connection dies).
2. You can use the value of client.ID as the key in a Hashtable or similar. If you do that, you should supply a Disconnect handler:
Hide Copy Code
void ConnectionClosed(ClientInfo ci){
myHashtable.Remove(ci.ID);
}
Encryption
This library includes the ability to protect a socket, using the encryption algorithm I wrote about here. This can be turned on by passing a value for encryptionType
in the ClientInfo constructor or setting the EncryptionType property before calling BeginReceive, and setting the DefaultEncryptionType
property on the server:
There are three encryption modes supported. The first, None, performs no encryption, and is the default. EncryptionType.ServerKey means that the
server sends a symmetric key for the connection when the client first connects; because the key is sent unencrypted, this is not very secure, but it does mean that
the communication is not in plain text. The most secure method is ServerRSAClientKey: the server will send an RSA public key upon connection, and the
client will generate a symmetric key and encrypt it with the RSA key before sending it to the server. This means the key is never visible to a third party and the
connection is quite secure; to access the message you would need to break the encryption algorithm.
If you choose to use encrypted sockets, very little is different in your application code. However, in your server, you should respond to the ClientReady event,
not ClientConnect, in most cases. ClientReady is called when key exchange is complete and a client is ready to send and receive data; attempting to send data
to a client before this event will result in an exception. Similarly, if you want to send data through an encrypted client socket, you should respond to the OnReady
event or check the EncryptionReady property before sending data.
History
December 2005: Initial version posted
April 2008: Updated with version 1.4, supporting encryption, multi-character delimiters and sending byte arrays
November 2011: Updated with version 1.6, including the ability to synchronise events to a UI control
License
This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)
Share
I'm a recent graduate (MSci) from the University of Cambridge, no longer studying Geology. Programming is a hobby so I
get to write all the cool things and not all the boring things . However I now have a job in which I have to do a bit of
work with a computer too.
Comments and Discussions
Search Comments
Very useful intro. Could you help me with a specific need? Member 4291906 23-Nov-17 3:02
Re: Client side Send("text") is not received by server Istvan D. 28-Jun-17 4:03
(problem) packet length goes crazy after some intense messaging exchange ernest_hemingway077 3-Jul-14 0:53
Re: Love the library so far, but I cannot get the test classes working. BobJanova 23-Jul-13 8:12
Re: Love the library so far, but I cannot get the test classes working. somedudecalledchris 23-Jul-13 22:20
How do I know that receiving long msg interrupted? Tamas24 30-Mar-13 5:23
Re: How do I know that receiving long msg interrupted? BobJanova 30-Mar-13 11:18
Last Visit: 7-Jan-20 20:54 Last Update: 7-Jan-20 20:54 Refresh 1 2 3 4 5 6 7 Next »
General News Suggestion Question Bug Answer Joke Praise Rant Admin
Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.