Update: June 19 – Getting a grip on all things considered

Summary

In the past week I worked on the security model and getting the SandBox creation model straight.

In the past days I refactored the auto connect mechanism as a consequence. I also found some bugs in the code for Remote Objects written in the current prototype code for Phase 1.

Next steps

In the next weeks I will:

1. Finalize the Security layer, part of Phase 2
2. Test, debug and clean up the prototype code for Phase 1 and 2.
3. Test and debug the framework with some basic applications

The goal is to have something demo-able before August.

Finalizing Database access and working with databases is moved – for now – after getting the basic framework running and tested to satisfaction.

Older Status Updates

• June 1: Prototype code for first phase of HotForestGreen almost done, implementing authentication
• June 13: First round trip successful
• June 19: This post

What is this Framework about?

I am building an “Internet of Things” / Distributed Applications framework called “HotForestGreen”. The basics of this Framework are:

1. Simplicity – Why have complex libraries doing very advanced stuff and still not solving your main issues when you can have it all and can keep it stupid simple?
2. Simplification - To simplify building Distributed Applications.
3. Hot plugging – To allow hot-plugging and dropping out of Servers
4. Scalability – To provide maximum scalability
5. Security -To provide maximum security within Application Cluster with mimimal effort

Distributed Applications

A brief definition of Distributed Applications:

Software that executes on two or more computers in a network.

See also more here.

Revised auto connect mechanism

When a Client wants to connect to a SandBox, it needs to connect to a Server and the Server needs to provide the IP number of the Server in the Cluster that serves that SandBox.

From a complex spaghetti-wired process, moving in all directions I simplified that to a “per sandbox process”.

Here is the new process:

1. Each Sandbox has a heartbeat.
2. The heartbeat has a default delay of 5 seconds.
3. On each beat, the Sandbox checks if all Server Connections are OK
4. If a connection within a specific IP range is down, it will start scanning the network to find a new Server Connection

Each Server Connection has its own hearbeat as well. The default delay for a connection is 1 second. Here is the process per Server Connection

1. On each heartbeat, the Server Connection checks if it is still connected
2. If the connection is down, it will notify the Sandbox it is part of: to do a rescan.

Old rules

1. A Sandbox has to be created after a Server is available
2. If there is no Server available, the Sandbox will fail to initialize

New rules

1. A Sandbox can be created before any Server is up
2. On each heartbeat it will check each IP range for an active connection
3. If there is an active connection on an IP range, it will skip and go to the next range to scan
4. If there is no active Server Connection the Sandbox will scan that IP range to discover any Server

New: Implemented Server/Client System of Trust

In the past days I have been working on the Server to Server commuinication. This communication includes a lot of information you do not want to share to Hijackers.

To make sure Servers can communicate safely without unwanted eavesdroppers, I started to implement a Security Layer.

See the full TechDoc article here.

Rules of the security system 

1. Security can be done on Server and SandBox level
1. Servers can be set to only allow Trusted Clients
2. Sandboxes can be set to be Trusted – meaning that only other Verified Trusted SandBox Connections can send and receive data within that Trusted Sphere
2. Security is done on a system of establishing Mutual Trust between Client and Server
3. If one of both parties does not trust the other, it will disconnect the Socket

The Server has extra mechanisms built in to avoid Eavesdropping by injecting a Sandbox that pretends to be Secured.

1. Each Trusted Sandbox will receive a flag from the Server stating that it is Verified and Trusted
2. Any injected Public SandBox pretending to be Trusted, will be killed by the Trusted SandBoxes

Update on roadmap

Phase 1: Building the basis – In progress per May 4, 2011

Before June 10, 2011 I hope to finish Phase 1, which covers the basics on data, data conversion and Client/Server and Client/Client messaging. This includes:

1. Remote Objects – Sending and updating Remote Objects to all Remote clients
1. Status: June 19, 2011
1. Basis is tested last week. Found some bugs in retrieving persistant objects, leading to creation of news ones instead of retrieving the old
2. Need to be retested. Will be done in the next 2 weeks.
2. Server feedback – Including IP numbers of Servers serving specific sandboxes
1. Status: June 19, 2011
1. Tested and in revision now. Refactored to make the message in standard BaseMessage format. Will do more refactoring today to revise the process of: “knock knock, who’s there?”
3. Heartbeats and auto-reconnect – Including auto-discovery of services and sandboxes and auto-reconnects when a Client connection drops or a Server drops out
1. Status: June 19, 2011
1. Revised to be independent of Servers running. To be tested in a Server Cluster.
4. User Authentication – Including a basic “plug and play” scenario for logging into SandBoxes and assuring messages sent from a Client are “signed” by the user Credentials
1. Status: June 19, 2011
1. No further progress
5. Data manipulation – Using a “plug and play” approach via: “Transparant Data Access Layers” to access, change and store data in databases
1. Status: June 19, 2011
1. Tested first version three weeks ago. To be revisited after finalizing items 1 to 4.
6. Data Conversion – Including the conversions of Objects to “Comma Separated Values” vice versa, in order to:
1. Send updates – On Remote Objects through the network
2. Reduce code for working with Databases – As we can inject data from databases into objects and database records

When these main items are done, I can release the code and start building some proof of concepts, showing the possibilities of the framework.

Phase 2: Securing the framework – Started per June 16

Phase 2 is about making the Framework more solid and more protected against people who want to hijack data and events.

1. Server to Server updates – Including: “I am currently serving Sandboxes A, B and C with a total of N connections”
1. Status: June 19, 2011
1. Started implementation of Secured SandBoxes to make this possible and simple
2. Implemented Server Sate Manifest as a Remote Object that contains the data per Server and automatically updates all other Servers when the state on that Server changes
2. Load Balancing – Including a smart distribution of Sandboxes so that the load to serve Clients is shared by many
1. Status: June 19, 2011
1. Implemented, not tested yet. When a Client requests an IP number, the Client Socket will provide the IP of the Server that is least loaded.
3. Server to Server security – Using handshakes and shared keys. Assuring that when a user plugs in a “Server” to intercept messages and sandboxes, this “Server” is refused by the network
1. Status: June 19, 2011
1. Work in progress. Servers now build up a Secured SandBox using the exact same mechanism as Clients, with the difference that they use an internal Shared Keyword to test if they can Trust the other Server
4. SSL encryption – Currently all data sent is in Clear Text, making it extremely easy to hijack and abuse the system
1. Status: June 19, 2011
1. Not started yet

When these items are done, the Framework can withstand most basic attacks, can be scaled up by hot-plugging new Servers in the network and will continue to work even when multiple servers drop out.

Phase 3: Opening up the framework – Not started yet

While the basis is for specific use in a controlled environment, some things are missing to make the framework even more useful. These include:

1. The use of Web-sockets – For Socket-communication over port 80 in environments behind firewalls
2. Porting the code from C# to Java and ActionScript – To provide a broader use base, allowing you to run the framework on:
1.  Android, Apple, Linux and in Flash
2. Intel and ARM-based devices

Other possibly needed ports I will leave up to the community that will hopefully emerge. I simply do not have the time.

Phase 4: Testing and cleaning up – Not started yet

In Phase 4 all crap and remaining leaks will be filtered out of the system. During phase 2, most issues have been tested and addressed, but as a part of the process.

The work includes:

1. Testing specific use-cases for performance - By running as much connections and messages as possible, until the system collapses
2. Testing possible ways to hijack users and data – By scrutinizing the security model and implementing code that should break it
3. Improving performance – By taking away data-hogs and

Tagged: Distributed computing, Distributed Systems, Internet of Things, Internet Of Things Framework

Posted in: update