home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / unix / programm / 5780 < prev    next >
Encoding:
Internet Message Format  |  1992-12-27  |  3.1 KB
  1. Path: sparky!uunet!mcsun!sunic!lunic!eru.mt.luth.se!enterpoop.mit.edu!think.com!sdd.hp.com!wupost!udel!princeton!tex.Princeton.EDU!subbarao
  2. From: subbarao@fc.hp.com (Kartik Subbarao)
  3. Newsgroups: comp.unix.programmer
  4. Subject: Re: Question on daemon's under inetd
  5. Message-ID: <1992Dec27.183029.2343@Princeton.EDU>
  6. Date: 27 Dec 92 18:30:29 GMT
  7. References: <1992Dec24.064005.5831@tigger.jvnc.net> <1992Dec24.161716.7183@Princeton.EDU>
  8. Sender: news@Princeton.EDU (USENET News System)
  9. Reply-To: subbarao@fc.hp.com
  10. Organization: putchar('I'); for (i = 0; i < 3; i++) putchar('E');
  11. Lines: 56
  12. Originator: news@nimaster
  13. Nntp-Posting-Host: tex.princeton.edu
  14.  
  15. Once again, I must flame myself for a hastily submitted article (I had to
  16. get on a plane in 30 minutes)
  17.  
  18. In article <1992Dec24.161716.7183@Princeton.EDU> I wrote:
  19. >In article <1992Dec24.064005.5831@tigger.jvnc.net> aggarwal@tigger.jvnc.net (Vikas Aggarwal) writes:
  20. >>? Can't I reuse the file descr 0 handed to me by 'inetd' ??
  21. >
  22. >You can't issue an accept() on a socket given to you by inetd.
  23. >
  24. >There are two different types of sockets at work here. One type of socket
  25. >is the one connected to the remote end of the connection. It is used as an 
  26. >endpoint of communication, to which you can read and write arbitrary data.
  27. >
  28. >The other type, which I'll call a "server socket", is used to maintain a queue 
  29. >of incoming connections from different hosts to that port. When you issue the 
  30. >listen() call on a socket, it sets the SO_ACCEPTCON flag in it, thus enabling 
  31. >you to accept() on that socket. Writing to or reading from this kind of
  32. >sockets is useless. The only purpose of this socket is to return you
  33. >another socket (from accept()) through which you CAN read and write to the 
  34. >remote host.
  35. >
  36. >Inetd sets up a bunch of these server sockets on the well known ports. When
  37. >an incoming connection from another host is detected, accept() returns
  38. >a socket of the "normal" (read/write type) to inetd, and inetd gives you
  39. >this socket on fd's 0, 1 and 2. 
  40.  
  41. Everything up to here is correct.
  42.  
  43. >Note, this socket is bound to a different TCP
  44. >port than the server socket, so that you can potentially have multiple remote
  45. >hosts accessing your service. 
  46.  
  47. This is bullshit. The reader socket is bound to the same port as the
  48. server socket. As far as the remote host is connected, it's the same
  49. connection. You can still have multiple remote connections accessing your
  50. service since the REMOTE port will be different for each connection.
  51.  
  52. >Here's where the wait/nowait comes in. If you
  53. >specify wait in /etc/inetd.conf, inetd will NOT allow multiple instances of
  54. >your daemon to run. That is, it will wait until the process is terminated
  55. >before it forks off another instance. If you specify nowait, then it will
  56. >fork off as many requests as it can handle, without waiting for any of them
  57. >to finish. Once again, the socket that inetd returns to you is a normal 
  58. >read/write socket, so you cannot accept() on it, even after the connection is 
  59. >closed. 
  60.  
  61. This is correct.
  62.  
  63. >Even if you could, it would be useless, since it is not bound to the 
  64. >well-known port.
  65.  
  66. This is wrong, just as before.
  67.  
  68. Sorry 'bout that folks.  Happy holidays! :-)
  69.  
  70.     -Kartik
  71.