Release of TCA Version 8.0 Summary: ======== 1) Receiver Translates: Messages are sent using the native byte ordering of the sender and the receiver performs automatics conversion, if needed. When messages are passed between machines of the same type, no translation is done, even if the machines don't use the network byte order (For example, i486 machines). 2) Direct Messages: Messages that don't involve the task tree can now be sent directly from one module to another. You can control this on a per resource basis using the tcaDirectResource call or globally using the "-c" option on the central server. Inform and query messages are passed directly whenever they are not being logged or tapped. 3) New central server interface commands. kill: Kill the task tree. Removes all pending and complete messages. close : Close a connection to a module. display : Show the task tree and all other current messages. dump : Print the malloc chain. Useful for debugging central. You have to compile with dbmalloc for this to be available. 4) Emergency memory free routines try to purge some of the pending queues to get enough memory to continue. This is always a last ditch effort, so it may still fail. 5) "Global" removed from some calls. For example, tcaRootNodeGlobal is now tcaRootNode. The old names are retained as defines for compatibility. 6) Reconfigured the TCA tools to separate the log parser from the tview front end. This will allow the parser to be used for other tools. 7) Added the utilities code to create the devUtils and ezx libraries. The device utilities library provides methods for creating and managing interfaces to hardware devices and other "IO" devices like X11, TCA and stdin. Provides more robust error and interrupt handling to improve your TCA programs. EZX is a wrapper to help use X11 to create interfaces. More documentation is still needed for these libraries. 8) Added tcaModuleProvides and tcaModuleRequires. Both take a variable number of pointers to strings that represent the names of capabilities the module provides/requires. By default, a module provides the capabilities with the name of the module and any other resources it creates. A module may also provide other resources. For instance, a simulator module may provide a number of capabilities that replace the capabilities of the real device controllers. There are also versions that take a NULL terminated array of pointers to strings, rather than use a variable number of arguments. 9) The number of modules defaults to 1. Using the tcaProvides and tcaRequires functions allows the central server to only start modules when the modules it depends on are also ready. Specifying a minimum number of modules is less useful now. 10) tcaMessageHandlerRegistered, tcaMessageRegistered: Determine whether a handler, or message, is registered. It can be used to determine whether optional messages should be sent. The result is cached, if a handler/message is registered. Otherwise, central is polled on every call. 11) tcaMaybeExecute, tcaMaybeExecuteWithConstraints, tcaMaybeExecuteAsync: Macros to test to see if a message has a handler registered and execute the message only if the handler is registered. 12) Support for Solaris and Linux operating systems. 13) tcaGetVersionMajor and tcaGetVersionMinor return the version number for tca, so you can tell which version the code was compiled with. 14) TCA_connect, the routine in the device utilities library now also takes provides and requires lists. 15) tcaGetVersionMajor and tcaGetVersionMinor return the version number for tca, so you can tell which version the code was compiled with. Details: ======= 1) There are several advantages to having the receiver translate the byte order for non-network byte order machines. The most obvious one is that it reduces double translation (native->net->native) when data is sent to processes on the same machine or same type of machine. It also allows the sender to do less data copying. When data must be translated from one byte order to another, to be sent, it must be copied. Otherwise, the translation would overwrite the original data. When receiving data, it is OK to overwrite the data buffer, since it is just temporarily needed to hold the incoming bytes. 2) Direct messages. TCA will take care of establishing and reusing direct connections from one module to another. To use direct messages as the default, use the -c option on the central server. For example: "central -c 1" All inform and query messages will, by default, go through direct connections. If logging or tracing are turned on, then the messages that are logged or traced pass through the central server so that they can be logged or traced. You can selectively allow direct connections by using the tcaDirectResource call. This specifies that the messages handled by that resource should be sent directly, when possible. For example, the module resource can be declared direct: " tcaDirectResource("Module B");" 3) Main event loops and Direct messages. In previous releases of TCA, there was a single socket that connected a module to the central server. With direct connections, a module may have multiple open sockets. If you use the TCA main event loop "tcaModuleListen", then TCA will manage the multiple connections. If you use TCA with X11 or have created your own event loop, you have to listen for activity on multiple sockets. If you are using X11, then you can use the routine "connectTCA_X11" in the utils/x11Utils.h file. This routine will add inputs and handlers to the X11 application context to allow the X11 main event loop to handle input on the multiple TCA sockets. The single call should be all that is needed. If you are interfacing to other devices or want more robust operation, I would suggest you use the deviceUtils library of routines. This library has routine for implementing device controllers that connect to the computer via RS232 lines or memory mapping and supports operations like polling and timeouts. It includes routines for handling X11, stdin and TCA connections. It also handles interrupts and broken pipe errors and allows you . If you "roll your own" main event loops, the call tcaGetConnections returns a pointer to an fd_set that will contain an up to date set of the open TCA connections. In your event loop, you should add these fds to the read mask in your select call. The call to tcaHandleMessage will accept messages on any of the connections and handle requests for new connections. 4) The default message deliver model for TCA is a guaranteed delivery. If a module falls behind, messages will queue up. You can limit the queue by limiting the pending messages. The default limit is infinite. There is also a TCA routine to register a handler to call when the central server runs out of memory. The default handler use to do nothing. The new default handler tries to purge the message pending queues to free memory in an emergency. 5) Speed Test : Send 200 messages from one process to another, optimizing the program for raw speed. All tests were conducted on a sparc 10 running Sunos. All processes where run on the same machine. Using different machines runs up against the limited bandwidth of the network (10 Mbits/s). TCA 7.8 TCA 7.9 TCA 8.0 Bytes/msg msg/s bytes/s msg/s bytes/s msg/s bytes/s --------- ----------------- ----------------- ------------------ 0/4 412 0.00 657 0.00 1769 0.00 16 363 5,801.64 582 9,317.85 1480 23,679.85 256 327 83,705.95 426 108,941.50 1334 341,549.66 1K 280 286,760.03 386 394,999.22 1027 1,051,431.88 4K 143 585,518.81 302 1,236,209.12 782 3,203,804.50 16K 58 955,469.81 135 2,210,402.50 402 6,581,836.00 64K 18 1,156,581.38 42 2,775,157.00 130 8,528,675.00 256K 5 1,218,955.25 12 3,068,828.50 40 10,377,018.00 1M 1 1,229,735.12 3 3,199,656.00 10 10,831,688.00