🚀 go-pugleaf

In article <1992Dec18.172134.3602@shearson.com> fgreco@shearson.com (Frank Greco) writes:

   1.  Is there a *guarantee* that all observers receive my message?

ToolTalk never just drops the message, and all ToolTalk communication is
done with TCP/IP, which is a reliable communication method. (Robert
mentioned that ToolTalk is as reliable as ONC RPC; since ONC RPC is often
done over UDP, I'd say that ToolTalk is *more* reliable than ONC RPC is
often perceived to be.)  

There are scenarios where messages don't get delivered, here's one:

1. Process 1 sends a message, the ttsession process gets it.
2. ttsession pattern matches and discovers process 2 wants it.
3. ttsession notifies process 2 by making tt_fd active.
4. Before process 2 does a tt_message_receive, the ttsession process
   crashes (somebody kills it, the machine it's on loses power, etc.)

For most purposes, you can count on tooltalk messages getting through.
If you need a higher level of reliabily, you probably need a end-to-end
application check anyway (i.e., it's probably not enough to know
that ToolTalk delivered the message, you probably need to verify that
the application on the end actually processed the message.)

   2.  I cannot seem to get a little tooltalk pgm to communicate
   over a WAN.  There is no common X session or (obviously) common
   process group.  How do I remedy this?

Robert responded with some ideas.  It's basically a rendevous problem:
how do the two processes find each other?   For a session scope
message, both processes have to be in the same session so both
processes have to know the session name; for a file scope 
message both processes have to be on machine mounting from the
same NFS file server.  

A quick way to get it just to work in a demo mode is to start a process tree
session on one machine, get the value of the environment variable
_SUN_TT_SESSION there, then setenv _SUN_TT_SESSION on the other machine:

machinea 8% ttsession -c
machinea 1% echo _SUN_TT_SESSION
<gobbledygook>
machinea 2% start_test_program_1 &

machineb 10% setenv _SUN_TT_SESSION "<gobbledygook>"
machineb 11% start_test_program_2

The two programs should connect up to the ttsession on machinea and work.

   3.  The (sparse) examples that I've seen only send simple ints
   among session members.  Does anyone have any examples of sending
   a structure?   Both simple (ie, no ptrs in struct) and a complex
   (ie, ptrs) would be helpful examples.

One typical way of doing this is to create an XDR memory stream and
serialize the structure into a byte array, then send that as a
ToolTalk byte string.  

   4.  My performance tests, informal as they may be, indicate that
   tooltalk is fine for high-level communication (ie, open app, iconify
   app) but seems to be slow and perhaps unusable for things like 
   real-time data feeds.  Can anyone corroborate this?

Yes, ToolTalk is for control integration between applications.  It was not
designed to be high-volume data feed distribution system.  For example,
ToolTalk's multicast messaging is really a software simulation of multicast
-- each receiver gets a copy of the message from ToolTalk.  In a high volume
data feed, you might be pushing the actual capacity of the network, so you'd
want real IP multicasting to cut down the network bandwidth consumed.

   5.  Can anyone compare (Athena) Zephyr to ToolTalk, or am I comparing
   apples and pi-mesons here?

Sorry, know nothing about Zephyr.   

Rich
--
Rich McAllister (rfm@eng.sun.com)