ToolTalk Internals - Detailed Outline

Dan Larner

{ItalicName} referes to the slide corresponding to the section.

1.0	The ToolTalk Architecture -- an Overview

1.1	The API -- libtt {Architecture}

1.1.1	Initialization Functions

1.1.2	Message Patterns

1.1.3	Sessions

1.1.4	Files

1.1.5	Messages

1.1.6	Objects

1.1.7	ToolTalk Storage Management

1.1.8	ToolTalk Error Status

1.1.9	Exiting

1.1.10	ToolTalk Error-Handling Macros

1.2	Session scopes -- ttsession

1.3	File scopes & Object Storage-- rpc.ttdbserverd

2.0	ToolTalk Installation

2.1	Where's the code? - OpenWindows, Copied from OpenWindows, pkgadd (from dis-
tribution CD-Rom)

2.2	What and where the files (normally) are.{FileLocationsBin}

2.2.1	Normally in /usr/openwin/ bin, lib, share/include/desktop, man/man1

2.2.2	ttsession - communicates with other ttsessions on the network to deliver 
messages

2.2.3	rpc.ttdbserverd - stores and manages ToolTalk object specs and information 
on files referenced in ToolTalk messages.

2.2.4	ttcp, ttmv, ttrm, ttrmdir, tttar - standard operating system shell commands 
that inform the ToolTalk service when files that contain ToolTalk objects or 
files that are the subject of ToolTalk messages are copied, moved, or 
removed.

2.2.5	ttdbck - a database check and recovery tool for the ToolTalk databases.

2.2.6	tt_type_comp - a compiler for ptypes and otypes. It compiles the ptype and 
otype files and automatically installs them in the ToolTalk Types database.

2.2.7	ttce2xdr - converts ToolTalk type data from the Classing Engine database 
format to the XDR-database format.

2.2.8	libtt.and tt_c.h - These files are the application programming interface (API) 
libraries and header file that contain the ToolTalk functions used by applica-
tions to send and receive messages. {FileLocationsOther}

2.2.9	Manpages

2.3	Versions - all (SunSoft) ToolTalk commands support a -v option that prints the ver-
sion string.

2.4	Requirements - ToolTalk service requires ONC RPC.

2.5	Installing and running rpc.ttdbserverd (Solaris) {Installing}

2.5.1	/etc/inetd.conf entry - auto start of server

2.5.2	Manual server use (while root)

2.5.2.1		comment out entry in inetd.conf

2.5.2.2	ps -ef | grep inetd and kill -HUP <inetd-pid>

2.5.2.3	kill and manually start rpc.ttdbserverd

2.6	Installing and running ttsession (Solaris / Openwindows)

2.6.1	$OPENWINHOME/lib/openwin-sys contains an entry that starts a ttsession

3.0	ToolTalk Administration

3.1	Environment Variables {AdministrationEnv1}

3.1.1	SUN_TTSESSION_CMD - Overrides the standard options specified when 
tools automatically start ttsession. If this variable is set, all ToolTalk clients 
use this command to automatically start their sessions.

3.1.2	_SUN_TT_ARG_TRACE_WIDTH - Defines the number of characters of 
argument and context values to print when in trace mode. The default is to 
print the first 40 characters.

3.1.3	_SUN_TT_FILE - "Causes ttsession to place a pathname in this variable 
when a tool is invoked by a message scoped to the defined file" (When pro-
cessing a file scoped message that requires an application to be `started', 
ToolTalk sets this environment variable (in the child process) to the name of 
the file. This can be used, for example, to pass the file name to a non-
ToolTalk aware application.)

3.1.4	_SUN_TT_HOSTNAME_MAP - Points to a map file. The defined map file 
is read into the ToolTalk client for redirecting host machines (when you want 
the server for a partition on host X, to run on a different host Y).

3.1.5	_SUN_TT_PARTITION_MAP - Points to a map file. The defined map file is 
read into the ToolTalk client for redirecting file partitions. (when you want to 
keep the database directory (TT_DB) on a partition different from the one 
actually holding the file(s)). 

3.1.6	_SUN_TT_SESSION - "Causes ttsession to communicate its session identi-
fier to the tools that it starts.")When ttsession creates a child process, 
(through the use of the -c switch, by `starting' an application, etc.) it sets this 
environment variable (in the child process) to its session identifier. If this 
variable is set, the ToolTalk client library uses its value as the default session 
identifier.) {AdministrationEnv2}

3.1.7	_SUN_TT_TOKEN - "Notifies the ToolTalk client library that it has been 
started by ttsession; the client can then confirm to ttsession that the start was 
successful." (When processing message that requires an application to be 
`started', ToolTalk sets this environment variable in the child process (to the 
ptype of the application). When the application starts and performs tt_open, 
this information is passed back to ToolTalk so it knows that the application 
coming up is the one `started' (or delegated) to handle the message.)

3.1.8	TTPATH - Tells the ToolTalk service where the ToolTalk Types databases 
reside. The format of this variable is: userDB[:systemDB[:networkDB]] 
Note: Type files are read in reverse order of TTPATH - thus entries to the left 
shadow those to the right. This also tells ToolTalk where to search for data-
base server redirection files.

3.1.9	DISPLAY - Causes ttsession to communicate its session identifier to the 
tools that it starts if the _SUN_TT_SESSION variable is not set. If this vari-
able is set, the ToolTalk client library uses its value as the default session 
identifier. This variable is typically set when ttsession is auto-started while 
running under OpenWindows.

3.1.10	CEPATH - Tells the Classing Engine where the ToolTalk Types databases 
reside. Note: this only applies to Sun platforms, and starting with ToolTalk 
1.1, ToolTalk on Sun platforms will not use the Classing Engine.

3.2	Defining and installing types - tt_type_comp runs your-file through cpp, compiles 
the type definitions, and merges the information into a ToolTalk Types table. 
{AdministrationTypes}

3.3	Examining Tooltalk type information - tt_type_comp -d user -p

3.4	Removing type information - tt_type_comp -d user -r type

3.5	Updating type information - ps -ef | grep ttsession and kill -USR2 ttsession_pid

3.6	Stored type definitions - XDR files (kept in .tt directories)

3.7	Utilities for moving, copying, deleting files - ttmv, etc. - The ToolTalk service 
rpc.ttdbserverd) maintains information about files and objects, (in TT_DB directo-
ries at the root of the partition involved), and needs to be informed of changes to 
these files or objects.{AdministrationDB}

3.8	Displaying, Checking, and Repairing Databases - ttdbck. Also for removing otypes, 
moving objects, finding dangling file references. Healthy databases should 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, prop-
erty_table.rec, property_table.var, with permissions set to -rw-r--r--

3.9	Redirection {AdministrationRedir}

3.9.1	Database host - allows a ToolTalk client to physically access ToolTalk data 
from a machine that is not running a ToolTalk database server.

3.9.2	File System - allows a ToolTalk database to logically read and write ToolTalk 
data from and to a read-only file system partition (for example, a CD-Rom) 
by physically accessing a different file system partition.

4.0	Start-up & Initialization

4.1	tt_open - what it does {Initialization}

4.1.1	Internal initialization

4.1.2	Session IDs (find a ttsession - ID is network name of ttsession)

4.1.2.1	_SUN_TT_SESSION environment variable

4.1.2.2	$DISPLAY, _SUN_TT_SESSION property on root window

4.1.2.3	start ttsession

4.1.3	Session ID anatomy 01 1797 1342177280 1 0 24151 129.144.153.7 2

4.1.3.1	01 - Version of address format

4.1.3.2	1797 - Unix pid of process

4.1.3.3	1342177280 - RPC Transient Program Number

4.1.3.4	1 - Junk version (compatibility holdover)

4.1.3.5	0 - Authorization level

4.1.3.6	24151 - User id

4.1.3.7	129.144.153.7 - Host IP address

4.1.3.8	2 - RPC version

4.1.4	Ping ttsession - This uses the a RPC call to ttsession first with NULPROC as 
the procedure to see if it's alive, then with the TT_RPC_VRFY_SESSION as 
the procedure, which returns back it's session id (the latter to prevent worries 
involving use of transient RPC numbers).

4.1.5	Create procid - This involves checking the environment variable 
TT_START_TOKEN to determine whether the client was started from a 
`start' command for the ptype (and if so the client is `committed' to the 
default session). Next, it creates a tcp/ip socket on the client side to which 
ttsession connects. Activity on the socket is noticed via the sockets associ-
ated fd [returned from tt_fd()]. This `backchannel' is used only by ttsession 
to notify the client of incoming messages.

4.1.6	Refreshes the DB hostname redirection map 

4.2	ttsession - start-up (slide of conceptual ttsession organization)

4.2.1	Initialize internal data & Set up RPC, Register with X server

4.2.2	Check for and load installed (static) types.

4.2.2.1	TTPATH

4.2.2.2	$HOME/.tt/types.xdr:/etc/tt/types.xdr:$OPENWINHOME/etc/tt/
types.xdr

4.2.3	Enter service loop (only leave to handle signals)

4.3	tt_fd - returns a fd that is active when ttsession wants to tell the client a message is 
waiting.

5.0	Internals - Conceptual View

5.1	tt_ptype_declare - registering your type {TTsessionConcept} Note that trying to 
declare a ptype when there is no static type definition for the ptype, results in an 
error.

5.2	When are your patterns active?

5.2.1	If the session / file / context is already set in a pattern when it is registered, it 
becomes active upon registration

5.2.2		Joining - Adds the session / file / context to ALL patterns that have been reg-
istered by your program.

5.2.3	Session - A pattern must be registered with each session in which it want's to 
be active.(You can't do multiple tt_pattern_session_adds and expect it to 
work simply by registering with one session.)

5.2.4	File - Your patterns can be active for more than one file (for a given procid). 
This says the file part of the pattern will match any of the listed files (an `OR' 
relationship).

5.2.5	Contexts - Your patterns can restrict their matching to particular context.Ev-
ery context in the pattern must have a match in the message (an `AND' rela-
tionship) (new for 4-93)

5.3	TTsession's RPC interface

5.3.1	Session Management - Procid joins a session ; Procid quits a session ; Get a 
key to form a procid ; Remove procid from ttsession ; Notify the server of its 
fd signalling channel

5.3.2	File Management : Process joins a file; Process quits a file

5.3.3	Message Management : Sender sends a message : Handler updates a message 
in any way (i.e. state change) ; Procid wants to retrieve the next undelivered 
message for it ; Sender sends a message to the server for delivery on exit

5.3.4	Pattern Management : Procid wants to register a new pattern ; Procid wants 
to unregister a pattern with the server

5.3.5	Property Management : Set the value of a session property ; Add a value to a 
session property ; Get a value from a session property ; Return the number of 
values for a session property ; Return a session property name ; Return the 
number of session properties

5.3.6	Type Management : Procid wants to load new types into its ttsession

5.3.6.1	Ptypes : Procid wants to declare a ptype ; Procid wants to undeclare 
a ptype ; Procid wants to test existence of a ptype ; Procid wants to 
unblock queued messages for its ptype

5.3.6.2	Otypes

5.3.6.2.1	Inheritance : Return the number of otypes derived from 
a base otype ; Return the n'th otype derived from a base 
otype ; Return the otype that is the base of a derived 
otype ; test if a derived otype derives directly or indi-
rectly from a base otype

5.3.6.2.2	Signatures : Return the number of observer signatures 
for the specified otype ; Return the number of handler 
signatures for the specified otype ; Return the op for an 
observer signature of an otype ; Return the op for a han-
dler signature of an otype ; Return the number of argu-
ments of an observer signature of an otype ; Return the 
number of arguments of a handler signature of an otype 
; Return the mode of the specified arg of an observer 
signature of an otype ; Return the mode of the specified 
arg of a handler signature of an otype ; Return the type 
of the specified arg of an observer signature of an otype 
; Return the type of the specified arg of a handler signa-
ture of an otype

5.3.7	Intersession : Inter-ttsession dispatch ; Inter-ttsession update

5.3.8	Context Management : Procid wants to join a context ; Procid wants to quit a 
context : Sender sends a contextful message : Sender sends a contextful ses-
sion-scoped message : Procid wants to register a new context-full pattern

5.3.9	Misc. : Alive check : Return session id

5.4	rpc.ttdbserverd 

5.4.1	Deals with both old and new interfaces.

5.4.2	Establishes RPC connections as a specific RPC program number

5.4.3	Only libtt communicates with rpc.ttdbserverd (not ttsession) libtt passes 
information back and forth. when needed.

5.4.4	Major functional duties {TTdbserverdConceptFile}

5.4.4.1	Storage of ToolTalk session IDs of sessions with clients that have 
joined a file via the tt_file_join call.

5.4.4.2	Storage of a file-scoped (NOT file-in-session scoped) message that 
is queued because the message disposition is TT_QUEUED and a 
handler has not yet been started that can handle the message.

5.4.4.3	Storage of ToolTalk objects specs (see tt_spec_write and the other 
tt_spec_* API calls).{TTdbserverdConceptSpec}

6.0	Patterns and Messaging

6.1	Patterns {Patterns1} {Patterns2} {Category}

6.1.1	Category(required): OBSERVE - just watch, or HANDLE - actually willing 
to perform operation and return a reply.

6.1.2	 Scope (required): 

6.1.2.1	TT_SESSION - only interested in messages in this session (i.e. 
using the same ttsession message passer), 

6.1.2.2	TT_FILE - only interested in messages about some files (rpc.ttdb-
server manages these). A session attribute may be set on this type 
of pattern to provide a file-in-session-like scoping, but a tt_ses-
sion_join will not update the session attribute of a pattern that is 
TT_FILE scoped.

6.1.2.3	TT_FILE_IN_SESSION -scopes to the intersection of interest in 
the file and the session. A pattern with just this scope will only 
match messages that are scoped to both the file and session.

6.1.2.4	TT_BOTH - interested in messages either in this session or about 
some files.

6.1.3	All other attributes `match' if they are left unspecified (but since we can't 
watch all files in the universe, some files must be filled in to scope to file).

6.1.4	Adding multiple things to a pattern attribute (e.g. repeated file_add) means 
match if any one of these is in the message (`or'). The exception is Contexts.

6.1.5	Arguments

6.1.5.1	Modes - TT_IN, TT_OUT, TT_INOUT - what can be read and 
written (from receiver point of view).

6.1.5.2	Type spaces - the `(v)type' of an argument - this is not C typing! - 
this is for application type space use. Setting vtype to ALL matches 
any vtype.

6.1.6	Contexts - used to restrict matching. They `and' together: i.e. 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 $ character, for exam-
ple $ISV, and the message causes an application to be started, the application 
will have the environment variable ISV set to whatever value the context slot 
had.

6.1.7	Static Patterns

6.1.7.1	Process and object types compiled with tt_type_comp and residing 
in the types database. 

6.1.7.2	PTYPE {PtypeSyntax}

6.1.7.2.1	ptype - The process type. It must be unique for every 
installation

6.1.7.2.2	start string - How to start the process.

6.1.7.2.3	disposition - none, start, queue, start+queue

6.1.7.2.4	opnum - eases job of receiver

6.1.7.3	OTYPE {OtypeSyntax} - names the ptype of the application that 
manages the object and describes message patterns that pertain to 
the object

6.1.7.3.1	When a ptype is registered by an app, ToolTalk checks 
for otypes that mention the ptype and registers the pat-
terns found in these otypes.

6.1.7.3.2	otid - The object type. An otid must be unique for every 
installation.

6.1.7.3.3	Inheritance - implementation based.

6.1.7.4	Arguments - () = don't care; (void) = none

6.1.7.5	Values - Get filled in with message argument value

6.1.7.6	Contexts - when used in static patterns, they act as wildcards - e.g. 
If a msg has context named FOO with value 45, and the static pat-
tern has a context named FOO, the associated application Will get 
the msg, and it will see 45 as FOO's value.

6.1.7.7	Declaring the ptype - your patterns now exist in memory. - Note: 
multiple declarations by an app of the same ptype are ignored.

6.1.8	Dynamic Patterns {DynamicPatterns}

6.1.8.1	Allocate, fill in, and register, unregister & destroy when done

6.1.8.2	Must do session join for newly registered patterns to be effective or 
have manually added the session to the pattern before registering.

6.1.8.3	Filescope - must specify a file - can't match on any file anywhere.

6.1.8.4	arg_add vs. barg_add vs. iarg_add

6.1.8.4.1	barg_add and iarg_add are basically a quick way of 
doing an arg_add followed by a set of the value

6.1.8.4.2	vtype == "ALL" matches any vtype

6.1.8.4.3	Value == NULL, matches any value

6.1.8.5	Callbacks - tt_pattern_callback_add()

6.1.8.6	Joining multiple sessions - default session and procid

6.1.8.7	Joining files - the name of the file is added to your file-scoped mes-
sage patterns

6.1.8.8	Joining contexts - adds a string value to the context of all patterns

6.1.9	Matching {Matching}

6.1.9.1	TT_HANDLER Point to point requires no matching - it is passed 
directly to the receiver. Note that this means that you can't monitor 
point to point messages since any patterns you register to do so are 
never checked.

6.1.9.2	TT_OBJECT & TT_OTYPE - otype must be filled in for object 
messages, then do PROCEDURE matching

6.1.9.3	TT_PROCEDURE

6.1.9.3.1	Scan list of static sigs (signatures) that have same op, 
collecting lists of observers and potential handlers

6.1.9.3.2	If sig has otype, & it doesn't match => Mismatch (picks 
up scope from otype signature)

6.1.9.3.3	else If sig has no otype & scope doesn't match => Mis-
match.

6.1.9.3.4	If sig has no args and no contexts => Match

6.1.9.3.5	If sig prototype (number, type and mode of args) don't 
match => Mismatch

6.1.9.3.6	Sig.contexts a subset of those in the message => Match

6.1.9.3.7	Save info for any static observers that require queuing. 

6.1.9.3.8	Scan through dynamic patterns, adding to lists of 
observers and potential handlers

6.1.9.3.9	Use ones with op then ones without to form list

6.1.9.3.10	Check reliability, states, class, paradigm (address), han-
dler, handler ptype, scope, object, otype, sender, 
sender_ptype, args, contexts (wildcard or value(s)) 
[mp_s_pattern.cc - Tt_s_pattern::match()]

6.1.9.3.11	Delivery - Send to Observers(observers first since han-
dler could change state), then Handler with best match

6.1.9.3.12	If more than one Handler at `best match', one will be 
chosen arbitrarily (actually/most likely, the most 
recently added handler is used)

6.2	Messages

6.2.1	Message States - Created, Sent, Handled, Failed, Queued, Started, Rejected - 
{MessageStates} Note that you'll never really see (e.g. from a pattern) the 
Created and Rejected states.

6.2.2	Session Scoped Message Flow {SessionMessageFlow}

6.2.2.1	Client builds request message and calls tt_message_send()

6.2.2.2	TTsession finds a handler (let's assume it had to start it based on a 
static pattern).

6.2.2.3	The handlers starts up and does a tt_open(), tt_fd(). This extablishes 
communication to ttsession. Note: the environment variable 
TT_START_TOKEN was set by ttsession when it fired up the han-
dler, so this tt_open also lets ttsession know that this is the handler.

6.2.2.4	The handlers declares it's ptype to ttsession. This causes ttsession to 
basically change all the static patterns for the ptype into dynamic 
patterns. (Note that at this point the patterns are not active yet 
because the handler hasn't joined the session yet.) Handler next 
joins session, activating patterns.

6.2.2.5	TTsession sends a byte down the back channel to let the handler 
know that there's a message waiting.

6.2.2.6	Handler notices activity on the fd, and calls tt_message_receive to 
get the message.

6.2.2.6.1	If the message returned by tt_message_receive has a sta-
tus of TT_WRN_START_MESSAGE the ToolTalk ser-
vice started the process to deliver a message and the 
process must either reply/reject/fail this message (even 
if it is a notice) or use tt_message_accept(). Messages 
for the ptype are blocked until this occurs.

6.2.2.7	Handler does it's processing (or could reject or fail the message if it 
wasn't in the mood to process it for some reason.)

6.2.2.8	Handler returns reply to request

6.2.2.9	TTsession sends a byte down the backchannel to the client to let 
him know that there's a (reply) message waiting for it.

6.2.2.10	Client does a tt_message_receive to get the result.

6.2.2.11	Note: All the while ttsession is honoring observer patterns

6.2.2.12	Note: the client actually receives a message every time its request 
message changes state.

6.2.3	File Scoped Message Flow {FileMessageFlow}

6.2.3.1	When a file scoped pattern is registered, libtt tells the dbserver 
about the file and the session it's registering the pattern in.

6.2.3.2	For notices, libtt checks with the dbserver to find all the sessions 
that have clients who have registered interest in the file, and then 
communicates with all these sessions directly.

6.2.3.3	For requests, libtt checks with the dbserver to find all the sessions 
that have clients who have registered interest in the file, and then 
tells its session the message and the list of other sessions involved. 
The sessions communicate amongst each other to find a handler 
(looking first for a handler in the clients session).

6.2.4	The value of message disposition: At first glance it seems that message dis-
position makes no sense since it seems the disposition specified in the static 
type definition is the disposition that is followed. However, if the message 
specifies the handler ptype (implying there is a static type definition for this 
ptype or the message will fail), and the message does not match any of the 
static signatures, the disposition set in the message will be adhered to (e.g. if 
disposition in the message was TT_START and the ptype specifies a start-
string, it WILL be started.) This effectively allows you to `ram a message 
down somebody's throat' if you know their ptype, and the message your 
sending doesn't match their listed signatures.

6.2.5	Message_status_string is never used by tooltalk itself, and that this message 
component is for use by the applications.

6.2.6	Message status is set by tooltalk only when there is a problem with message 
delivery. At other times it may be set/read in an application dependent man-
ner

6.2.7	When sending a request message, you will be sent a message every time the 
message changes state, regardless of whether you have specified any match-
ing patterns or message callbacks.

6.2.8	tt_mark, tt_release, tt_malloc & tt_free {MemoryMgmt}

6.2.8.1	libtt maintains an internal storage stack. It is from this stack that 
you receive data buffers (e.g. from tt_message_arg_val).

6.2.8.2	Mark and release are a convenient way of freeing everything allo-
cated during some sequence of operations. Release frees everything 
since the corresponding mark.

6.2.8.3	If you don't use mark and release, remember to tt_free the storage 
you get back from libtt calls.

6.2.9	Messages also contain id of sender

6.2.10	Defaults that affect messages & delivery

6.2.10.1	file - set when you join a file. If not file is set in the message, the file 
attribute gets set to the default.

6.2.10.2	procid - set by tt_open - it's how ttsession knows the client

6.2.10.3	ptype - set by tt_ptype_declare

6.2.10.4	session - externally set - determines where messages actually go.

6.2.11	two_session_server example - illustrates one program handling requests 
from two sessions

7.0	Termination

7.1	tt_close - ttsession only closes the current procid, and if that was the last procid to 
close, all other baggage (structures, etc... all the tt structures created since tt_open()) 
are cleaned up/out/destroyed. {Termination}

7.2	What happens if program doesn't call tt_close? - if tt_message_send_on_exit() was 
called previously, then the queued message is sent out before cleanup. Note: tt_mes-
sage_send_on_exit() first appears in ToolTalk 1.1.

8.0	Error Control / Status

8.1	Tt_status, pointers, and integers as return values (TT_OK) {Errors}

8.2	Checking tt_int_error(), tt_pointer_error() => Tt_status

8.3	Tt_status - what's it mean

8.3.1	tt_status_message()

8.3.2	Error message chapter of Reference Manual

8.3.3	Propagation of errors

8.4	tt_error_notify sample files

9.0	Reliability

9.1	ttsession crash {Reliability}

9.1.1	clients will receive TT_ERR_NOMP error status from api calls.

9.1.2	Recent tooltalk versions allow client to recall tt_open to re-establish connec-
tions. 

9.1.3	ttsession is not automatically restarted without some client or user actions.

9.1.4	Thing's that are lost

9.1.4.1	patterns registered by procids in the crashed session

9.1.4.2	outstanding requests from procids in the crashed session

9.1.4.3	messages bequeathed via tt_message_send_on_exit() by procids in 
the crashed session.

9.1.4.4	session props

9.1.4.5	session-queued messages

9.2	rpc.ttdbserverd crash

9.2.1	Maybe no effect at all if inetd starts a new one.

9.2.2	clients may receive TT_ERR_DBAVAIL error status from api calls.

9.2.3	rpc.ttdbserverd maintains and reads in crash recovery logs, so no data from 
the period before the crash is lost

10.0	Security

10.1	ttsession's -a option sets its enforcement level to one of AUTH_UNIX, xauth (see 
xauth(1)), or AUTH_DES (see the Network Interfaces Programmer's Guide).{Secu-
rity}

10.2	rpc.ttdbserver uses AUTH_UNIX security by default, or no security with the -n 
option.

10.3	tt_message_uid() and tt_message_gid() return what ttsession believes to be the uid/
gid of the sender

10.4	Data inside messages could be encrypted, but no special support is provided.

10.5	Not C2 qualified?

11.0	Debugging

11.1	ttsession: {Debugging}

11.1.1	tracing: -t switch at start-up, kill -USR1 <ttsession_pid> to toggle

11.2	rpc.ttdbserved -t <int_from_1_to_10>

11.3	ttsnoop

11.4	ttmon

11.5	Using the debugger / dbx - they use ToolTalk. (running.ttsession.doc)

12.0	Misc. Topics

12.1	Session properties {Misc}

12.2	Versions

12.2.1	1.0, 1.0.1, and 1.0.2 all have virtually the same function. 

12.2.2	All the ports are essentially 1.0.2

12.2.3	ToolTalk 1.1:added contexts; was made MT safe; added ptype_undeclare() 
and tt_message_send_on_exit(); removed dependence on classing engine

12.2.4	ToolTalk 1.1.1 added XDR support, point-to-point and static pattern call-
backs, and a way for an application to dynamically load PTYPEs.

13.0	Common questions

13.1	FAQ

13.1.1	Interapplication communication (session id)

13.1.2	File Scoping (same partition)

13.2	alt.soft-sys.tooltalk
