home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / alt / softsys / tooltalk / 57 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  4.1 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!male.EBay.Sun.COM!exodus.Eng.Sun.COM!newbirth.Eng.Sun.COM!rja
  2. From: rja@newbirth.Eng.Sun.COM (Robert Allen)
  3. Newsgroups: alt.soft-sys.tooltalk
  4. Subject: Re: ToolTalk questions
  5. Date: 18 Dec 1992 23:44:29 GMT
  6. Organization: Sun
  7. Lines: 74
  8. Message-ID: <lj4oitINN2oo@exodus.Eng.Sun.COM>
  9. References: <1992Dec18.172134.3602@shearson.com>
  10. NNTP-Posting-Host: newbirth
  11.  
  12. In article <1992Dec18.172134.3602@shearson.com> fgreco@shearson.com (Frank Greco) writes:
  13. >
  14. >I'm in the process of creating my first *real* tooltalk-capable
  15. >application and have a few questions that perhaps somebody might
  16. >be able to answer.
  17. >
  18. >1.  Is there a *guarantee* that all observers receive my message?
  19.  
  20.     No.  However, assuming that all the observers are up, and
  21.     your network is up, your rpc.ttdbserverd is up, etc., all
  22.     observers *should* receive the message.  ToolTalk should
  23.     be considered as reliable as Sun RPC.
  24. >
  25. >2.  I cannot seem to get a little tooltalk pgm to communicate
  26. >over a WAN.  There is no common X session or (obviously) common
  27. >process group.  How do I remedy this?
  28.  
  29.     There are several ways you can do this.  First, you can do
  30.     file scoped messaging to a file which is known to both client
  31.     and server ToolTalk program.  However this is somewhat tedious
  32.     if your application doesn't have a real interest in a specific
  33.     file.  The other way to do this is to have the server run a
  34.     process tree session and to, somehow, advertise the default
  35.     session ID of the server to the ttsession the client is running
  36.     under.  This could be stored in a "well known" file that both
  37.     the client and server know about and have access to.  You could
  38.     also use an alternative medium to broadcast the process tree
  39.     session ID.
  40.  
  41.     This is one point which ToolTalk, IMHO, needs further development
  42.     in.  Some talk of additional scopes has been bandied about.  Do
  43.     you have any suggestions in this regard?
  44.  
  45. >3.  The (sparse) examples that I've seen only send simple ints
  46. >among session members.  Does anyone have any examples of sending
  47. >a structure?   Both simple (ie, no ptrs in struct) and a complex
  48. >(ie, ptrs) would be helpful examples.
  49.  
  50.     ToolTalk is primarily designed to send "messages" around.  If
  51.     your application requires sending complex structures around,
  52.     particularly between machines which may have different memory
  53.     architectures, you may want to look at RPC.  A more interesting
  54.     scheme might also be to use ToolTalk to broadcast control 
  55.     information which is then used to invoke other communication
  56.     channels, such as a socket or RPC call.
  57.  
  58.     ToolTalk isn't intended to be a general purpose solution to
  59.     network wide data transfer.  It can however be useful for
  60.     certain bootstrapping issues related to starting sockets
  61.     for example.  It's best used for message passing, although
  62.     there is nothing to keep you from casting an array to a
  63.     structure, loading the structure, and then sending it via
  64.     tt_message_barg_add().  Do I advise doing something like
  65.     this?  Probably not.
  66.  
  67. >4.  My performance tests, informal as they may be, indicate that
  68. >tooltalk is fine for high-level communication (ie, open app, iconify
  69. >app) but seems to be slow and perhaps unusable for things like 
  70. >real-time data feeds.  Can anyone corroborate this?
  71.  
  72.     ToolTalk is a high level interface.  What I find intersting
  73.     about it is to use it precisely as you describe.  Let's
  74.     say you want to open a bunch of sockets between system to
  75.     do bulk data transfer, but you don't want to have to use
  76.     a static file to store the names of all the potential data
  77.     transfer participants.  So, put a ToolTalk interface on all
  78.     the potential participants, and use that interface to pass
  79.     around connection management information.
  80.  
  81.     Currently ToolTalk is not a real-time system, so using it
  82.     for that is likely to be somewhat disappointing.
  83. --
  84. Robert Allen, rja@sun.com        DISCLAIMER: I said it, not my company.
  85.             Samuel Addams: Brewer, Patriot.                                                                    "The right to brew beer is the right to be free!" - me
  86.