What is the difference between arg_add, barg_add, and iarg_add?
The barg_add and iarg_add calls are basically an arg_add call followed by a set of the value.
What is the type or vtype in a message argument?
The type or vtype (which is short for value type) in a message argument indicates the semantic domain in which the argument's value has meaning and is determined by your application.
Vtypes are analogous to typedefs in C. Every vtype, by convention, corresponds to only one of the three possible data types for argument values.
The vtype mechanism allows you to declare two values as the same type; for example, you could declare both the vtype messageID and the vtype bufferID as C strings with different semantics for each: some operations are valid on messageID only, some operations are valid on bufferID only, and some operations are valid on both vtypes. The pattern-matching mechanism makes sure that a request with a bufferID string does not get matched to a pattern for an operation that is only valid on messageID strings.
How do I use contexts?
You can use contexts to restrict matching. To restrict matching, a message must have the same contexts, or a superset of the contexts, in order to possibly match. Also, if the name of a context slot begins with a dollar sign ($) character (for example, $ISV) and the message causes an application to be started, the environment variable for the started application will be set to whatever value is indicated in the context slot.
How does ttsession check for matches?
Table D-4 describes the various ways ttsession checks for matches.
Table D-4 How ttsession Checks for Matches
Mechanism | Description | Match? |
|---|---|---|
TT_HANDLER | This type of addressing is "point-to-point" delivery -- the message is passed directly to the receiver. You cannot monitor point-to-point messages because registered patterns are never checked. | No matching required. |
TT_PROCEDURE | Scans list of static signatures (sig) that have same operation (op) and collects lists of observers and potential handlers. If the sig has no arguments and no contexts If sig prototype (number, type and mode of args) have different values If the sig contexts are a subset of the contexts in the message Saves information for any static observers that require queuing. Scans through dynamic patterns and adds to lists of observers and potential handlers. To form the lists, ttsession first uses the patterns with operations, then the patterns without operations. Checks reliability, states, class, address, handler, handler ptype, scope, object, otype, sender, sender_ptype, args, contexts. Delivers to observers first (because a handler can change state). Delivers to handler with best match -- if more than one handler equally "best" matches, the handler is arbitrarily chosen. |
=> Match => No Match => Match |
TT_OBJECT & TT_OTYPE | Checks whether the otype argument is filled in If sig has a different otype If sig has no otype & scope is different Otherwise, matches in the same manner as for TT_PROCEDURE matching. |
=> No Match => No Match |
How many kinds of scope does the ToolTalk service have?
Currently, the ToolTalk service has only two kinds of scope: session scope and file scope.
Note - X session is sometimes referred to as a scope; however, the X session is really a session scope.
What are the TT_DB directories, and what is the difference between the types database and the TT_DB directories?
The ToolTalk types databases store the static ptype and otype definitions. These definitions declare the messages to which applications and objects respond. The ToolTalk types compiler modifies the types database when you add or change static type definitions. Upon starting, ttsession reads in these type files.
The TT_DB database is created by rpc.ttdbserverd. The tt_db directories contain the associations between files in this partition and the sessions with patterns interested in these files. It also contains all the object spec information for files in this partition.
What should the tt_db databases contain?
The tt_db databases currently contain the following ten files:
- access_table.ind
- access_table.rec
- file_object_map.ind
- file_object_map.rec
- file_table.ind
- file_table.rec
- file_table.var
- property_table.ind
- property_table.rec
- property_table.var
The permissions for these files are set to -rw-r--r-- .
What does rpc.ttdbserverd do?
The ToolTalk database server daemon performs three major functional duties:
It stores the ToolTalk session IDs of sessions with clients that have joined a file using the tt_file_join call.
It stores file-scoped messages that are queued because the message disposition is TT_QUEUED and a handler that can handle the message has not yet been started.
It stores ToolTalk objects specs.
It responds to requests into the ToolTalk filename mapping API.
Do ttsession and rpc.ttdbserverd ever communicate?
No.
What message bandwidth can be supported?
About 100 small messages per second. Performance mainly depends on how many recipients each message has; that is, notices that do not match any pattern are the cheapest while messages that match many observers are the most expensive.
Is there a limit to the message size or the number of arguments?
No. However, while there is no designed limitation to the size of a ToolTalk message or the number of arguments ToolTalk does copy the data several times (both from one area in the client's address space to another area, and across the RPC connection to and from the server). For example, a megabyte of data in a ToolTalk message would be copied at least 4 times:
From your storage to the ToolTalk library's storage
From the ToolTalk library to the ToolTalk server
From the ToolTalk server to the receiver's library
From the receiver's library to the final resting place.
If there are processes observing the message, even more copying will take place. In addition, no other messages for this session can be delivered during the copy time because the ttsession process is single-threaded. Therefore, if you plan to send really big chunks of data very often, you probably want to consider using a non-ToolTalk way to pass the data.
What is the most time efficient method to send a message?
Directly to process (that is, addressing the message using TT_HANDLER) is faster than procedural messages that match only one receiver.
What network overhead is involved?
The ToolTalk service does not use hardware broadcast or multicast. The message is sent directly to the ttsession process for the session (whether across the network or not). When a pattern is registered, it also is sent directly to the ttsession process. The ttsession process matches the message against all the patterns and sends the message directly to only the processes that registered patterns that match the message -- if no process on another machine is interested in a message, that machine does not need to wake up and look at it.
Does the ToolTalk service use load balancing to handle requests?
No, the ToolTalk service is not a load-distribution mechanism. If two processes with identical patterns are registered, the ToolTalk service arbitrarily chooses one of process and delivers all matched messages to it. You can do load distribution if you unregister the pattern while the process is busy and reject any messages that may have been received before the pattern was unregistered.
What resources are required by a ToolTalk application?
Coarse numbers indicate that several 100K of working set for a sending client, ttsession, and a receiving client is required to process messages. ToolTalk memory requirements do not grow over time, as long as clients process messages in a timely manner.
What happens if the ttsession exits unexpectedly?
When ttsession crashes, the tt_fd becomes active and most ToolTalk API calls will return the TT_ERR_NOMP error message
|
Most applications assume this message means that something has happened to ttsession and will stop sending or receiving ToolTalk messages. Possible recovery from this situation may include:
Recognize the TT_ERR_NOMP situation
Call tt_close to clean up the connection from its end
Reinitialize the ToolTalk service
Call the sequence:
tt_open, tt_default_session_join, tt_fd |
Re-register all patterns and re-declare ptypes
Note - You may need to manipulate the setting of the environment variable TT_SESSION and the value of the TT_SESSION property of the root X window (if it exists) when you restart a crashed ttsession to take over where the last one left off. Also, you must inform other participants of the crashed session of the restarted session and the new session id so that they can recover.