Eric lippert - Amazon Web Services

Real-time network
applications in the past
using .NET
There are multiple ways to solve different scenarios regarding
real-time systems using .NET. You might have found yourself
using raw sockets to have full control over everything you do. The
biggest problem is that if you are creating a real-time application
using .NET and rely on sockets to help you, you most likely write a
nice wrapper or library that you can use.
As with anything else, this ends up in lots and lots of different
libraries to solve real-time systems over sockets. There’s certainly
nothing wrong with going down on the lowest possible layer,
but sometimes abstractions can reduce complexity and speed up
development.
Next up, we need to connect to this server and to do this, we have
the following code.
var client = new Socket(SocketType.Stream, ProtocolType.
Tcp);
client.Connect(new IPEndPoint(IPAddress.
Parse(“127.0.0.1”), 3425));
var buffer = new byte[1024];
while (true)
{
Console.WriteLine(“Connected to server!”);
client.Receive(buffer);
Console.WriteLine(Encoding.Default.GetString(buffer));
}
As you might have noticed, there are a couple of problems with
the server and the client. First of all, the buffer is big and we don’t
handle data sent which is more than 1024 bytes. This would need
to be fixed if this was a real world application. Writing up all this
boilerplate code for a real-time application, can be cumbersome
and we tend to do the same thing over and over again. The next
step when we have a client and a server, is to come up with a
“protocol” to use and now I am not talking about the
actually DTOs that are sent, but in what way they are sent.
If you want to handle disconnects, reconnects and broadcasts,
you’ll first and foremost need a basic list of all connected and
possibly disconnected clients as you can see above. There’s
absolutely nothing wrong with this, but so far we’ve just started
to talk about the most basic things. Imagine what this adds up to
once the real-time system grows.
Next up, you need a unified language that all your clients and
servers use, so that you can ensure that each entry point gets what
they should.
The following code shows how to create a basic server that listens
on TCP for clients to connect and once they connect, it simply
sends a message to the client greeting it.
var socket = new Socket(SocketType.Stream, ProtocolType.
Tcp);
socket.Bind(new IPEndPoint(IPAddress.Parse(“127.0.0.1”),
3425));
socket.Listen(5000);
while (true)
{
var client = socket.Accept();
Console.WriteLine(“Client connected!”);
client.Send(Encoding.Default.GetBytes(“Hello!”));
}
This all adds up and in the end you will end up with something
that someone else has also written lots of times before. Therefore
it is now time to present the solution of repetitive boilerplate for
near real-time communication between Client and Server – a.k.a.
SignalR.
Creating real-time network
applications with SignalR
SignalR is a real-time network library that has an awesome and
well-engineered abstraction over sockets. Instead of having to
write all the socket code yourself, you use SignalR to fire up a
server which is as simple as saying the port number out loud,
a couple of times. Then you have very useful features that will
let you direct messages to one client, multiple clients or to just
broadcast the entire message.
In SignalR, you have abstractions that will even help you to do
things even more magically. This actually means that there is a
“raw” way for working with SignalR and there’s a more easy way to
work with clients and the server.
SignalR has fall back mechanisms built in on different protocols
and technologies. For instance, if you set up a server, and the
client only has support for long polling; that is what is going to be
used.
DNcmagazine www.dotnetcurry.com | 15