Tasted

From TASTE
Jump to: navigation, search

Overview

tasted is a TASTE daemon designed to ease the execution of generated applications. Once system designers have successfully built their systems, they can automatically execute them on boards. As the TASTE toolset can produce applications for systems with different architectures and requirements, it is sometimes difficult to deploy them altogether. The TASTE daemon aims at facilitate this deployment and execution step. The TASTE daemon runs on a machine (potentially the same machine as the host development) and listens for incoming requests.


Location on the SVN repository: https://tecsw.estec.esa.int/svn/taste/trunk/tasted

Features

  • Execute applications remotely
  • Build binaries of a project
  • Generate AADL dataview
  • Generate skeletons
  • Handle the components library

License

Released under GPL license.

Dependencies

Protocol

The protocol works more or less as the FTP protocol: you have one connection to exchange control data (XML-based notation) and another to exchange binary data (project archive or data being produce during the execution of a program). It exchanges data on top of the TCP stack (for both the control data and the pure data). The control data are exchanged on a fixed port while data are exchanged on a port allocated for each request. This is explained in the protocol definition and its illustration below.


There are two main message types:

  1. request, sent from the client to tasted
  2. answer sent from tasted to the client

Request types are the following:

  • generate-skels
  • generate-dataview-aadl
  • build
  • getgmonout
  • exec
  • exit

Answer are the following:

  • sendbin
  • gmonok
  • gmonko
  • execerror
  • generate-skels-result
  • generate-dataview-aadl-result
  • build-result
  • send-archive


Getting ASN.1 AADL dataview

The client first issues a request to send the archive containing the project. Then, tasted replies with a new archive with the updated project.

<request type="generate-dataview-aadl"/>

Then, the server answers with the following message:

<answer type="send-archive">
   <option name="port" value="PORTVAL"/>
</answer>

Then, the client has to initiate a socket to the server on port PORTVAL.

Once the project archive is sent, the server generates the AADL Data view and replies using this message:

<answer type="generate-dataview-aadl-result" status="ok">
</answer>

In case there is an error, the following message is then sent:

<answer type="generate-dataview-aadl-result" status="ko">
   <option name="code" value="ERRCODE"/>
   <option name="message" value="ERRMSG"/>
</answer>

In that case, code and message are optional.

In case the project archive could not be sent, the following message is sent:

<answer type="send_error">
   <option name="code" value="ERRCODE"/>
   <option name="message" value="ERRMSG"/>
</answer>

In that case, code and message are optional.

Example

This is an example of the messages being exchanged between the client and the server:

<request type="generate-dataview-aadl"/>
<answer type="send-archive"><option name="port" value="5680"/></answer>

In the meantime, the client sends the project through a socket in port 5680 and receives on the same socket the updated project if successful.

<answer type="generate-dataview-aadl-result" status="ok"/>

This protocol is illustrated in the following picture :

Protocol for the Generation of the AADL dataview

Generating skeletons

The client first issues a request to send the archive containing the project. Then, tasted replies with a new archive containing the code skeletons.

<request type="generate-skels"/>

Then, the server answers with the following message:

<answer type="send-archive">
   <option name="port" value="PORTVAL"/>
</answer>

Then, the client has to initiate a socket to the server on port PORTVAL.

Once the project archive is sent, the server generates the skeletons, populates the archive with them and replies using this message:

<answer type="generate-skels-result" status="ok">
</answer>

In case there is an error, the following message is sent:

<answer type="generate-skels-result" status="ko">
   <option name="code" value="ERRCODE"/>
   <option name="message" value="ERRMSG"/>
</answer>

In that case, code and message are optional.

In case the project archive could not be sent, the following message is sent:

<answer type="send_error">
   <option name="code" value="ERRCODE"/>
   <option name="message" value="ERRMSG"/>
</answer>

In that case, code and message are optional.

Building binaries

The client first issues a request to send the archive containing the project. Then, tasted replies with a new archive containing the binaries.

<request type="build"/>

Then, the server answers with the following message:

<answer type="send-archive">
   <option name="port" value="PORTVAL"/>
</answer>

Then, the client has to initiate a socket to the server on port PORTVAL.

Once the project archive is sent, the server generates the binaries, populates the archive with them and replies using this message:

<answer type="build-result" status="ok">
</answer>

In case there is an error, the following message is sent:

<answer type="build-result" status="ko">
   <option name="code" value="ERRCODE"/>
   <option name="message" value="ERRMSG"/>
</answer>

In that case, code and message are optional.

In case the project archive could not be sent, the following message is sent:

<answer type="send_error">
   <option name="code" value="ERRCODE"/>
   <option name="message" value="ERRMSG"/>
</answer>

In that case, code and message are optional.

Execute Binaries

This protocol is illustrated in the following picture :

Protocol for the execution of binaries


Testing tasted

You can test tasted using netcat. The idea is the following:

  1. You start tasted on the command line
  2. You connect on the server using netcat using a first TCP connection (connection 1)
  3. You send the archive if required using netcat using a second connection (connection 2)

The result would be the XML input/output on connection 1 and projects files on connection 2.

There is an example of a session of debugging to get the AADL dataview for a project.

  1. On one shell session, start tasted, like this:
     ./tasted
    
  2. On another session, connect to the server (we assume the server is running on port 5678)
    telnet localhost 5678
    
    and type the following command:
    <request type="generate-dataview-aadl"/>
    
    . Then, the server answer something like:
    <answer type="send-archive"><option name="port" value="5680"/></answer>
    
    .
  3. Send the binary on the port specified by the server (here 5680, see previous answer from the server):
    cat project.taste|nc localhost 5680
    
    . Then, you should receive the updated project by the network (the standard output of netcat) amd the terminal executing telnet should receive an XML answer like:
    <answer type="generate-dataview-aadl-result" status="ok"/>
    
    . Also, you can send the archive and store the new archive using the following command-line:
    cat project.taste|nc localhost 5680 > newarchive
    
    . This would store the updated archive in the file newarchive.

Installation from sources

assert@assertvm:~/tool-src/tasted$ PREFIX=whereveryouwanttoinstall
  • Install
assert@assertvm:~/tool-src/tasted$ make && make install