Re: tasksing and TCP sockets

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 30 Jan 2006 14:12:51 -0800, Rolf wrote:

> Consider an application that communicates with its environment via
> sensors and actors. For testing purposes the low level access to the
> sensor and actor data gets replaced by a TCP socket communication whose
> other end simulates the world, i.e. the world simulation continuously
> writes sensor data to the socket and accepts commands as actor data.
> 
>   +-----------------------+
>   |                       |
>   | application           |
>   |                       |
>   +-----------------------+
>   |    h/w abstraction    |
>   |  sensors  |  actors   |
>   +-----------------------+
>              |
>          TCP client
>              |
>              |
>              |
>   TCP server that simulates the world

This architecture is called "middleware." In a more elaborated form it
looks like:

Application1 ... ApplicationN
   | (application API)
Middleware [state variables to access]
   | (driver API)
Hardware abstraction layer [middleware-"drivers"]
   |                          |
Network protocol      |
   |                          |
TCP/IP based layer   Hardware registers
   |                          |
Ethernet                A/D converter

BTW, in general it is not a 2-tier architecture, so client-server approach
might appear difficult.

> In a stripped down version I can succesfully connect to the server
> (using GNAT.Sockets) and either read the sensor data *or* write actor
> data.

Middleware usually provides a bit more. You will also need some
synchronization mechanisms [any hardware has limited speed], different
publishing/subscribing policies for periodic and event-controlled data etc.

> The program is currently split in two tasks. One tasks contains
> the application code and the actor communication (using
> type_id'output(channel)). The second tasks gets started during program
> initialisation. It reads the data from the socket via
> type_id'input(channel) and provides the data to the application through
> a protected object.

It is a design problem. I would factor out the middleware kernel first.
Note that there is no logical difference between Ethernet TCP/IP and A/D
converter. Both are devices for the middleware. The very purpose of
middleware is to hide any difference from the application.

> My questions:
>  - is that a reasonable tasking approach?

You might need one task per device to decouple application from the
middleware. When an I/O is started on a middleware variable, the
application task just continues to the time point where it says: now I need
the result.

>  - I don't know much about sockets (or better I don't remember much).
> Does a waiting read (in the second task) block a write in the first
> task?

Usually not. Note that you must wait not for a socket read, but for a
"variable-update" event from the middleware layer.

>  - how can I interrupt the waiting read task to force activity in the
> main task?

Don't. A waiting task does not consume CPU time, so why would you like to
interrupt it?

>  - what other hints can you give me?

Never ever use UPD, avoid TCP_NO_DELAY with TCP/IP. The first is unreliable
for your purpose, the second quickly brings the network down. Carefully
design your network protocol, most probably it will be full-duplex in the
end. Make it platform independent from the start (htonl issues etc.)
Consider connection start/down/repair issues with a great care, it will pay
off later. Then, well, real-time issues. Under Windows the above can
perform with 5-10ms [this is the figures of our commercial middleware.] If
you want it faster, you have a problem then. Windows is not very suitable
for this. You might also have to consider numerous industrial Ethernet
semi-standards and time-triggered protocols instead of standard Ethernet.

Good luck!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de