We’re hoping to have Syntrino as part of the first open source release of Syntro. It will include the SyntrinoLib library that will handle all of the Syntro-related networking and present an easy to use API to the top level sketch. In addition, there’ll be a demo application to show just how easy it is to write sketches that can leverage the power of a Syntro cloud.

One of the really cool features of Syntro is that it’s possible to pick up a stream from a Syntro cloud, do some fancy processing on it and then make it available to other Syntro apps. The screen shot shows this in action. An app called SyntroVideoFilter is picking up a couple of video streams, performing a Canny edge detect function on both and then passing the results back as two new video streams. The viewer displays the raw and processed streams side by side. In a real application, SyntroStore could be storing any or all of these video streams for later review via the SyntroCFS Cloud File Storage system. The very nice thing is that, even with OpenCV code, there are only about 40 lines of code that had to be written for the client class.

This is a very simple example that demonstrates some of the capabilities of a Syntro Lightweight Compute Cloud. In this case, it was a simple flow:

<data source> -> <SyntroControl> -> <filter> -> <SyntroControl> -> <viewer>

This could easily be extended to have more filters in series, more filters in parallel (all obtaining their streams from the same data source) or indeed a combined serial and parallel set of filters. And of course, these filters can be distributed over many processors or geographical distances (depending on delay tolerance in the latter case).

There’s nothing stopping a filter from receiving multiple streams or generating multiple output streams from one input stream if that makes sense. Also, this happens to be a video demonstration but the Syntro infrastructure is agnostic – data is data – so the filter apps could be operating on any or multiple types of data. Only the producer, filter and consumer apps need to understand the data at some level.

The screenshot shows SyntroControl running on an iMac with Mac OS X 10.7. Thanks to Qt, getting it running on the iMac was pretty painless! The remaining apps will follow very quickly now. This will bring Mac OS X up to a fully supported platform along with Linux (currently being tested on Ubuntu) and Windows.

We’re working on an interesting idea about how to combine SyntroControl with Ethernet switches and routers – Syntro-enabled network devices. First though a bit of background on what SyntroControl does.

SyntroControl is a core Syntro component that performs two main functions – message switching and distributed directory management. A key design principle of Syntro is that each Syntro app only has to maintain a single connection into the Syntro network. Contrast this with something like ROS for example. ROS implements a centralized directory but components set up direct links between themselves as necessary. This certainly avoids having messages go through a single switch component but also has some disadvantages. There’s nothing to help components out with loading so each component may have to replicate messages for multiple clients and multicast. It also makes the data flows in the network hard to visualize (although there are tools to assist with that).

In the Syntro architecture, each Syntro app maintains a single link to its designated SyntroControl. There may be many SyntroControls in a Syntro system and apps can be configured to use specific ones (to optimize traffic flows) or just pick one at random. SyntroControls implement a distributed directory system so that Syntro apps can look up published services by just asking their SyntroControl. To communicate with other components, Syntro apps can send and receive End To End (E2E) messages or send and receive multicast messages.

SyntroControl plays a key part in the multicast architecture by ensuring that data duplication is done in an optimal way. Unusually, Syntro was designed with multicast as a critically important transport mechanism – usually multicast is an afterthought!

Now we can get back to considering the location of SyntroControls. Generally, the server PCs in a Syntro system will each run a copy of SyntroControl and indeed many of the peripheral devices too if that makes sense for data flow reasons. SyntroControl is actually very efficient on CPU utilization so this makes sense.

While this message switching architecture (technically connectionless over connection-orientated networking) has many desirable features, it’s true that every message has to go through at least one SyntroControl. That means that the shortest path between two Syntro apps is two SyntroLink (what we call the links between Syntro apps and SyntroControl) hops. If you think about it though, most networks are built using switches and routers. Suppose the switches and routers had a copy of SyntroControl built-in? This would effectively eliminate the extra hop and make this architecture a perfect match for the underlying switched Ethernet or routed IP architecture at the same time. SyntroControl functionality is an excellent match for the hardware within switches and routers and so it’d be reasonable to expect very good performance even from low-cost devices.

The bottom line is this – by embedding SyntroControl instances in the network, a Syntro system can get all of the advantages of the connectionless overlay network concept without any of the disadvantages.

For example, Syntro’s intelligent multicast distribution system allows large number of client apps to monitor a subset or all of a large number of media streams (audio, video etc) in real-time and at high data rates but does not allow for a “DVR-like” capability where it’s possible to pause a stream, go back to an arbitrary point in history, replay at a different rate etc. SyntroCFS adds that capability.

There are two parts to the SyntroCFS implementation. SyntroStore is a Syntro core app that monitors multicast streams and stores them to disks. SyntroStore also publishes a SyntroCFS End To End (E2E) service via the SyntroControl distributed directory system. SyntroLib, the basis of every Syntro application, contains within it the SyntroCFS client API that allows easy access to the SyntroCFS service offered by any or all of the SyntroStores in a Syntro system. The SyntroCFS API allows full random access to the historical records previously saved for each stream while at the same time providing an alternate mechanism for receiving streams in real-time. To use the DVR analogy, if a stream is a video stream, the SyntroCFS API allows for real-time play, pause, rewind, reverse, high-speed forward and reverse, etc.

SyntroCFS is an enabling technology for some of the key functions of Syntro - the managing, mining, manipulation and presentation of data in all its forms that has been and is being collected by the system. The SyntroCFS API offered by SyntroLib gives Syntro app developers a straightforward way to access its very powerful capabilities.

Syntro is currently being supported on both Windows and Linux (we test on Ubuntu) and support on MAC OS will hopefully follow very soon.

To give a sense of how Syntro might be used, consider the case where a large number of surveillance cameras are generating video and audio feeds, perhaps over a very large area. All of these data feeds need to be stored for future data mining. A monitoring center needs access to all of the feeds on demand in real-time, as do remotely located staff using tablets or smartphones. At the same time, sophisticated processing of the feeds is taking place in both real-time and on historic records, perhaps to track an interesting object backwards in time. Tools are provided for users to access the processed information in the same way as the real-time feeds.

Syntro provides all of the infrastructure to make this happen and can cost-effectively scale from just a few cameras and users to thousands of cameras and users just by adding more computing resources.

Another example of use would be to coordinate the actions of multiple autonomous mobile robots. Each robot becomes part of the Syntro LCC and allows flexible allocation of computing resources and easy access to data from anywhere else in the system to assist with coordination. Sensors on the robots act as sources of data into the Syntro system allowing real-time monitoring by controllers at the same time as autonomous intelligence is processing the information and sending out commands to the robots based on sensor information and task goals. For example, a group of autonomous Unmanned Aerial Vehicles (UAVs) could utilize Syntro to simplify the collection of sensor streams, provide the control intelligence and then command coordinated actions.

These are just two examples of how the power of Syntro can be leveraged in real application scenarios. Future posts will delve deeper into the underlying technology and talk more about real applications.