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
