home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v21 / 135 < prev    next >
Internet Message Format  |  1990-12-05  |  3KB

  1. From std-unix-request@uunet.uu.net  Thu Sep 27 13:32:13 1990
  2. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3.     id AA03547; Thu, 27 Sep 90 13:32:13 -0400
  4. Posted-Date: 27 Sep 90 01:08:56 GMT
  5. Received: by cs.utexas.edu (5.64/1.76) 
  6. From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  7. Newsgroups: comp.std.unix
  8. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  9. Message-Id: <547@usenix.ORG>
  10. References: <543@usenix.ORG> <544@usenix.ORG> <546@usenix.ORG>
  11. Sender: jsq@usenix.ORG
  12. Organization: IR
  13. X-Submissions: std-unix@uunet.uu.net
  14. Date: 27 Sep 90 01:08:56 GMT
  15. Reply-To: std-unix@uunet.uu.net
  16. To: std-unix@uunet.uu.net
  17.  
  18. Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  19.  
  20. In article <546@usenix.ORG> henry@zoo.toronto.edu (Henry Spencer) writes:
  21. > I'm afraid I don't understand:  a program that is trying, simultaneously,
  22. > to open several different connections is somehow not doing several things
  23. > at once?
  24.  
  25. Correct. Between sending an open request out upon the network and
  26. receiving an acknowledgment, the program is not doing anything at all
  27. related to that connection.
  28.  
  29. Let me be more specific. Host X, on the Internet, wants to know the
  30. time. It decides to ask ten hosts around the network for the time.
  31.  
  32. In reality, here's what happens in X's interaction with Y: X sends to Y
  33. a request for a connection on port 37. Pause. Y acknowledges. Y sends a
  34. few bytes back and closes the connection. During the pause, X is doing
  35. nothing.
  36.  
  37. But there are several Y's. So X sends out ten requests in sequence. It
  38. waits. Each Y responds at some point; X collects the responses in
  39. whatever order they come. Where is it doing any two things at once, let
  40. alone several?
  41.  
  42. > The program *is* doing several things at once, to wit opening several
  43. > connections at once.
  44.  
  45. ``Opening a connection'' is really an abuse of the language, because a
  46. network open consists of at least two steps that may come arbitrarily
  47. far apart. Let me replace it by phrases that honestly describe what the
  48. computer is doing: ``sending out a connection request, and later
  49. accepting an acknowledgment.''
  50.  
  51. Now, out of the requests and acknowledgments going on, what two are
  52. happening at once? None of them. You're being misled by the terminology.
  53. ``Opening a connection'' is such a common phrase that we automatically
  54. accept it as a description of reality, and consequently believe that it
  55. is well described by open(); but it isn't. The time between request and
  56. acknowledgment is filled with nothing but a void.
  57.  
  58.   [ combining threads with a one-step open() ]
  59. > This is a far more natural model of what's
  60. > going on than forcing everything into one sequential process, and a
  61. > much better match for the semantics of the problem.
  62.  
  63. No. It is not an accurate description of what is going on, since an
  64. open() is implicitly local while a network open is not.
  65.  
  66. Abstract imagery aside, though, ``naturalness'' is really defined by how
  67. a concept helps a programmer. BSD's non-blocking connect() and select()
  68. for connection acceptance, while perhaps not the best-named system
  69. calls, are extremely easy to work with. They adapt perfectly to network
  70. programming problems because they accurately reflect what the system is
  71. doing. In contrast, forking off threads and kludging around a local
  72. open() is unnecessarily complex and would make network programming
  73. unnecessarily difficult. For me that condemns it as an unnatural,
  74. inaccurate reflection of reality.
  75.  
  76. ---Dan
  77.  
  78. Volume-Number: Volume 21, Number 135
  79.  
  80.