From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,136c120daac2a1 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!news3.google.com!news.glorb.com!npeer.de.kpn-eurorings.net!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: tasksing and TCP sockets Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.14.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1138659171.491931.322480@g49g2000cwa.googlegroups.com> Date: Tue, 31 Jan 2006 11:09:17 +0100 Message-ID: NNTP-Posting-Date: 31 Jan 2006 11:09:18 MET NNTP-Posting-Host: 12074f58.newsread4.arcor-online.net X-Trace: DXC=XEP4X>Hl\U_8f4>W>BJ_OP:ejgIfPPldTjW\KbG]kaMXXY;eg@jLYe\?=`dfYc@TiS[6LHn;2LCV^7enW;^6ZC`TIXm65S@:3>_ X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:2724 Date: 2006-01-31T11:09:18+01:00 List-Id: 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