bf71ff62   
   From: rick.jones2@hp.com   
      
   David Schwartz  wrote:   
   > On Mar 1, 5:39?pm, Rick Jones  wrote:   
      
   > > Until Linux's behaviour came around the ass-u-me-ption was that   
   > > the discardability was at layers 4 and below, not between UDP and   
   > > the socket layer.   
      
   > Maybe, but I can't imagine why. It was (at least to everyone I've   
   > interacted with) always clear that UDP datagrams could be discarded if   
   > memory got tight.   
      
   The perils of recollection - I don't recall 4.3ish BSD ever actually   
   *doing* that though.  If memory were tight, 99 times out of 10 the   
   inbound DMA buffer would not have been allocated and the UDP datagram   
   wouldn't have gotten off the NIC to even get to the socket buffer to   
   be dropped later.   
      
   > > (FWIW, I think that was the motivation behind the odd "ENOBUFS"   
   > > return of accept() in HP-UX 11 - because all those pesky   
   > > enterprise customers who were accustomed to a particular behaviour   
   > > - not getting stuck in an accept() call - wanted that maintained)   
   > > HP-UX 11 was an "upgrade" to previous HP-UX versions and so   
   > > backwards compatability to semantics, even those in grey areas of   
   > > what few standards there were were rather important).   
      
   > See my other post on why I can't follow the logic on this. If an   
   > application was specifically coded with this issue in mind, why   
   > wouldn't it just set the socket non-blocking, which is portable and   
   > guaranteed to work by standards? If the intention was to fix code "by   
   > accident", what about code that does the most logical thing when it   
   > gets an "ENOBUFS" error? (These things include load shedding in a   
   > cluster and sleeping and then calling 'recvmsg' again in a non-   
   > clustered environment.)   
      
   "Changing application coding to non blocking is hard, let's lean on   
    the vendor."   
      
   The issue lives at layers 8 and 9 of the model.  The   
   customers/application developers then certainly, perhaps even still   
   today would base their expectations on past behaviour.   
      
   > This also creates a denial of service attack issue in clustered   
   > environments if it can be remotely triggered. If an attacker can   
   > cause an ENOBUFS error on all machines without running them low on   
   > socket resources, he can get every node in a cluster to shed load.   
      
   > I don't see the sense in a fix that only fixes code that just   
   > happens to do the "right" thing on an ENOBUFS and introduces its own   
   > risk of failures, especially if it's a non-portable fix for an issue   
   > that already has a simple portable fix.   
      
   There is what makes technical sense and then there is what at least   
   initially appears to make "business sense."   
      
   rick jones   
   --   
   denial, anger, bargaining, depression, acceptance, rebirth...   
                                        where do you want to be today?   
   these opinions are mine, all mine; HP might not want them anyway... :)   
   feel free to post, OR email to rick.jones2 in hp.com  but NOT BOTH...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)