Timeout for "connect" state sessions needed
Christian Balzer <[email protected]>
| Newsgroups | gmane.mail.perdition.user |
|---|---|
| Organization | FusionGOL |
| Message-ID | <[email protected]> |
Hello and a happy new year, a couple of days ago one of our perdition servers exceeded the 1024 pop3 connections limit configured (normal usage is about 30-50 parallel connections). I turned out that all these connections had been eaten up by some customer trying to pop his email from China and instead of firing off a connection every 2 minutes things seemed to fail on his end and groups of 3-6 parallel connects (which failed in turn again) came hurtling in. We have been using perdition for over 4 years and have a huge customer base with over 1.5 million pop3 connects per day and never seen anything like this, so my guess here is that this is not (purely) a client thing but that the grate(sic) firewall of China is involved, too. Anyways, this is a typical example: --- Jan 7 12:15:10 pp12 perdition[16881]: Connect: 218.1.143.164->203.216.5.113 Jan 7 12:15:10 pp12 perdition[16886]: Connect: 218.1.143.164->203.216.5.113 Jan 7 12:15:10 pp12 perdition[16889]: Connect: 218.1.143.164->203.216.5.113 Jan 7 12:38:19 pp12 perdition[16881]: io_read: read: Connection timed out Jan 7 12:38:19 pp12 perdition[16881]: __token_fill_buffer: error reading input: Connection timed out Jan 7 12:38:19 pp12 perdition[16881]: token_read: token_fill_buffer Jan 7 12:38:19 pp12 perdition[16881]: read_line: token_read Jan 7 12:38:19 pp12 perdition[16881]: pop3_in_get_pw: pop3_in_get_pw: read_line Jan 7 12:38:19 pp12 perdition[16881]: main: protocol->in_get_pw Jan 7 12:38:19 pp12 perdition[16881]: Fatal Error reading authentication information from client "218.1.143.164->203.216.5.113 ": Exiting child --- Aside from being a good starting measure against a DoS attack in general a feature where one could set a timeout for the maximum time that a process is allowed to be in "connect" state (I would set this to 1 minute or less) would be a very welcome addition. The problem I raised in http://lists.vergenet.net/pipermail/perdition-users/2008-February/001973.html would benefit (as in workaround) from such a feature, too. Regards, Christian -- Christian Balzer Network/Systems Engineer NOC [email protected] Global OnLine Japan/Fusion Network Services http://www.gol.com/ https://secure3.gol.com/mod-pl/ols/index.cgi/?intr_id=F-2ECXvzcr6656 ______________________________________________ Perdition-users mailing list [email protected] http://lists.vergenet.net/listinfo/perdition-users