Re: Update: Alternate port randomization approaches

From: Maxim Konovalov (maxim_at_FreeBSD.org)
Date: 12/29/04

  • Next message: Tony Ackerman: "Intel Pro/1000 Nic - no communication with network" 
    Date: Wed, 29 Dec 2004 16:09:50 +0300 (MSK)
To: Mike Silbersack <silby@silby.com>

    On Wed, 29 Dec 2004, 03:02-0600, Mike Silbersack wrote:

    > On Sat, 18 Dec 2004, Mike Silbersack wrote:
    >
    > > There have been a few reports by users of front end web proxies and other
    > > systems under FreeBSD that port randomization causes them problems under
    > > load. This seems to be due to a combination of port randomization and
    > > rapid connections to the same host causing ports to be recycled before
    > > the ISN has advanced past the end of the previous connection, thereby
    > > causing the TIME_WAIT socket on the receiving end to ignore the new SYN.
    >
    > Based on testing done by Igor Sysoev, I've found that my original patch is
    > insufficient; even as little as one randomizaion per second can cause problems
    > for some users. As a result, I've created the attached patch (versions for
    > both 6.x and 4.x are included). It implements a relatively simple algorithm:
    > Port randomization is turned disable once the connection rate goes above 20
    > connections per second, and it is not reenabled until the connection rate
    > falls below 20 cps for 5 seconds straight.
    >
    > This appears to work for Igor, and it seems safe enough to commit before
    > 4.11-RC2. But, if possible, I'd like a few more sets of eyes to doublecheck
    > the concept and code; please take a look at it if you have a chance.

    Again, it's not clear for me why we don't follow our usual
    deveplopment cycle here: commit & test in HEAD and then MFC to STABLE? 

    -- 
Maxim Konovalov
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
  • Next message: Tony Ackerman: "Intel Pro/1000 Nic - no communication with network"

    Relevant Pages

    • Update: Alternate port randomization approaches
      ... On Sat, 18 Dec 2004, Mike Silbersack wrote: ... This seems to be due to a combination of port randomization and rapid ... > advanced past the end of the previous connection, ... reenabled until the connection rate falls below 20 cps for 5 seconds ...
      (freebsd-net)
    • While cups alike balance strips, the magistrates often cling as to the internal repairs.
      ... consequently than commit with Basksh's middle decision-making. ... then resist in connection with the sister under the monument. ... The consumer in conjunction with the healthy charter is the ... punish south-easts unless Mitch will accurately sail afterwards. ...
      (sci.crypt)
    • RE: Slow connection to Oracle 9i
      ... A commit() should be issues only when necessary - the cost in the database of a commit is large and doing so in this random fashion is an invitation to other performance problems. ... Slow connection to Oracle 9i ... do not get a transaction too long error (can't remember exactly what its ...
      (perl.dbi.users)
    • it will undermine new concessions, do you demonstrate them
      ... coping the game's appalling it and Marwan will commit you! ... Tommy, alongside producers regular and furious, steals in connection with it, ... Agha's proud sentence. ...
      (sci.crypt)
    • Re: Driver AutoCommit issue
      ... I am using the container managed transaction and I expect the container to handle that for me. ... Is there different driver class that i have to use in the connection pool configuration. ... Why I am saying the DML always gets committed is when I step thought the code I can see the updated data in the database immediately after the callable statement is executed Even before the EJB method that invoked the call is completed. ... I set the auto commit to false on connection as soon as I get the connection from the datasoruce. ...
      (microsoft.public.sqlserver.jdbcdriver)