Architecture

The Social Interaction Cloud has been developed under this main guiding principle:

• There are multiple users, each with their own Devices, that want to connect to our cloud to obtain certain Services whilst running their own applications (using one of the Connectors).

Note that a technical ‘user’ as used here (someone who uses SIC to run an application) should not be confused with an ‘end-user’ (someone who interacts with such an application). As there is no definite cloud node in place at this time (though initial tests have been succesfully completed), we support Local Installation of SIC. The entire framework is open-source and available at: https://bitbucket.org/socialroboticshub/workspace/projects/SIC .

Internal workings

The main ‘node' of SIC is a Redis server. Redis is a high-performance data store that can be used as a database, cache, and message broker. It has built-in support for replication, persistance and access control.

Although making use of the database features as well, SIC mainly relies on Redis' Pub/Sub messaging system. Using the publish-subscribe pattern brings great benefits in terms of decoupling and scalability. Although there are multiple message brokers out there, Redis is extremely fast and readily supports binary data (e.g. video and audio streams), making it very suitable in a social interaction context, especially in combination with the database-oriented features. We also make use of Redis' built-in SSL support to automatically encrypt everything (note: on local installations this uses insecure auto-generated certificates).

A message is always published on a channel. A typical channel in our system will look something like this:

• default-14F6D86621CD_events

Here, default is the name of the user, 14F6D86621CD is the unique identifier of the device, and events is the relevant topic. The user corresponds to a pre-registered Redis user (on local installations the default admin is used), which will only have permission for operations on keys and/or messages starting with their unique username, thus ‘automatically’ isolating users. The device identifier is auto-generated and stored in a sorted set that contains all the users' devices indexed by last time at which they were alive; each device is expected to update this each minute (i.e. auto-register), and is considered to be ‘gone’ otherwise. The final ‘topic-part’ of the channel is up to the specific device and/or service, and is thus used to separate all the different information streams. The libraries and connectors provided for devices, services and applications therefore also allow abstracting away from the user/device details and operating on the topics only.

Each service, which is considered part of the SIC framework (unlike e.g. external applications for which you need a connector), is actually a ‘service factory’. These factories wait for devices to send their identifier to a dedicated non-user-specific channel, e.g. intent_detection, at which point the actual service is launched for that device. Locally services run in their own Docker container, but in the cloud such a factory could run on its own node, and perhaps even spawn the individual services on separate nodes as well.

Services, devices and connectors (and thus applications) can be programmed in any programming language, as long there is a Redis client available for it. Currently, however, shared SIC-specific libraries for such implementations are only provided in Java and Python (see e.g. here and here).