Architecture - How it works
The architecture for XSockets.NET is simple yet powerful. Everything is a module that can be overwritten. Below we will walk through each part of the architecture briefly. This is just an overview and not all modules are covered in here.
Different clients have different capabilities, browsers for example have the RFC6455 (WebSockets) protocol implemented, but other devices might talk a protocol that you have created. Since XSockets allows cross-protocol communication all connected clients can communicate with each other very easily.
Currently we have clients for:
- C# .NET 4.5+
- iOS - Xamarin
- Android - Xamarin
- .NET Micro Framework
Each configuration module added will become an individual endpoint when the server starts. This means that clients can connect to separate endpoints but still communicate with each other cross endpoints. This is very useful if you have different security levels on the endpoints. For example, you might have sensors behind a firewall that does not need, or can have, TLS/SSL. Then you might have monitoring clients, such as browsers, native apps etc., connecting on a public endpoint using TLS/SSL. This way all the public traffic is secure even though the sensors producing data does not use TLS/SSL.
If needed you can create custom transports and add the transport to an endpoint. This is useful, for example, when you connect clients that can’t use certificates but you still need security. By implementing a custom transport you can choose your own encrypting/decrypting mechanism such as symmetric encryption or TLS-PSK etc.
Since the protocols are modules you can add as many protocols as you like. It may sound like a hard or complex task to write protocols, and it can be. The complexity of your protocol is totally up to you. However, protocols in XSockets only require a few things.
- Check if the handshake sent from the client matches the protocol.
- Convert incoming data to the internal IMessage format.
- Convert outgoing data to the format the client expects.
It is this simple logic that enables cross-protocol communication. When a connection is established the protocol will invoke the Authentication Module. This module is, of course, re-writable so that you can authenticate the user in any way you see fit.
A controller is where the developer will write the business logic. This is no different than a regular back-end, except from the fact that you can send targeted messages to any client connected. When a connection is established each client can communicate over n controllers. So you can multiplex over several controllers on one connection. So this architecture enables communication cross-protocol as well as cross-controller.
XSockets has a lot of features that speed up development and makes things easier.
- Offline queues - Enables clients that is currently offline to get messages when they reconnect
- Persistent properties - Will repopulate the state, properties on the controller, when a client reconnects
- A key/value storage that let you persist data and get it back later
All these features are modules, and you can overwrite the default modules with your own. For example, we have written a few demos where we store both properties and key/values on Azure Storage Table.
XSockets can be hosted pretty much anywhere. It does not have any dependencies to a specific OS-version, or any WebServer (such as IIS) etc. As long as the machine has Mono or .NET installed you are good to go. This means that you have many, many options when it comes to hosting. A few of the options are listed below.
- Azure Worker Role
- Azure WebSite
- Service (TopShelf is recomended)
For enterprise solutions there is of course the possibility to scale out. The scaling module, that can be replaced with a custom module, scales via sockets (P2P) by default. However, a very popular scale out option is to use Azure Service Bus. We have templates ready for you so that you can add Azure Scale Out in a few minutes .