================================================================================ 
The ttsend and ttreceive programs illustrate basic tooltalk concepts:

I.   Connecting to the tooltalk service.

II.  Creating and sending a message.

III. Creating and registering a pattern.

IV.  Receiving a message.

V.   Closing up connections to tooltalk.


================================================================================ 
ttsend:  When the slider is moved, the broadcast_value function is called.  This
function creates a notice, and adds to it (as an argument) the integer value
denoting its slider position.  It then sends this message to the toolttalk service
for broadcast.

ttreceive: After initial opening of connection to the tooltalk service, the program
sets up the windows notifier to call the function receive_tt_message whenever
there is an incoming tooltalk message.  Next it creates a pattern to observe
SliderValue messages.  When a message arrives, the receive_tt_message function gets
called.  
================================================================================ 
To try the programs, perform the following steps.

1. From a command window, start a ttsend and a ttreceive as background processes.

2. Move the slider in the ttsend window, and watch what ttreceive does.

3. Try starting some more ttsend and ttreceive programs and watch what
   happens when moving ttsend sliders.

4. To clean up, quit all the ttsend and ttreceive programs.

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

Non code Exercises:

A.  Run ttsnoop to watch the messages that flow.
    Use ttsnoop to manually construct Slider_Value messages.
        Try sending both requests and notices - what happens?

B. Turn on the trace for the ttsession involved and watch 
   it work. {ps -ef | grep ttsession, then kill -USR1 <ttsession_pid>}

C.  Use ttsnoop to construct a point-to-point message to one of the receivers.
   (hint: ttsession trace output shows procids)  What can you see now with 
   the snooper?

D. Use multiple ttsessions to create multiple send/receive groups (i.e. groups of
   senders/receivers that don't see each others messages).

E. Set the environment variable _SUN_TT_SESSION to something bogus (e.g. junk),
   then run ttsend.   What happens?

F. Run send and receive under a ttsession, then kill the ttsession - what happens?


Non code-modifying Exercises:

G. Examine the code for the programs.  Try to determine the flow of control.
   Does ttsend really need my_procid?  How come there's no call to tt_fd?
   What would happen if ttsend were sending out requests instead of notices?

H. Run the debuggers on ttsend and/or ttreceive. Set breakpoints at broadcast_value
   and/or receive_tt_message.  Send a Slider_Value message from ttsnoop, but use 
   an 'add' argument instead of an iadd.  What's happening in ttreceive?

I. Try running one of the ttsends on one host and ttreceive on another. (Hint: use
   -p switch of ttsession)


Code-modifying Exercises:

J. Change the pattern in ttreceive to category TT_HANDLE.  Now what happens when 
   you send a Slider_Value notice?  What else might you want changed in ttreceive now?
   What about the arguments?  What about replies?

K. Create different variants of ttsend & ttreceive: ttsendA & ttreceiveA,
   and ttsendB & ttreceiveB that can use the same ttsession message passer, but have
   no crosstalk between them (i.e. A variants should not respond to B variants and 
   vice-versa). (Hint: try using contexts - for extra credit, make the variant
   of the ttreceive or ttsend depend on an environment variable.)

 
