RFID Guardian Software:Library:Top-level:User Interface

From RFID Guardian

RFID Guardian Software / Library / Top-level / User Interface

Contents 1 User Interface 1.1 UI communication 1.2 UI server implementation 1.3 UI client implementation 1.4 UI submodules

User Interface

Some of the MRG modules are used in interacting with the outer world:

• UI server implementation
• UI clients
• for communicating, UI server and clients use GP (Guardian Protocol), the dedicated message language for the RFID Guardian and its peers

Here we describe how the user interface is implemented. There is a separate [user-manual user manual ]that describes how it should be used. GP is discussed in more detail below .

UI communication

There are UI clients that are implemented in different languages: a command-line interface in C, and a GUI interface in J2ME (Java for embedded devices like cell phones). The server runs on the RFID Guardian, so it is in C. Maintenance considerations led us to make a compiler that, taking the GP message format as input, generates stubs for C and Java clients, and skeletons in C for the server. The job for clients is to translate user commands into GP request messages, and to appropriately present GP response messages to the user. The communication paradigm between UI client and server is RPC: a request is always answered by a GP response message from the UI server.

The C network interface for a UI client-server connection is currently a file descriptor, which can be tied to a serial line, a socket connection, or a BlueTooth connection. The J2ME client uses a BlueTooth stream.

As an illustration, we give an example of how a UI command is executed in this structure. Say, the cell-phone GUI user selects the [ACL] menu, then clicks the [status] command. As a consequence, the J2ME application on the cell phone constructs a request message of class org.rfidguardian.GP.ReqAclAclStatus . That request is passed to the generated stub that converts it to a (BlueTooth) byte stream, which is sent to the RFID Guardian. The RFID Guardian's GP reception layer receives that stream over the BlueTooth connection, unmarshalls it into a struct mrg_GP_req_acl_acl_status_t , and passes that to the handler for this kind of request. The handler (in the ACL layer) fills out a response struct mrg_GP_resp_acl_acl_status_t , and the reverse route is taken for this response. The end of the journey is that an automatically created object of class org.rfidguardian.GP.RespAclAclStatus is handed to the cell phone application, which displays the contents of that response to the user.

The GP messages are of a fixed size. Data of arbitrary size is fragmented by the implementation of that command. For example, a file can be cat 'ed, and it sent chunkwise over the UI network. The file/cat implementation takes an offset parameter, and the client is responsible for manipulating that offset across consecutive calls.

UI server implementation

For each UI message type that is to be served, the appropriate part of the appropriate submodule registers a UI server callback with the GP dispatcher module, which receives the unmarshalled requests from the network. The GP dispatcher inspects the type of the message, unmarshalls it, and hands the result to the registered callback. The callback inspects the command arguments and does its job, then returns a response message or error reply. See also the section on Operating Model .

API	include/ui/mrg_ui_impl.h
Source	[ src/ui/impl/ ]

UI client implementation

Each submodule of the command-line UI client registers itself with the UI client, with a prompt string, a help message, and a UI client callback . The UI client prompts the user for input on its [#Console console ], parses the command that is typed, and dispatches to the callback that belongs to that command. If the command is incomplete or incorrect, the help message for that command is printed. When a command is completely parsed, an appropriate GP request message is assembled and sent out.

The J2ME UI client is documented extensively in its own report .

API	include/ui/mrg_ui_stdin.h
Source	[ src/ui/stdin/ ]

API	same as source
Source	[ java/org/rfidguardian/UI/ME/ ]

UI submodules

The UI submodule and command software structure on the UI client is exactly matched by the software structure of the UI server implementation.

There are UI submodules to control or query:

• (flash) disk:
  • mkdir, rmdir, chdir
  • ls, cat, save
  • rm, mv
  • upload, download: serial line, tftp
  • pwd
• on-board reader
  • perform tag scan
  • authentication
  • more?
• logger
  • enable/disable request/response
  • flush/browse
  • to be implemented: smart filtering of logged frames
• spoofer
  • enable/disable
  • tag sets
• ACL
  • enable/disable
  • load a complete ACL
  • set context
• discovery
  • perform discovery
• system stuff
  • get/set date
  • reboot
  • version
  • command line history/editing

For each of the activities listed here, there is a GP C type and Java class for request and response.