🚀 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)

In article <1992Dec18.172134.3602@shearson.com> fgreco@shearson.com (Frank Greco) writes:
>
>I'm in the process of creating my first *real* tooltalk-capable
>application and have a few questions that perhaps somebody might
>be able to answer.
>
>1.  Is there a *guarantee* that all observers receive my message?

    No.  However, assuming that all the observers are up, and
    your network is up, your rpc.ttdbserverd is up, etc., all
    observers *should* receive the message.  ToolTalk should
    be considered as reliable as Sun RPC.
>
>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?

    There are several ways you can do this.  First, you can do
    file scoped messaging to a file which is known to both client
    and server ToolTalk program.  However this is somewhat tedious
    if your application doesn't have a real interest in a specific
    file.  The other way to do this is to have the server run a
    process tree session and to, somehow, advertise the default
    session ID of the server to the ttsession the client is running
    under.  This could be stored in a "well known" file that both
    the client and server know about and have access to.  You could
    also use an alternative medium to broadcast the process tree
    session ID.

    This is one point which ToolTalk, IMHO, needs further development
    in.  Some talk of additional scopes has been bandied about.  Do
    you have any suggestions in this regard?

>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.

    ToolTalk is primarily designed to send "messages" around.  If
    your application requires sending complex structures around,
    particularly between machines which may have different memory
    architectures, you may want to look at RPC.  A more interesting
    scheme might also be to use ToolTalk to broadcast control 
    information which is then used to invoke other communication
    channels, such as a socket or RPC call.

    ToolTalk isn't intended to be a general purpose solution to
    network wide data transfer.  It can however be useful for
    certain bootstrapping issues related to starting sockets
    for example.  It's best used for message passing, although
    there is nothing to keep you from casting an array to a
    structure, loading the structure, and then sending it via
    tt_message_barg_add().  Do I advise doing something like
    this?  Probably not.

>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?

    ToolTalk is a high level interface.  What I find intersting
    about it is to use it precisely as you describe.  Let's
    say you want to open a bunch of sockets between system to
    do bulk data transfer, but you don't want to have to use
    a static file to store the names of all the potential data
    transfer participants.  So, put a ToolTalk interface on all
    the potential participants, and use that interface to pass
    around connection management information.

    Currently ToolTalk is not a real-time system, so using it
    for that is likely to be somewhat disappointing.
--
Robert Allen, rja@sun.com		DISCLAIMER: I said it, not my company.
		    Samuel Addams: Brewer, Patriot.															        "The right to brew beer is the right to be free!" - me

In article <lj4oitINN2oo@exodus.Eng.Sun.COM> rja@newbirth.Eng.Sun.COM (Robert Allen) writes:
>In article <1992Dec18.172134.3602@shearson.com> fgreco@shearson.com (Frank Greco) writes:
>>
>    It's best used for message passing, although
>    there is nothing to keep you from casting an array to a
>    structure, loading the structure, and then sending it via
>    tt_message_barg_add().  Do I advise doing something like
>    this?  Probably not.

    Note that I base this on personal taste.  It should *function*
    just fine.

>    Let's say you want to open a bunch of sockets between system to
>    do bulk data transfer, but you don't want to have to use
>    a static file to store the names of all the potential data
>    transfer participants.  So, put a ToolTalk interface on all
>    the potential participants, and use that interface to pass
>    around connection management information.

    Of course, you'd still need to somehow advertise ToolTalk session
    IDs...
--
Robert Allen, rja@sun.com		DISCLAIMER: I said it, not my company.
		    Samuel Addams: Brewer, Patriot.															        "The right to brew beer is the right to be free!" - me