When ttsession crashes, you will not be able to recover the following:
Patterns registered by procids in the crashed session
Outstanding requests from procids in the crashed session
Messages that were passed the tt_message_send_on_exit call by procids in the crashed session
Session props
Session-queued messages
What happens if rpc.ttdbserverd exits unexpectedly?
If rpc.ttdbserverd exits unexpectedly, inetd will start a new one to replace it. Data may be temporarily unavailable but no data will be lost. However, one or more API calls may return TT_ERR_DBAVAIL; if the call returns TT_OK, the dbserver will update the ToolTalk databases appropriately either immediately or when a new dbserver reads the crash recovery log.
What happens if a host or a link is down?
When TCP notices that a host or a link is down, the TCP connection breaks. When a process connection to ttsession breaks, ttsession behaves as if the process exited. All the patterns are cleaned up, and the process will receive the error message TT_ERR_NOMP if it attempts to send or receive messages.
What does tt_close do?
When you call tt_close, ttsession only closes the current procid. If the current procid is the last procid to close, it cleans up all the ToolTalk structures created since the tt_open call was made. You must call tt_close on the file descriptor returned by tt_fd; otherwise, your file descriptor count will rise upon successive tt_open and close calls.
Is message delivery guaranteed on a network?
Yes, delivery is reliable because messages are sent using RPC on TCP/IP.
Is there a temporal sequence of message delivery?
Between a given sender and receiver, message sequence is preserved; that is, if process A first sends message M1 and then later sends message M2 and both messages are received by process B, process B will receive message M1 before it receives message M2. However, there are two special exceptions:
If process B receives message M1 and then rejects it, message M1 is redispatched to process C. In the meantime, (while process B is deciding whether to reply or reject message M1), the ToolTalk service continues its message delivery. These subsequent messages can appear to "pass" the first request.
If process B's messages are queued, it will receive its queued messages when it declares a ptype that contains the pattern which caused the queuing. However, process B may not actually receive its queued messages (in this case, message M1) until it has already received subsequent messages from process A.
What is unix, xauth, and des?
These are the three kinds of authentication:
unix tells you the uid of the entity that is making an rpc call on you. The dbserver enforces security on each RPC call and uses this kind of authentication by default.
xauth uses a read-protected file in your home directory to control access to your X display (and, thus, to your ttsession).
des uses the Data Encryption Standard (DES) to ensure that processes who talk to ttsession are really who they say they are.
Can my applications hide messages from each other?
No. The ToolTalk service intentionally does not provide a mechanism that allows one application lock out other applications from seeing its messages.
Is there protection against interception or imitation?
No. The "plug-and-play" concept of the ToolTalk service allows applications to install and deinstall tools of choice that best perform a particular task. If application B responds better to protocol X than does application A, protocol X should be allowed to deinstall application A and install application B.
Where are queued messages stored and how secure is the storage?
File-scoped queued messages are stored in a database on the same filesystem as the file to which they are scoped. The database is readable to the super-user only, and the ToolTalk database server (running as root) only gives the messages to processes owned by a user with read access on the file.
Session-scoped queued messages are stored in the address space of the ttsession that manages the session. ttsession only gives the messages to a process that has satisfied the authentication mode in which the ttsession is running.
Is the ToolTalk service C2 qualified?
No.
How can I trace my message's progress?
To trace your message's progress, turn on the trace output of the ttsession involved. The easiest way to do this is by using the tttrace application, but you can also send a SIGUSR1 signal to a running ttsession process by using the following command:
|
How can I isolate my debugging tool from all the other tools using the ToolTalk service?
To isolate your debugging tool, use the "process tree session" mode. This mode places the session name in an environment variable to find the ttsession process. To use this mode, do the following:
Start a new process tree session with trace mode turned on.
% ttsession -t -c $SHELL * * ttsession (version 1.3, library 1.3) * ttsession: starting %
ttsession starts, sets the environment variable, and forks the given command ($SHELL). You are now running in a subshell. All the commands run from this subshell will use the ttsession started from the command line. You can check the value of the TT_SESSION environment variable for the session id of this new ttsession.
Inside the subshell, run the test programs:
% ./my_receiver & [1] 4532 % ./my_sender & .. and look at the output of the ttsession trace.
Exit the subshell after testing.
If you start any tool that uses the ToolTalk service in the subshell, it uses the process tree ttsession, not the X-session ttsession, which will produce undefined results.
Can I use the ToolTalk service with C++?
Yes. The ToolTalk API header file is set up to deal with C++. When you use C++, tt_c.h declares all the API calls as extern C.
Should I qualify my filenames?
No. The ToolTalk service does not allow explicit hostname qualification of pathnames. If you use a filename that contains a colon (:) symbol, the ToolTalk service searches for a filename that contains the colon symbol. The tt_message_file and tt_default_file calls return the realpath of the specified file as it appears on the machine on which you invoked the call. The ToolTalk service ensures that
If two clients file-scope to the same file on different machines, they can talk to each other without regard to how the two files are actually mounted on each machine.
A locally-valid, canonical pathname is returned back to you.