RITA messages may be in binary or
ASCII. In the simples form, the
messages are simple C-strings. If
binary, the first byte of the message must be 0. The following byte is a control byte that distinguishes among
the different RITA protocols. Moreover,
RITA messages may be a subset of XML scripts to encapsulate both data and
RITA messages may be transmitted in UDP or TCP frames.
Again, in its simples implementation, UDP datagrams are used.
This is the case with simple 8-bit controller.
Each message must fit in a single frame (less than 1500 bytes).
This size constraint is not a restriction, since typical control
messages are only a few bytes long. Moreover,
restricting the number of frames and the frame size reduces network
Essentially, with network connectivity, you
may type in short strings that are received by the RITA node.
The node then takes action and sends back a short string.
The issues of connection reliability and security are moved to the
application layer. Although this
sounds like running opposite to conventional wisdom, it makes good practical
sense in this context. After all,
the RITA nodes implement very simple control routines.
That is, their application is very small compared to a public HTTP
server. If you type in a command
and not get a response, you simply type in the command again. In TCP, the protocol takes care of this by waiting for an
acknowledgement and re-transmitting if deemed necessary.
By moving this responsibility to the application lets the RITA node
communicate in UDP frames. Otherwise,
the node would have to implement and maintain the much more sophisticated but
resource consuming TCP logic.
Typically, the capacity of a network node is
measured by the number of simultaneous clients it can serve.
Using UDP rather than TCP for RITA messages makes sense in this regard.
RITA messages are inherently short.
Thus, with UDP, there is no need to keep parallel sessions open while
talking to several clients simultaneously.
In fact, from the RITA node viewpoint, each message is served as it
comes in. The node need not keep
track of the different IP addresses from which the messages were originated.
If TCP is used, a session must be initiated with each client.
As the number of open sessions increases, the memory and CPU
requirements become taxing for a small (8-bit) controller.
Moreover, maintaining simultaneous sessions is best accomplished in a
multitasking environment. The
multitasking kernel itself needs CPU resources, which can be avoided with UDP
when small controllers are used. RITA
uses TCP with high-performance 16-bit or 32-bit controllers.
The architecture is flexible. For
instance, the nodes may be programmed to generate unsolicited messages to
known IP addresses. Similarly, the nodes may be programmed to only respond to
messages from known IP address or ports.
Schemes that are more elaborate are still possible.
For example, the node may respond to a keyword or even respond only
during certain times of the day. The
RitaBrowser launches a specified program on the connected PC when a keyword is
received from a RITA node. The
tokens following the keyword are passed on to the launched program as
command-line parameters. In its
most generic form, a batch file may be launched, which in turn executes or
launches other programs depending on the command line.
For example, you may invoke an e-mail server and send a message, or
call a pager number.
| Rita-51 | Rita-51J
| Design Philosophy | RitaBrowser
| NetApi51 | Example
| Ping Utility