TechDoc: Moving towards multi-purpose Socket Servers

Posted on July 10, 2011

0


Introduction

The HotForestGreen base design started with Standard type Sockets. As support of as many different platforms (HTML, Flash, Java, Android, Windows, Mac, Linux) as possible is a requirement WebSockets were on the list for a long time.

I started implementing them in the past days: the first week of July, 2011.

Based on some online sources like the jWebsocket article and the code in the WebSockets server by Bert Mortheamer  I was able to build a specific handler.

Multi-purpose server

As Sockets are the base objects for all communication, and protocols are what are added, I moved away from Protocol Specific Servers: which was the second incarnation of my code after refactoring.

Mutation of Class Structure

Below you will find the mutation of the Class Structure to support the new directions. Each phase took at least one refactoring, breaking the entire project until it was fully implemented.

Original setup

As we only had one type of Socket, the structure was simple.

Original Class Structure to handle Client Sockets

WebSockets are not the same as Standard Sockets

Web Sockets implement a different protocol and a specific handshake, based on HTPP. This means that we need to extend the Standard Socket and also have to find a way to direct the incoming Socket to the correct handler.

Strategy – Introducing different type of Sockets

So we need to choose which we will use. In the Class Structure as shown below, the main assumption was that we would tell the Server what kind of Sockets it would support. Based on that it would choose the Socket Type from a Lookup Table and instantiate that specific Socket Type to deal with the incoming data and Socket Type related protocols.

Second implementation: Strategy to chosse specific Socket Type

Socket Handlers – Making the model more flexible

What I did not like about the second model, implemented on a Saturday, was the rigid nature. Each SocketServer would only serve a specific type of Sockets, making mixing of Socket Types harder to do.

After starting the implementation of a specific connection of type: Bi-Directional Gateway, I decided to do a third refactoring: moving towards Socket Handlers instead of Socket Types.

Using Socket Handlers instead of Socket Types

The difference is how the Socket Encapsulation is done.

  1. Socket Types: decision before reading the content – With Socket Types, I have to decide beforehand which Class I instantiate. Only then I will start the process of receiving data.
  2. Socket Handlers: first read content, then decide how to handle it – With the Socket Handlers, I first start receiving data (the Header) and based on what I find inside that Header, I will instantiate a Handler which will deal with Socket Type Specific protocols.

Encapsulation and the ISocket Interface

To serve specific Socket Types, we need to cater specific communication protocols. The protocol to encapsulate data, as used in the Standard Type Socket is different form a Web Socket. Still, the basic activities we want to perform remain the same.

These actions are:

  1. Send and receive Messages – Which are (should be) always formatted the same way, containing a header for the Server and a message Body to be processed by the receiving Client.
  2. Check if the Socket is still connected – Of which the method might vary per Socket Type, but the outcome is always the same: “yes” or “no”
  3. Start and stop the Socket – Including its disconnection
  4. Auto-connect the Socket when connection is broken – Done via the Socket Handler

Benefits and results – simpler model, more options

  1. It does not matter anymore what Type of  Socket is connecting –  WebSocket, HTML http request, Standard Socket, your own protocol: if we recognize it, we will assign a specific Handler to it to deal with
  2. Any Type of Socket can communicate data to any other Type of Socket – As long as they are in the same Scope, defined by the Port and SandBox
  3. The Class Structure stays simple while options grow – Very important. There is not just one way to do things and not just one technology to get it done.
  4. It is easier to expand the model with new (your own) Socket Types – Using injection. See: “Creating and adding new Socket Types”

Creating and adding new Socket Types

Using the ISocket interface, you can add any Type of Socket to the collection of existing Sockets.

What you need is the following:

  1. A Socket Type Identifier – This is for internal use.
  2. The implementation of ISocket – As the Socket Handler expects a specific standardized Interface, it will expect you to implement and use that specific contract.
  3. A Header Validator – Which is a public method in your Class. The Header Validator is used by the Socket Handler to verify if the Header is specific to a Socket Type.

Socket Type Auto Detection

For each Socket Connection, the header will be verified against the different Socket Type Handlers, using a public method.

If the validation process returns a “true” then that Socket Type Handler is the one to be used.

Allowing fox mixed Socket Types on one single port

Instead of separating Socket Types per port (as is usual for HTPP, FTP and Socket type connections) we want to allow any Socket Type to be able to connect. In the end they all are Base Sockets and in the end they all connect because they need the data flowing within one or more Application Clusters.

These are the reasons:

  1. The method is less important than the purpose – The purpose is to exchange data between Clients. As these Clients can include HTML pages with Web Sockets, and more standard protocols might be added, we should accept any protocol IF we can recognize it.

Plug and Play – Extending the model with a HTPP handler

Now that we have a Plug and Play type of model, where we inject Handlers into the Framework, we can start expanding it. One of the next modules is to handle standard HTTP requests.

This allows for the Servers to offer a web page and web site, allowing for a very simple low-effort way to build Remote Controls for public use.

Web Based Remote Controls

Web Based Remote Controls are small web sites, offering you the tools to communicate with an Application Cluster using a simple Web Browser.

The standards I am thinking of using for Web Based Remote Controls are those:

  1. HTML – Allowing for a broader support and the lack of need for a specific plugin or compiler (Flash, Java). Might not work on all browsers. Specifically when WebSockets are used but not supported.
    1. WebSockets – For real time interactions via JavaScript
    2. HTTP calls – When your browser does not allow for more complex stuff including Web Sockets. This will be implemented in the second phase of the Simple Web Browser Implementation in the Framework.
    3. Intercepted calls in a custom browser – When you can deploy a application for general use which includes a Web Browser that intercepts calls of specific types, like: “socketcall:<your call to the HotForestGreen Application Cluster>”
  2. Flash – allowing for a more stable platform and browser independent implementation. Might not run on all systems (old Android phones, specific tablets, Mac iOS)
    1. Normal Sockets – As supported by flash
    2. Web Sockets – When normal Sockets are blocked due to their (lack of) protocol

 

Advertisements
Posted in: techdoc