home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sources / d / 1521 < prev    next >
Encoding:
Text File  |  1993-01-06  |  4.4 KB  |  107 lines
  1. Newsgroups: comp.sources.d
  2. Path: sparky!uunet!paladin.american.edu!howland.reston.ans.net!wupost!cs.utexas.edu!geraldo.cc.utexas.edu!portal.austin.ibm.com!awdprime.austin.ibm.com!linas
  3. From: linas@austin.ibm.com (Linas Vepstas)
  4. Subject: Distributed Processing Package
  5. Originator: linas@boardhead.austin.ibm.com
  6. Sender: news@austin.ibm.com (News id)
  7. Message-ID: <C0Gqtn.16D0@austin.ibm.com>
  8. Date: Thu, 7 Jan 1993 02:56:11 GMT
  9. Reply-To: linas@boardhead.austin.ibm.com
  10. Organization: IBM Graphics Systems
  11. Keywords: MP distributed multi-tasking multi-processing
  12. Lines: 93
  13.  
  14.  
  15.  
  16. Can someone out there help me find a permanent home for some 
  17. distributed multi-processing code?  I have some source I wish to
  18. put into the public domain -- somewhere where people can find it
  19. & get it.  An anon-ftp site would be great!
  20.  
  21. Description
  22. -----------
  23. The package is called "MAY" and implements a basic
  24. message-passing distributed-processing API.  It allows you do
  25. develop programs that execute concurrently on a number of
  26. machines on a network.
  27.  
  28. The API supports basic distributed services & a processor farm. 
  29. The basic services provide a very simple, very easy-to-use
  30. interface to TCP/IP together with a remote server daemon that
  31. allows processes to be started remotely.  The processor farm
  32. provides an equally simple API to allow repetitive work to be
  33. "farmed out" to a number of network nodes.  It has a bunch of
  34. high tech built into it -- high & low watermark FIFO's,
  35. queue-empty alarms, load-balancing, etc. to make sure that 
  36. each network node is busy crunching on something, and
  37. gaurenteeing the shortest possible real-time execution.
  38.  
  39. The basic services include a "create" routine -- sort of like 
  40. a network fork, or rexec -- it starts up program /u/joe/xyz 
  41. on machine abc.whatever.domain.  In addition, it establishes 
  42. a network connection, i.e. a socket, between the parent and 
  43. the child, so that the two can pass messages between one another. 
  44. In addition, there is a "send" routine, a "recevie" routine, a
  45. "terminate" routine, and a routine that the child process can
  46. invoke to get it's parents address.  The basic services are
  47. implemented in both TCP/IP and in UDP/IP.
  48.  
  49. The package comes with documentation & examples.  The processor
  50. farm examples include a fractal drawer, and a ray-tracer
  51. (a modified version of rayshade), displaying into an X11 window
  52. in more-or-less real time (depending on your network bandwidth &
  53. processor speeds).  The package compiles & runs on IBM RT's,
  54. RS/6000's and on SGI boxes. The code is free and unencombered by
  55. funky copyrights.
  56.  
  57. Pro's, Con's & Caveat's
  58. -----------------------
  59. The package was developed to overcome what seemed to be a basic
  60. limitation with RPC's -- the inability to perform asynchornous,
  61. distributed processing.  Prior to development, the Apollo NCS
  62. system was examined, but seemed to be excessively complex.
  63.  
  64. MAY does not support NIDL -- although it probably should.  If
  65. the messages you are passing around contain char's, short's
  66. long's & double's, plan ahead to do some word-alignment/byte
  67. swapping accross different CPU architectures.
  68.  
  69. MAY allows you to launch processes remotely, but does not put
  70. them there.  You have to get them there first, by hand -- I used
  71. ftp, and later, NFS.
  72.  
  73. To perform a MayCreate() (i.e. a remote fork/exec) on a remote
  74. machine, you must have the MAY daemon running on the remote
  75. machine.  I did this by hacking the rc, and later, the inetd
  76. files on the remote machines, so that a reboot didn't force you
  77. to go off & restart the daemons by hand.
  78.  
  79. MAY does not stop to ask you for a password -- it doesn't do ANY
  80. security verification stuff.  And anyone using it can run most
  81. anything executable -- so its a real security hole if you want
  82. to use it in an unfreindly environment.     Adding security
  83. features could make MAY broadly acceptable to the general
  84. computing public.
  85.  
  86. ----------
  87.  
  88. If anyone is interested, please let me know.  I'm tired of
  89. watching my slick technology gather dust & grow old on my
  90. machine.
  91.  
  92. --- linas
  93.  
  94. ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^
  95.     Linas Vepstas                
  96.     Phone: 1-(512)-838-1116
  97.     internet: linas@innerdoor.austin.ibm.com
  98.     Home addr: 1518 Enfield Road, Austin TX, 78703-3424
  99. ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^
  100.  
  101.  
  102. -- 
  103. ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^
  104. You are in a twisty little maze of standards, all conflicting.
  105.  
  106. ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^
  107.