46a6d357   
   From: lacos@caesar.elte.hu   
      
     This message is in MIME format.  The first part should be readable text,   
     while the remaining parts are likely unreadable without MIME-aware tools.   
      
   On Tue, 26 Oct 2010, David Schwartz wrote:   
      
   > On Oct 25, 12:27 pm, Albert Manfredi  wrote:   
   >   
   >> At the risk of sounding overly pedantic, the socket is usually   
   >> described as a five-tuple, I think. In addition to IP addresses and TC   
   >> ports, there is also the protocol ID.   
   >   
   > Actually, the term socket can also be used to mean a file descriptor   
   > associated with a network connection. In this case, the socket also   
   > includes the process ID and file descriptor index.   
   >   
   > Sadly, the use of the term "socket" is not consistent. For example, if   
   > a process that has a socket for a TCP endpoint fork's, do the two new   
   > processes each have a socket for the same endpoint? Or do the two file   
   > descriptors reference the same socket?   
      
   I think:   
      
   file descriptor -> file description -> file (which is a socket)   
      
   For example, the file descriptor has the file descriptor level flags (eg.   
   F_[SG]ETFD / FD_CLOEXEC), the file description is associated with the file   
   description level flags (eg. F_[SG]ETFL / O_NONBLOCK), and the file (which   
   is a socket for this discussion) is associated with everything else (IP   
   and TCP specific attributes).   
      
   So in case of fork() / dup() / SCM_RIGHTS / etc:   
      
   fd1 (in process A) --> file description --> file (which is a socket)   
                              ^   
                              |   
   fd2 (in process B) -------+   
      
   That is, they will share the O_NONBLOCK setting for example, and further,   
   all SOL_SOCKET / IPPROTO_IP / IPPROTO_TCP level options and the more basic   
   IP/TCP characteristics. (Notably, shutdown() works on "file" (which is a   
   socket for now), and the path to it shouldn't matter.)   
      
   If "file" at the end of the reference chain is a regular file (or a named   
   pipe, or any "fs object"), then it is usually possible to move the   
   confluence one step further to the right (by opening or mapping the file   
   independently, if there is at least one name to it in the filesystem). I   
   believe this is not possible with a TCP socket.   
      
      
   > Even the POSIX documentation is inconsistent. For example:   
   >   
   > "If fildes refers to a socket, close() shall cause the socket to be   
   > destroyed. If the socket is in connection-mode, and the SO_LINGER   
   > option is set for the socket with non-zero linger time, and the socket   
   > has untransmitted data, then close() shall block for up to the current   
   > linger interval until all data is transmitted."   
   >   
   > The first part has to mean that a 'socket' is a file descriptor that   
   > refers to a connection. Because 'close' will not destroy the   
   > connection endpoint if another file descriptor references it, yet this   
   > says the socket will be destroyed on a 'close'. Yet the second part   
   > talks about what happens when you close a connection endpoint, not a   
   > 'socket' by the definition implied by the first sentence.   
      
   I think the quoted section is fixable by replacing "close()" with "the   
   last close()" (as used elsewhere in the standard, IIRC). Or the first part   
   could be reworded like "if fildes is the last reference to a socket". In   
   summary, I think the usage of "fildes", "refers/reference", and "socket"   
   is okay in the above; the missing word is "last".   
      
   This is only to say that IMHO the term "socket" should be interpreted, per   
   default, as the last (rightmost) link in the above chain.   
      
   lacos   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)