Personal tools
You are here: Home Issue Tracker Background reader
Document Actions

#23 — Background reader

State Resolved
Release:
Area Core Software
Issue type Feature
Severity Important
Submitted by Sébastien Lelong
Submitted on 2007-04-26
Responsible Sébastien Lelong
Target release:
Return to tracker
Last modified on 2007-05-18 by Sébastien Lelong
SirBot works in a master/slave mode: the PC first initiate the connection. Never the bot. This is a problem. Even if the @poll decorator can kind-of bypass this problem, still the bot can't initiate the connection, thus can't tell the PC "I've head a sound".

This is a master/slave because:
- the PC sends a request
- then bot answers, this is the response
- request + response can be used to generate event.

Need to associate the initial request with the response. Thus, cannot use to read/write threads. An options would to use a "background reader": this is a reader thread, which keeps reading what's come from the bot. When a request has to be sent, the reader is deactivated. The request is sent, got the response so we can create (req,res) couple. Once done, the background reader is reactivated.

So, when the bot has to send something, it'll be caught by the bgreader. The message can then be passed to a callable or something... Now, a issue would be:
- PC sends a request
- the bot, at the "same time" sends a message, and not the expected response
- bad couple (req,msg).

This can be resolved by checking what comes from the bot, thus adding types in messages occuring within the communication process. Ex: message initiated from the bot starts with a specific chars. More, because the bgreader can't know how many chars it should get from the bot, the protocol needs to use SOF/EOF chars.

Using a bgreader:
- a request to the bot looks like:
     <SOF><REQ>arf<EOF>
- a response (to a request) from the bot looks like:
     <SOF><RES>blabla<EOF>
- a message (not answering to a request) from the bot looks like:
     <SOF><MSG>oula<EOF>

  (<SOF>, <MSG>, <REQ>, <EOF> are specific chars)

The bgreader must be put in the communication manager. Actually, this wouldn't be a reader thread. Need to have a general reader thread, used for both message and response, which is able to feed two queues (one for messages, one for responses) according to the type (<MSG> or <RES>). Using python the Queue module, readers can get elements from the queue, and deal with timeout, blocking, etc...
Added by Sébastien Lelong on 2007-04-26 16:43
Issue state: unconfirmedopen
Go !
Added by Sébastien Lelong on 2007-05-03 07:45
Issue state: openin-progress
Added by Sébastien Lelong on 2007-05-03 07:50
Probably, ticket #18 will have to be reopen, since reset or emergency events could be detected with this bgreader. Having the possibility to detect reset or emergencies would then require (mandatory) the use of bgreader, thus SOF/EOF and types (MSG/RES)
Added by Sébastien Lelong on 2007-05-07 09:41
Using such a reader requires SOF and EOF: frames are getting richer. To send one order to the bot, we need to send several chars. Thus, the semaphore in rs232.py is not useful, since rs232 locks it each time it sends a char. The semaphore must be used each time an order is sent (to prevent colision between main thread and bgreader thread), that is must be put in the CommunicationManager
Added by Sébastien Lelong on 2007-05-18 15:37
Issue state: in-progressresolved
> Using such a reader requires SOF and EOF: frames are getting richer.
> To send one order to the bot, we need to send several chars.
> Thus, the semaphore in rs232.py is not useful
Not True, since there's only one reader and one writer. Semaphore is still useful to avoid between them.

Anyway, this big part is done. BGreader has been abstracted as a FrameManager. Now, depending on the one used, communication can be in master/slave or peer-to-peer mode.

Powered by My Hands Powered by Jalv2 Hosted by Google Code