home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / protocol / tcpip / 4246 < prev    next >
Encoding:
Text File  |  1992-08-31  |  2.8 KB  |  61 lines
  1. Newsgroups: comp.protocols.tcp-ip
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!stortek!blackcat!pae
  3. From: pae@blackcat.stortek.com (Phil Earnhardt)
  4. Subject: Re: Implementation of Distributed Database in SUN RPC
  5. Message-ID: <1992Aug31.185338.29597@stortek.com>
  6. Sender: usenet@stortek.com
  7. Nntp-Posting-Host: blackcat.stortek.com
  8. Organization: StorageTek, Louisville, CO
  9. References: <1992Aug25.021602.22737@usl.edu> <1992Aug31.010015.1275@decuac.dec.com>
  10. Date: Mon, 31 Aug 1992 18:53:38 GMT
  11. Lines: 48
  12.  
  13. In article <1992Aug31.010015.1275@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes:
  14. >axk7110@usl.edu (Khanna Alok) writes:
  15. >>I am working on implementation of a small model of distributed database.  I
  16. >>am planning to use SUN RPC for communication between different clients and
  17. >>servers.
  18. >
  19. >Unless it's just going to be a toy, good luck. There are two main problems
  20. >with Sun RPC for doing this: a) Unless you're using a multi-threaded RPC
  21. >server, the server will fairly quickly become the bottleneck.
  22.  
  23. Do you really mean multi-threaded here? Most UNIX platforms still lack kernel
  24. support for multi-threading. It sounds like this is a moot issue in this
  25. context.
  26.  
  27. Sun does supply something that looks a lot like multi-threading for its NFS
  28. server. At initialization time, n NFS servers are forked. When idle, all of
  29. the clients are blocked in a read() on the same UDP socket. Aesthetically,
  30. it's ugly, but it does work. Is there some reason that Khanna couldn't use the
  31. same trick in his code? Is this something that real users can't do without
  32. excessive modification?
  33.  
  34. >b) Since RPC does retransmit if it doesn't get an answer "fast enough" in
  35. >case 'a' above, you may get multiple retransmits. The server then blindly
  36. >redoes operations, unless you wind up writing a reliable delivery system, or
  37. >using TCP RPC or something else.
  38.  
  39. Using TCP isn't the worst thing in the world, provided you're not establishing
  40. and tearing down connections on each transaction.
  41.  
  42. >Generally, there are enough problems with using RPC (all fixable) that for
  43. >anything other than a toy, by the time you've fixed them all, you might as
  44. >well have not used RPC.
  45.  
  46. Are you talking about ONC RPC, or all RPCs in general?
  47.  
  48. Netwise's RPC TOOL has certainly addressed the issue of different styles of
  49. dispatching...there are single-threaded dispatchers, multi-processing
  50. dispatchers (forking off a process for new requests) on systems providing
  51. multi-processing, and multi-threaded dispatchers (spawning a new thread for
  52. new requests) on systems providing multi-threading capabilities.
  53.  
  54. RPCs do seem to take about a 2x hit in throughput vs. hard-coding your network
  55. application. If that's important in your application, then don't use RPCs.
  56.  
  57. >mjr.
  58.  
  59. --phil
  60. pae@blackcat.stortek.com
  61.