From: ddl@danlan.*com   
      
   In article ,   
   barmar@alum.mit.edu (Barry Margolin) writes:   
   | In article <1355024@news1.IPSWITCHS.CMM>,   
   |  ddl@danlan.*com (Dan Lanciani) wrote:   
   |   
   | > In article ,   
   | > barmar@alum.mit.edu (Barry Margolin) writes:   
   | >   
   | > | I'm not sure how this scenario is possible.  Putty should get an   
   | > | EADDRINUSE error when it tries to bind the socket.  SO_REUSEADDR   
   | > | shouldn't override this case (it allows you to bind a socket while there   
   | > | are established sockets using the port, but it shouldn't allow you to   
   | > | bind a socket while there's a listening socket).   
   | >   
   | > SO_REUSEPORT, however, will allow totally duplicate bindings on   
   | > "modern" systems.  One of the early rounds of multicast enhancements   
   | > for the BSD stack changed the semantics of tcb matching (and thus of   
   | > SO_REUSEADDR) to allow for totally duplicate bindings.  This broke   
   | > things.  IIRC, SO_REUSEPORT showed up as the alternative with slightly   
   | > different semantics from the "modern" version.  There was so much   
   | > confusion that some applications may just use both in hopes of getting   
   | > the least restrictive behavior.   
   |   
   | I was under the impression that SO_REUSEPORT was only applicable to UDP,   
      
   I don't know about "applicable" in an academic sense, but functionally   
   it works on stream sockets and allows exactly the situation the original   
   poster described--at least as of the last FreeBSD system I checked.   
      
   | and maybe just multicast.   
      
   That's another interesting question.  IIRC the original multicast patches   
   used a different path for actual multicast traffic.  This path was able   
   to duplicate packets and deliver them to multiple datagram sockets bound   
   to a particular port.  The path for unicast packets did not handle this;   
   thus, while you could bind multiple sockets to the same port/address, only   
   one would receive a given unicast packet.  This caused confusion.   
      
   | There's no such thing as multicast TCP,   
   | AFAIK, so which should TCB matching have to consider this case?   
      
   TCP and UDP used (and probably still use) common matching code.  That's   
   why the original multicast patches broke TCP servers that used SO_REUSEADDR   
   but did not want multiple instances of themselves running.  (It would also   
   break UDP servers that similarly desired exclusion, but I don't think they   
   typically set SO_REUSEADDR since they weren't as worried about lingering   
   connections.)  SO_REUSEPORT provided the necessary semantics for multicast   
   while letting SO_REUSEADDR go back to its original function.  Unfortunately,   
   it took a while for the API to settle down and there may have been a time   
   when SO_REUSEPORT was required to get the original SO_REUSEADDR semantics.   
   Applications that try to be portable may simply be setting them both.   
      
   				Dan Lanciani   
   				ddl@danlan.*com   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)