Overview

In the "Tux Services" section, the description of the Tux Daemon shows a global view of the Tux Droid software and emphasizes on the links of Tux Daemon with others services and with applications. The purpose of this section is to provide a detailed architecture of the Tux Daemon and to explain the reasons of our choices.

Tux Droid Daemon Architecture

As described in "Tux Droid Services", Tux Daemon suffers from major limitations.

• An application must manage multiples TCP/IP connections to control the Tux Droid system: one for driving the Tux hardware; one per software resource used by application. Interfacing Tux Droid would be easier if the application controls the full set of hardware and software resources through a single TCP/IP client connected to Tux Droid Daemon.

• There is no intelligent policy to allocate Tux Droid for applications requests: the daemon TCP/IP facility serves requests in their arrival order (FIFO). It would be useful to configure applications priorities according to user preferences: for example, if you are listening to an internet radio, you would like Tux Droid to let you know when someone is calling you with Ekiga or when you receive an e-mail ...
  

• Communicating with people through Tux Droid will imply to drive more than one Tux Droid simultaneously: it could be one local and many remote Tux Droids or simply many local Tux Droids. Anyway, the final Tux Daemon architecture must support this feature to pretend to be convenient.

To circumvent these limitations we isolate the following rules of thumbs that guide architecture choices of Tux Daemon:

1. Extensibility: Tux Daemon would be able to manage any number of Tux Droids
   
2. Configuration: global configuration of application priorities for Tux Droids control is required
3. Unity of connection: an application must control Tux's hard and soft resources through a single connection
4. Transparency : driving a local or a remote Tux Droid must be transparent for an application

Extensibility and Configuration

To ensure the "configuration" and the "extensibility" properties, the Tux Droid Daemon is built around a unique "master daemon" and multiple instantiations of one "subdaemon" module.

• The "master daemon" is in charge of the configuration. It controls data routing of the links between applications and Tux Droid. It provides information about the Tux Daemon configuration: an application can receive the port address to connect a Tux Droid. It instantiates a new subdaemon when requested by an application or when a Tux is plugged into the USB. The configuration of the Tux Droid Daemon would be defined by a specific user-friendly configuration application.

• a "subdaemon" manages one connection to Tux Droid. Subdaemons are dynamically created (instantiated) for each Tux Droid controlled by the computer.

The Master Daemon instantiates a new subdaemon dedicated to this Tux when a new Tux is plugged in the USB port, or when an application requests it. To setup a connection with a new subdaemon, an application will first communicate directly with the master daemon which provides all necessary information for the subdaemon connection.

Unity of Connection

• to control one Tux Droid
  
• to control resources services
• to get information about the configuration
  

through a single channel. Data will be routed by the subdaemon to their destination. References of the channel (port number, ...) will be forwarded by the master daemon when setting up the subdaemon.

Communication with the subdaemon takes place through four channels:

• the Applications Channel supporting data exchange with applications; the subdaemon is in charge of routing data to the right destination.
  
• the Resources Channel supporting connections between resources and the subdaemon
  
• the Tux Channel supporting data exchange with a local or remote Tux Droid
  
• the Master Channel supporting configuration data exchange with the Master daemon.The Master Daemon configures the routing features of the subdaemon through this channel.

This property of the Tux Daemon will simplify connection management in the applications: the counterpart is that messages sent by applications will include extra routing information such as the message destination. Routing features must be implemented in the subdaemon; they are managed by the master daemon.

Transparency: adding a Tux Daemon Transport Layer

In order to abstract the communication through Tux Daemon, a transport layer has been added. This layer mainly uses a TCP/IP module for communication; meanwhile

• it uses a propriety (open) protocol module based on libusb for local the Tux Droid link.
• it uses a DBUS module for direct communication with existing applications using DBUS as API
• New Transport Modules could be added when needed
  

The data layer is responsible of simple data processing. As an example, the data processing module of the Tux Droid channel aggregates status coming from the USB to build a complete state of Tux. More information can be found in the source code of the Tux Droid Daemon.

The routing layer sends data to the destination channel ensuring the priority rules set through the master daemon.

Application Channel Message Structure

The Application Channel messages are 16 bytes long and are structured in three fields:

• The Destination Header is composed of
  
•  a "Destination" byte defining the destination channel
• a "Sub-destination" byte indicating the Tux Droid Identifier
• The Data Header is composed of
  
•  a "Data Type" byte defining the type of data message (control, request, answer,..)
• a "Sub data type" byte defining the type of control sent (raw command, structured command, status data, information,...)
  
• Data composed of 12 bytes of data

Resource Channel Message structure

Under construction

Master Channel Message structure

Under construction

Tux Channel Message structure

Under construction