Questions

The following frequently asked questions contain additional information about ToolTalk services.

What is the ToolTalk service?

The ToolTalk service enables independent applications to communicate with each other without having direct knowledge of each other. Applications create and send ToolTalk messages to communicate with each other. The ToolTalk service receives these messages, determines the recipients, and then delivers the messages to the appropriate applications.

Is the ToolTalk Service the Sun implementation of the Common Object Request Broker Architecture (CORBA)?

No. The ToolTalk service is not the Sun CORBA-compliant Object Request Broker (ROB). The ToolTalk service was designed and shipped in 1991 -- before the Object Management Group (OMG) CORBA specification was defined.

The Sun CORBA-compliant ORB is the Distributed Object Management Facility (DOMF), which is part of the Sun Project DOE product. Sun is publicly committed to support the ToolTalk API running on the DOMF when the DOMF becomes generally available as part of Solaris. Applications that use the ToolTalk messaging service today will transition to the distributed object environment of the future.

What files are part of the ToolTalk service?

The ToolTalk files are found in the /usr/dt/bin, lib, and include/Tt, directories, as well as in /usr/openwin/bin, lib, include/desktop, and man directories. The reason for this is historical. ToolTalk existed before the Common Desktop Environment (CDE) and was shipped with Solaris in the /usr/openwin directory structure. When CDE was released, ToolTalk was visible from the /usr/dt directory structure using symbolic links, but was still actually installed in /usr/openwin. On a Solaris 2.5 or compatible system that has CDE installed, you will find that the ToolTalk files in /usr/dt are symbolic links to /usr/openwin. On a Solaris 2.4 or compatible system with CDE installed, you will find two different complete versions of ToolTalk installed: one in /usr/dt and one in /usr/openwin. However, only the ToolTalk in /usr/dt will work with CDE.

Table D-1 describes the files.

Table D-1 ToolTalk Files

File Name	Description
`ttsession`	Communicates on the network to deliver messages.
`rpc.ttdbserverd`	Stores and manages ToolTalk object specs and information on files referenced in ToolTalk messages.
`ttcp`, `ttmv`, `ttrm`, `ttrmdir`, `tttar`	Standard operating system shell commands. These commands inform the ToolTalk service when files that contain ToolTalk objects or files that are the subject of ToolTalk messages are copied, moved, or removed.
`tttrace`, `ttsnoop`	`tttrace` is analogous to `truss`(1). It enables you to trace either the messags-passing and pattern matching occuring in a given `ttsession`, or it can be used to provide a per-program trace of all calls into the ToolTalk API. `ttnsoop` is a Motif-based program that provides the message and pattern tracing functionality of `tttrace` with the added ability to create and send messages easily, and register patterns, both as a debugging or tutoring aid.
`ttdbck`	Database check and recovery tool for the ToolTalk databases.
`tt_type_comp`	Compiles the ptype and otype files, and automatically installs them in the ToolTalk Types database.
`ttce2xdr`	Converts ToolTalk type data from the Classing Engine database format to the XDR database format.
`libtt.a`, `libtt.so`, and `tt_c.h`, `tttk.h`	Application programming interface (API) libraries and header file that contain the ToolTalk functions used by applications to send and receive messages.

Where is the initial X-based `ttsession` started?

The first call to tt_open automatically starts ttsession if no ttsession is running. However, the /usr/dt/bin/Xsession file contains an entry such as the following, which will start a ttsession at login time automatically if you are using /usr/dt/bin/dtlogin:

# Start ttsession here.
  dtstart_ttsession="$DT_BINPATH/ttsession"

Where is `rpc.ttdbserverd` started?

The /etc/inet/inetd.conf file contains an entry similar to the following:

# Sun ToolTalk Database Server
100083/1  tli  rpc/tcp  wait  root  /usr/dt/bin/rpc.ttdbserverd 
 /usr/dt/binrpc.ttdbserverd

Where are the ToolTalk type databases stored?

The environment variable TTPATH tells the ToolTalk service where the ToolTalk Types databases reside. The format of this variable is:

userDB[:systemDB[:networkDB]]

Note - The type files are read in reverse order of TTPATH.

This environment variable also tells the ToolTalk service where to search for database server redirection files. The default locations are listed in Table D-2.

Table D-2 Default Locations of ToolTalk Types Database

Database	Location
user	`~/.tt`
system	`/etc/tt`
network	`$OPENWINHOME/etc/tt`, or, `/usr/dt/appconfig/tttypes`.

Do I need X Windows to use the ToolTalk service?

The ToolTalk service does not use X messages or protocols to deliver messages. The ToolTalk service is only associated with X Windows if you run an X session.

When you run an X session, the session name is advertised as a property (named TT_SESSION) on the root window of the X server. Every process which names that X server as its display gets that X session as its default session. Since the X session is defined to be the group of processes displaying on a particular X display, you do need to run X Windows by definition but not because the ToolTalk service requires you to use it.

If there is no X server running at all (for example, you are running a session that consists entirely of character-mode applications running on a dumb terminal), use a process tree session. When you run a process tree session, the session name is advertised in the environment variable TT_SESSION. This session is the default session for every process in the tree of processes descending from the process that set the environment variable.

Can I use the ToolTalk service with MIT X?

Yes. However, the LD_LIBRARY_PATH must point to /usr/dt/lib for the libtt.so file.

Where is the session id of the X-session?

To get this identifier, enter the following command:

xprop -root | grep TT_SESSION

Note - An X session is a session that advertises its session id on the TT_SESSION property of root window.

How does `tt_open` connect to a ttsession?

After some internal initialization, tt_open tries to find a ttsession.

tt_open checks whether the environment variable TT_SESSION is set.

If this environment variable is set, it uses the value as the id of the ttsession.

If this environment variable is not set, it checks to see if the DISPLAY environment variable is set.
- If this environment variable is set, it uses the value as the id of the ttsession.
- If this environment variable is not set, it checks to see if the TT_SESSION property on root X window (of the machine running the display) is set.
In the event that none of these environment variables are set, it will start a ttsession itself.
tt_open 'pings' the ttsession to make sure it is active.
tt_open checks the environment variable TT_TOKEN to determine whether the client was started from a `start' command for the ptype.

Once the start ptype is determined, tt creates a procid.
tt_open creates a TCP/IP socket on the client side to which ttsession connects.

Activity on the socket is noticed via the socket's associated file descriptor. ttsession only uses this channel to notify the client of incoming messages.

Note - Call tt_close on this file descriptor; do not call the close function. If you call the close function on the file descriptors returned by tt_fd, your file descriptor count will rise upon successive tt_open and close calls.

tt_open refreshes the database hostname redirection map.

After calling `tt_open`, when does a session actually begin?

If the default session is an X session and there is no ttsession running, libtt starts one; otherwise, the ttsession must be started first in order to get the session name.

If another session is attached, does the first session get killed?

No. The first session will still be running.