Personal tools
 
Document Actions

Daemon-API protocol

by Rémi Jocaille — last modified 2007-03-14 16:02

Protocol between the daemon and the python API

1. Principle



The aim of the communication protocol between " Tuxdaemon " and the python API is to be making a transparent link for an easy access to the tuxdroid system. The communication is assumed by a tcp socket server on the daemon, and a tcp socket client on the API.
In the tuxdroid software topology, The daemon is the routing element between the different elements (Ressources daemons, USB dongle, clients). For the moment, the routing philosophy is not completely implemented in the daemon, but the protocol is constructed in this spirit.

Tuxdroid software topology










Tuxdroid software topology


2. Session

2.1. Typical flowchart

Typical flowchart of the daemon-api protocol

































2.1.1 API open a session
The API sends a request of connection to the daemon with a tcp socket at port 5000. When the daemon receives this request, the socket of API is added in the clients list.
2.1.2. API sends a frame
When the API sends a frame to daemon, the frame is processed in the tree of dispatching. The daemon sends an ack for informing the API of the status of tree processing. If this ack is a valid value, the API stands to receiving a response frame from the daemon.
2.1.3. Daemon sends a frame
When the daemon sends a frame to API sessions, it’s not required to responding each time. No acknowledge is needed here, the tcp/ip socket ensures this part of quality of service.
2.1.4. API close the session
When the API wants to be disconnected, she alerts the daemon of her intention. When the daemon receives this information, he removes the socket of this API from the clients list.
2.1.5. Daemon is killed
When the daemon is killed, he sends a alert to all API clients. On reception of this message, the API closes the socket linked at tcp server of the daemon.

3. Frame encapsulation

3.1. Layers

The transactions from the daemon to the API and from the API to the daemon uses a defined frame structure. The frame is 16 bytes of length. The frames have two levels of encapsulation.

Level 1: Routing layer. It’s the source/destination encapsulation of the frame.
Level 2: Data layer. It’s the data encapsulation

Layers of the protocol between tuxdaemon and the API
















3.2. Routing layer (level 1)

The routing layer contains 2 bytes of header and 14 bytes of data.

3.2.1. Routing header
The routing header can have 2 two types of address:
- Destination address
or
- Source address
For example, when the API sends a frame to the daemon, the routing header contains the address of the destination element. When de API receives a frame sent by the daemon, the routing header contains the address of the sender.
3.2.1.1. Destination address
Destination address is divided in two parts:
- Destination : Main element to access
- Sub destination : Sub element to access
Possible values of <destination> :
DEST_MASTER_DAEMON	0x00		: Not used
DEST_SUB_DAEMON		0x01		: To daemon
DEST_TUX		0x02		: To tuxdroid USB dongle
DEST_RESOURCE		0x03		: To resource daemon (NI)
DEST_CLIENT		0x04		: To API client (NI)

Possible values of <sub destination> :

SD_DEFAULT		0x00		: First sub element
SD_ALL			0xFF		: Broadcast
			0x01-0xFE 	: Explicit sub element

3.2.1.1. Source address

Source address is divided in two parts:
- Source : Main element which sent the frame
- Sub source : Sub element which sent the frame

Possible values of <source> :

SOURCE_MASTER_DAEMON	0x00		: Not used
SOURCE_SUB_DAEMON	0x01		: From daemon
SOURCE_TUX		0x02		: From tuxdroid USB dongle
SOURCE_RESOURCE		0x03		: From resource daemon (NI)
SOURCE_CLIENT		0x04		: From API client (NI)

Possible values of <sub source> :

SS_DEFAULT		0x00		: First sub element
			0x01-0xFE	: Explicit sub element

3.2.1. Routing data

The routing data contains the 14 bytes of the Data layer

3.3. Data layer (Level 2)

The data layer contains 2 bytes of header and 12 bytes of data.

3.3.1. Data header
The data header contains the type of the data to be sent.
The data type is divided in two parts:
- Data type
- Data sub type
3.3.1.1. Data type

Possible values of <data type> :
DATA_TP_CMD		0x01		: Main type is "command"
DATA_TP_REQ		0x02		: Main type is "request"
DATA_TP_RSP		0x03		: Main type is "response"
DATA_TP_ACK_CMD		0x04		: Main type is "command acknowledge"
DATA_TP_ACK_DP		0x05		: Main type is 
					  "data processing acknowledge"

3.3.1.2. Data sub type

Possible values of <data sub type> :

SUBDATA_TP_RAW		0x01		: Sub type is "raw"
SUBDATA_TP_STRUCT	0x02		: Sub type is "structured"
SUBDATA_TP_STATUS	0x03		: Sub type is "status"
SUBDATA_TP_INFO		0x04		: Sub type is "information"
3.3.2. Data data

(See the section 4)

4. Signification of the data part of the data layer

The signification of the data part of the data layer depends of the 2 layers header. All combinations of values in the headers don't be judicious, or are not used for the moment. Therefore, the list of data combination below is not exhaustive.

4.1. Client is the sender


4.1.1. Client to deamon

Sending a structured command :


DESTINATION SUB DESTINATION
 DATA TYPE
 DATA SUB TYPE
DEST_SUB_DAEMON SS_DEFAULT DATA_TP_CMD SUBDATA_TP_STRUCT
DATA[0]
 DATA[1] DATA[2] DATA[3]
SUB_D_CMD_STRUCT_DISCONNECT_CLIENT
 <Client id>
 /
 /
SUB_D_CMD_STRUCT_KILL_DAEMON
 /
 /
 /
SUB_D_CMD_STRUCT_DISCONNECT_ME
 /
 /
 

SUB_D_CMD_STRUCT_DISCONNECT_CLIENT	0x01
SUB_D_CMD_STRUCT_KILL_DAEMON		0x02
SUB_D_CMD_STRUCT_DISCONNECT_ME		0x04

Sending a information request :

DESTINATION SUB DESTINATION
 DATA TYPE
 DATA SUB TYPE
DEST_SUB_DAEMON SS_DEFAULT DATA_TP_REQ SUBDATA_TP_INFO
DATA[0] DATA[1] DATA[2] DATA[3]
SUB_D_REQ_INFO_VERSION
 /
 /
 /
SUB_D_REQ_INFO_CLIENT_COUNT /
 /
 /
SUB_D_REQ_INFO_MY_CLIENT_ID /
 /
 /
 
SUB_D_REQ_INFO_VERSION			0x01
SUB_D_REQ_INFO_CLIENT_COUNT		0x02
SUB_D_REQ_INFO_MY_CLIENT_ID		0x04


4.1.2. Client to Tux dongle


Sending a raw command :

DESTINATION SUB DESTINATION
 DATA TYPE
 DATA SUB TYPE
DEST_TUX <Tux dongle number> DATA_TP_CMD SUBDATA_TP_RAW
DATA[0] DATA[1] DATA[2] DATA[3]
(See command.h)
 (See command.h) (See command.h) (See command.h)


Sending a structured command :

DESTINATION SUB DESTINATION
 DATA TYPE
 DATA SUB TYPE
DEST_TUX SS_DEFAULT DATA_TP_CMD SUBDATA_TP_STRUCT
DATA[0] DATA[1] DATA[2] DATA[3] DATA[4]
TUX_CMD_STRUCT_EYES TUX_CMD_STRUCT_SUB_ON
 <number>
 /
 /
TUX_CMD_STRUCT_EYES TUX_CMD_STRUCT_SUB_OFF / /
 /
TUX_CMD_STRUCT_MOUTH TUX_CMD_STRUCT_SUB_ON <number> /
 /
TUX_CMD_STRUCT_MOUTH TUX_CMD_STRUCT_SUB_OFF /
 /
 /
TUX_CMD_STRUCT_WINGS TUX_CMD_STRUCT_SUB_ON <number> /
 /
TUX_CMD_STRUCT_WINGS TUX_CMD_STRUCT_SUB_OFF /
 /
 /
TUX_CMD_STRUCT_SPINL TUX_CMD_STRUCT_SUB_ON <number> /
 /
TUX_CMD_STRUCT_SPINL TUX_CMD_STRUCT_SUB_OFF /
 /
 /
TUX_CMD_STRUCT_SPINR TUX_CMD_STRUCT_SUB_ON <number> /
 /
TUX_CMD_STRUCT_SPINR TUX_CMD_STRUCT_SUB_OFF /
 /
 /
TUX_CMD_STRUCT_IR TUX_CMD_STRUCT_SUB_ON /
 /
 /
TUX_CMD_STRUCT_IR TUX_CMD_STRUCT_SUB_OFF /
 /
 /
TUX_CMD_STRUCT_IR TUX_CMD_STRUCT_SUB_SEND <address> <command>
 /
TUX_CMD_STRUCT_LEDS TUX_CMD_STRUCT_SUB_ON <number> /
 /
TUX_CMD_STRUCT_LEDS TUX_CMD_STRUCT_SUB_OFF /
 /
 /
TUX_CMD_STRUCT_LEDS TUX_CMD_STRUCT_SUB_BLINK <number>
 <delay>
 /
TUX_CMD_STRUCT_LEDL TUX_CMD_STRUCT_SUB_ON <number> /
 /
TUX_CMD_STRUCT_LEDL TUX_CMD_STRUCT_SUB_OFF /
 /
 /
TUX_CMD_STRUCT_LEDR TUX_CMD_STRUCT_SUB_ON <number> /
 /
TUX_CMD_STRUCT_LEDR TUX_CMD_STRUCT_SUB_OFF /
 /
 /
TUX_CMD_STRUCT_SOUND
 TUX_CMD_STRUCT_SUB_PLAY <index>
 <volume>
 /
TUX_CMD_STRUCT_SOUND TUX_CMD_STRUCT_SUB_STORING <number>
 /
 /
TUX_CMD_STRUCT_SOUND TUX_CMD_STRUCT_SUB_STORE_INDEX <high address>
 <middle address>
 <low address>
TUX_CMD_STRUCT_SOUND TUX_CMD_STRUCT_SUB_TEST /
 /
 /
TUX_CMD_STRUCT_PING /
 <number>
 /
 /
TUX_CMD_STRUCT_SLEEP TUX_CMD_STRUCT_SUB_ON /
 /
 /
TUX_CMD_STRUCT_SLEEP TUX_CMD_STRUCT_SUB_OFF /
 /
 /
TUX_CMD_STRUCT_AUDIO
_CHANNEL
 TUX_CMD_STRUCT_SUB_CH_GENERAL /
 /
 /
TUX_CMD_STRUCT_AUDIO
_CHANNEL		 TUX_CMD_STRUCT_SUB_CH_TTS /
 /
 /
 
TUX_CMD_STRUCT_EYES		0x01
TUX_CMD_STRUCT_MOUTH		0x02
TUX_CMD_STRUCT_WINGS		0x03
TUX_CMD_STRUCT_SPINL		0x04
TUX_CMD_STRUCT_SPINR		0x05
TUX_CMD_STRUCT_IR		0x06
TUX_CMD_STRUCT_LEDS		0x07
TUX_CMD_STRUCT_LEDL		0x08
TUX_CMD_STRUCT_LEDR		0x09
TUX_CMD_STRUCT_SOUND		0x0A
TUX_CMD_STRUCT_PING		0x0B
TUX_CMD_STRUCT_SLEEP		0x0C
TUX_CMD_STRUCT_AUDIO_CHANNEL	0x0D
TUX_CMD_STRUCT_SUB_ON		0x01
TUX_CMD_STRUCT_SUB_OFF		0x02
TUX_CMD_STRUCT_SUB_SEND		0x04
TUX_CMD_STRUCT_SUB_PLAY		0x05
TUX_CMD_STRUCT_SUB_STORING	0x06
TUX_CMD_STRUCT_SUB_STORE_INDEX	0x07
TUX_CMD_STRUCT_SUB_TEST		0x08
TUX_CMD_STRUCT_SUB_BLINK	0x09
TUX_CMD_STRUCT_SUB_CH_GENERAL	0x0A
TUX_CMD_STRUCT_SUB_CH_TTS	0x0B

Sending a status request :

DESTINATION SUB DESTINATION DATA TYPE
 DATA SUB TYPE
DEST_TUX SS_DEFAULT DATA_TP_REQ SUBDATA_TP_STATUS
DATA[0]


DATAS_STATUS_WINGS_MOTOR_BACKWARD


DATAS_STATUS_SPIN_MOTOR_FORWARD


DATAS_STATUS_SPIN_MOTOR_FORWARD


DATAS_STATUS_MOUTH_OPEN_POSITION


DATAS_STATUS_MOUTH_CLOSED_POSITION


DATAS_STATUS_HEAD_PUSH_POSITION


DATAS_STATUS_CHARGER_INHIBIT_SIGNAL


DATAS_STATUS_WINGS_POSITION_SWITCH


DATAS_STATUS_MOTOR_FOR_WINGS


DATAS_STATUS_LEFT_BLUE_LED


DATAS_STATUS_HEAD_MOTOR_FOR_MOUTH


DATAS_STATUS_HEAD_MOTOR_FOR_EYES


DATAS_STATUS_SPIN_POSITION_SWITCH


DATAS_STATUS_WINGS_MOTOR_FORWARD


DATAS_STATUS_IR_LED


DATAS_STATUS_EYES_OPEN_POSITION_SWITCH


DATAS_STATUS_EYES_CLOSED_POSITION_SWITCH


DATAS_STATUS_LEFT_WING_PUSH


DATAS_STATUS_RIGHT_WING_PUSH


DATAS_STATUS_POWER_PLUG_SWITCH


DATAS_STATUS_HEAD_PUSH_SWITCH


DATAS_STATUS_CHARGER_LED_STATUS


DATAS_STATUS_MUTE_STATUS


DATAS_STATUS_LIGHT_LEVEL


DATAS_STATUS_EYES_POSITION_COUNTER


DATAS_STATUS_MOUTH_POSITION_COUNTER


DATAS_STATUS_WINGS_POSITION_COUNTER


DATAS_STATUS_SPIN_POSITION_COUNT


DATAS_STATUS_RIGHT_BLUE_LED


DATAS_STATUS_RF_CONNECTED


DATAS_STATUS_SOUND_COUNT 


DATAS_STATUS_WINGS_MOTOR_BACKWARD		0x01
DATAS_STATUS_SPIN_MOTOR_BACKWARD		0x02
DATAS_STATUS_SPIN_MOTOR_FORWARD			0x03
DATAS_STATUS_MOUTH_OPEN_POSITION		0x04
DATAS_STATUS_MOUTH_CLOSED_POSITION		0x05
DATAS_STATUS_HEAD_PUSH_POSITION			0x06
DATAS_STATUS_CHARGER_INHIBIT_SIGNAL		0x07
DATAS_STATUS_WINGS_POSITION_SWITCH		0x08
DATAS_STATUS_MOTOR_FOR_WINGS			0x09
DATAS_STATUS_LEFT_BLUE_LED			0x0A
DATAS_STATUS_HEAD_MOTOR_FOR_MOUTH		0x0D
DATAS_STATUS_HEAD_MOTOR_FOR_EYES		0x0E
DATAS_STATUS_SPIN_POSITION_SWITCH		0x10
DATAS_STATUS_WINGS_MOTOR_FORWARD		0x11
DATAS_STATUS_IR_LED				0x12
DATAS_STATUS_EYES_OPEN_POSITION_SWITCH		0x13
DATAS_STATUS_EYES_CLOSED_POSITION_SWITCH	0x14
DATAS_STATUS_LEFT_WING_PUSH			0x15
DATAS_STATUS_RIGHT_WING_PUSH			0x16
DATAS_STATUS_POWER_PLUG_SWITCH			0x17
DATAS_STATUS_HEAD_PUSH_SWITCH			0x18
DATAS_STATUS_CHARGER_LED_STATUS			0x19
DATAS_STATUS_MUTE_STATUS			0x1A
DATAS_STATUS_LIGHT_LEVEL			0x1B
DATAS_STATUS_EYES_POSITION_COUNTER		0x1C
DATAS_STATUS_MOUTH_POSITION_COUNTER		0x1D
DATAS_STATUS_WINGS_POSITION_COUNTER		0x1E
DATAS_STATUS_SPIN_POSITION_COUNTER		0x1F
DATAS_STATUS_RIGHT_BLUE_LED			0x20
DATAS_STATUS_RF_CONNECTED			0x21
DATAS_STATUS_SOUND_COUNT			0x23
You are here: Home → Members → remi → Documentation → Daemon-API protocol
Powered by Plone CMS, the Open Source Content Management System