When we defined the architecture, we acknowledged that the transaction model was likely to be the subject of much debate.
Consequently, we named this piece the "reference dispatcher", which was intended to provide a simple transaction method suitable to the programming language and paradigm of choice and provide a simple wrapper to use the encoder/decoders. These implementations are likely to be different between Java, C and Perl. It was expected that some sophisticated apps may use the reference dispatcher as base code to extend, or possibly pitch it and leverage only the parsing and framing modules of the LTK. If I were to loosely specify requirements/goals for the reference dispatcher, I'd say: Provide a reference "connection" that has the following functionality: Allows multiple "endpoint" instantiations within 1 runtime Usable by either an LLRP client or reader endpoints. Can initiate and/or accept LLRP connections. Can send any LLRP message (read generic) to the peer endpoint Can receive any LLRP message (read generic) from the peer endpoint Can perform a transaction sending the message and waiting for the response. (Note, readers have to do this too with KEEPALIVE) Regards Paul -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gordon Waidhofer Sent: Friday, October 26, 2007 2:52 PM To: LLRP Toolkit Development List Subject: Re: [ltk-d] Communication/Transaction support Christian, What you are asking about is a frequent topic of discussion. We call it the "transact" model. Early on we recognized that it is a deeper subject than the encoder/decoder. In LTKC and LTKCPP (C++) there are modules called ltkc_connection and lktcpp_connection, respectively. There is a synchronous Transact() call. It is built atop primitive SendMsg and RecvResponse() calls. RecvResponse() is built atop RecvMsg() and RecvResposne() waits for a specific incoming message based on type and MessageID. The Connection instance contains a list of deferred messages (like READER_NOTIFICATION_EVENT) that are retrieved by RecvMsg(). All in all, it is what it was meant to be: good enough for example programs and also an example for implementing a Transact() model more suitable for an application. I think I got a little lucky on ltkc[pp]_connection. I expected it would be entirely replaced in an application. But the underlying primitives work out OK for more sophisticated circumstances. I've done applications where there is a receiver thread. All messages are received by it. Response messages are diverted to the main thread. The notifications, like READER_NOTICATION_EVENT, are processed under the receiver thread. All necessary mutexes and semaphores are done above ltkc[pp]_connection. It worked out just fine. To the main thread the resulting Transact() is still a synchronous call. This meant that large portions of the example programs could be used as-is. All the gritty bits for composing ROSpecs, etc, came for free! All that changed was how the application specific Transact(), a wrapper around ltkc[pp]_connection::Transact(), is implemented. FWIW. Regards, -gww -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christian Floerkemeier Sent: Friday, October 26, 2007 2:31 PM To: 'LLRP Toolkit Development List' Subject: [ltk-d] Communication/Transaction support We are just about to finalize the messaging framework of LTKJava and I was wondering how the other LTK* libraries implemented the messaging. - Did you implement the request/response messaging, e.g. ADD_ROSPEC/ADD_ROSPEC_RESPONSE, synchronously with the client blocking until the reader fulfills the request? Or did you implement this asynchronously via a callback/listener mechanism? - I guess you implemeted the listener mechanism anyway for messages initiated by the reader such as READER_NOTIFICATION_EVENT, right? Don't think a common approach is necessary, am just curious. Christian -- Christian Floerkemeier Auto-ID Lab, Massachusetts Institute of Technology phone: +1-617-324-1984 email: <[EMAIL PROTECTED]> ------------------------------------------------------------------------ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel ------------------------------------------------------------------------ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
