🚀 go-pugleaf

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