================================================================================ 
The two_session example illustrates 3 tooltalk concepts:

I.   A single application connecting to more than one session (two_session_server)
     These sessions may be on the same or different machines, it doesn't really 
     matter since the session identifier tells the tooltalk library everything 
     it needs to know about how to connect up to them.

II.  The use of message callbacks. (send_upcase.c)

III. The error handling support (tt_error_notify.*)


================================================================================ 
The two_session_server program Handles the "UpperCase" message in two
different sessions.  The "UpperCase" operation accepts a string and 
returns back the uppercase version of the string.

The send_upcase program accepts a string as a command line argument,
and sends out a tooltalk request to have the string UpperCase(d), and
prints the reply.

tt_error_notify is used by both programs to show any tooltalk errors.

================================================================================ 
To try the programs, perform the following steps.

1. Open a command window, hereafter referred to as cmdA.

2. In cmdA enter: ttsession -p -c 
   (the -p switch causes ttsession to print out its session identifier, 
   and the -c starts a shell underneath the ttsession.  Alternatively, 
   you can omit the -p switch and get the session identifier in the 
   child shell by performing echo $_SUN_TT_SESSION)

3. Open another command window, hereafter referred to as cmdB.

4. In cmdB enter: ttsession -p -c.  
   (If you want to show how tooltalk works across hosts, first rlogin 
    to some other host in this window.)

5. In some other command window cmdC, enter two_session_server, and provide
   it the two session identifiers from steps 2 and 4.  To do this, use
   cut and paste, but be sure to enclose the identifiers in quotes
   so the shell will treat them as two separate args. (Of course you
   could design other ways to get the session ids to two_session_server.)
   Your entry should look something like:
   two_session_server '01 17813 1342177288 1 0 24151 129.144.153.7 2' 
                      '01 17828 1342177289 1 0 24151 129.144.153.7 2'
   Two_session_server is now connected to both sessions and ready to 
   handle UpperCase messages from either.

6. To send a UpperCase message from the session we started in cmdA, 
   enter: send_upcase 'some cmdA string'
   in cmdA.

7. To send a UpperCase message from the session we started in cmdB, 
   enter: send_upcase 'some cmdB string'
   in cmdB.

8. To clean up, quit two_session_server, and type exit
   in both cmdA and cmdB to have the child shells of the ttsessions
   exit (at which point the ttsessions will exit too).

================================================================================ 
SUGGESTED EXCERCISES:

Non code Exercises:

A.  Run ttsnoop under the different sessions to watch the messages that flow.
    Use ttsnoop to manually construct UpperCase messages.
    Use ttsnoop to manually construct point-to-point messages.

B. Turn on the trace for one or both of the ttsessions involved and watch 
   them work. {ps -ef | grep ttsession, then kill -USR1 <ttsession_pid>}

C. Supply the same session id as both arguments to two_session_server, and
   then send a message.  Does this give you any hints about how ttsession
   chooses a handler when more than one are possible?

D. Supply some bogus session ids to two_session_server.  What's happening?

E. Try running one of the ttsessions on a remote host (if you haven't already), 
   and try send_upcase from both hosts.

F. Kill one or both of the ttsessions that two_session_server has connected to.
   What happens?  What could be done?  Could you know what to do?


Non code-modifying Exercises:

G. Examine the code for the programs.  Try to determine the flow of control.
   Are there some message states send_upcase's message callback will never see?
   What's going on in receive_tt_message()?

H. Run the debugger on two_session_server. Set breakpoints at receive_tt_message_s1
   and receive_tt_message_s2, and examine what happens when messages are sent from
   each session.


Code-modifying Exercises:

I. Comment out the return statement of send_upcase's ShowUpperCaseReply function.
   What happens?

J. Modify send_upcase to create and register a pattern to watch for responses
   instead of using a message callback.  How can you know which incoming message
   matches the request you send out?  When would you need such a resolution strategy
   when using callbacks?

K. In two_session_server add the ability to handle a request called "Add" that takes
   an arbitrary number of integer arguments, and replies with the sum.  Try out
   your addition using ttsnoop, or create a new client program 'send_integers', using
   the code for send_upcase as a starting point.

