home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / os / minix / 4917 < prev    next >
Encoding:
Internet Message Format  |  1992-12-14  |  3.3 KB
  1. Path: sparky!uunet!mcsun!Germany.EU.net!urmel.informatik.rwth-aachen.de!gandalf!michael
  2. From: michael@gandalf.moria (Michael Haardt)
  3. Newsgroups: comp.os.minix
  4. Subject: A few remote procedure call questions
  5. Date: Sun, 13 Dec 92 12:17:59 +0100
  6. Organization: An old and gray machine, somewhere in Moria.
  7. Lines: 62
  8. Distribution: world
  9. Message-ID: <921213328@gandalf.moria>
  10. Reply-To: u31b3hs@pool.informatik.rwth-aachen.de (Michael Haardt)
  11. NNTP-Posting-Host: messua.informatik.rwth-aachen.de
  12. Keywords: RPC, remote procedure call
  13.  
  14. A few months ago, there was a nice kernel discussion in this group.  I
  15. read some things about RPC in between, and I like the concept of remote
  16. procedure calls a lot.  However, all I read explained how RPC is used,
  17. but not how it is implemented.
  18.  
  19. I don't like timeouts for RPCs, but having the kernel generate an answer
  20. message if either the addressee is invalid or busy (not listening for
  21. RPC requests).  If the addressed process doesn't listen, it is up to the
  22. caller to send the RPC again or treat it as an error.  Of course that
  23. means that I expect reliable connections.
  24.  
  25. I understood the RPC concept to be synchronous, which means that a
  26. process can be in one of the following states:
  27.  
  28. -  busy
  29. -  listening for RPCs
  30. -  busy with calculating an answer
  31. -  waiting for answer of a sent RPC
  32. -  busy with calculating an answer and waiting for answer of a sent RPC
  33.  
  34. Is that correct?
  35.  
  36. I think that not using RPC queues for non-listening processes would
  37. result in bad performance because RPC are getting sent again and again,
  38. but queues can overflow, and they will do for sure if a process doesn't
  39. intend ever to listen to RPCs.
  40.  
  41. The synchronous concept doesn't allow a process to run in threads and
  42. managing its own queue, because after listening for one RPC it first
  43. has to be answered.  That brought me to the idea of redirecting a call.
  44. That way, a client (a) can run in threads (b,c,...), which all have
  45. ports to the kernel.  Other processes always send RPCs to (a), which
  46. redirects them to (b,c,...) depending on which one is listening.
  47. Redirecting means, that now (a) can again listen, because (b,c,...) will
  48. answer that call.  Sending out a redirected RPC is equivalent to
  49. answering it concerning the above process states.  This method allows a
  50. threaded filesystem to be written, and for each filesystem thread to let
  51. a device driver process answer a call directly back to the client.  That
  52. way, traffic is reduced a lot.
  53.  
  54. Now tell me, did I misunderstood RPC completely, or does the RPC concept
  55. already contain redirection and I only didn't see it, or how is a
  56. threaded filesystem supposed to get implemented?
  57.  
  58. Do already existing systems like Amoeba use queues for calls?  Do they
  59. have threaded filesystems?  What is done with overflowing queues, in
  60. case queues are used?
  61.  
  62. I first want to get these (and perhaps more:) questions answered, if
  63. things turn out not to be too complicated, perhaps I will write a small
  64. kernel only containing process management (create, kill), memory
  65. management (alloc, free) and communication (delivering RPCs)
  66. capabilities to play with it.  Such a microkernel should be very small
  67. and not too hard to write.  To keep things simple for the beginning, I
  68. will not care about routing RPCs in a distributed system yet.
  69.  
  70. Any comments?
  71.  
  72. Michael "wondering about RPC"
  73.  
  74. PS: I know, this isn't related to Minix, but this group is read by
  75.     kernel hackers, so ... :-)
  76.