RITA Messages
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 context.

UDP versus TCP
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 traffic. 

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. 

Flexibility
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  |  Rita-51  |  Rita-51J  |  Design Philosophy  |  RitaBrowser  |  NetApi51  |  Example |  Ping Utility |  NetCat

 ___________________________________________

      Copyright 1995-2008 Rigel Corporation
       Hardware Warranty | Software License Agreement | Privacy Policy | Contact Us 
       Last updated 3/18/08