public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matti Aarnio <matti.aarnio@zmailer.org>
To: Andrew Chan <achan@achan.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: How to tune TCP for heavily loaded sendmail box
Date: Thu, 19 Apr 2001 10:07:21 +0300	[thread overview]
Message-ID: <20010419100721.X805@mea-ext.zmailer.org> (raw)
In-Reply-To: <Pine.LNX.4.21.0104160037230.19394-100000@maelstrom.localhost> <3ADA5C4C.748D0916@home.com> <007d01c0c862$3fa67e40$093d9ecd@outblaze.com>
In-Reply-To: <007d01c0c862$3fa67e40$093d9ecd@outblaze.com>; from achan@achan.com on Thu, Apr 19, 2001 at 07:49:45AM +0800

On Thu, Apr 19, 2001 at 07:49:45AM +0800, Andrew Chan wrote:
> Greetings,
> 
> I am running a relaying sendmail box and I would like it to be able to
> handle up to 600 or so concurrent (incoming or outgoing) connections.
> 
> I tried that and discovered that TONS of incoming connections are stuck at
> SYNC_RECV state. It is like the sendmail box received these port 25
> connection attempts and then didn't know what to do with them.

	Such sockets don't make it to accept() -- the TCP connection
	setup is a three-way handshake, and SYN_RECV is just indication
	of the reception of the first part of it:

	1)  local  <-------  SYN ----------  remote
	2)  local  --------  ACK,SYN ----->  remote
	3)  local  <-------  ACk,ACK ------  remote

	Each of those  SYN_RECV  sockets have done 2, but have never
	heard back.   In normal case the state 3 is reached by 1.5
	times the roundtrip time between the two systems. (Presuming
	symmetric delays.)

	There is finite size queue of sockets that can sit in this
	particular state waiting for full open (3), after which the
	user programs can then get the sockets with  accept().

	It may be so called 'SYN-attack', although it might just as
	well be routing blackhole somewhere.

	Look for documents regarding SYN-Cookies, and how to enable them.
	( I.e. what values mean what at:
		/proc/sys/net/ipv4/tcp_syncookies )

> I suspect I need to tune some of the TCP parameters so that the system can
> handle many short lived TCP connections in an efficent manner. Any pointer
> to this specific issue or general TCP tunning under Linux (2.4.2-ac28
> kernel) will be most appreciated.
> 
> Thanks.
> 
> Andrew

/Matti Aarnio

      reply	other threads:[~2001-04-19  7:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-16  1:25 2.4.3 - Module problems? Matthew W. Lowe
2001-04-15  7:17 ` Jeff Garzik
2001-04-16  1:40   ` Matthew W. Lowe
2001-04-15 12:51 ` Alan Cox
2001-04-16  7:42 ` ecksfantom
2001-04-16  2:43   ` Matthew W. Lowe
2001-04-18 23:49     ` How to tune TCP for heavily loaded sendmail box Andrew Chan
2001-04-19  7:07       ` Matti Aarnio [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010419100721.X805@mea-ext.zmailer.org \
    --to=matti.aarnio@zmailer.org \
    --cc=achan@achan.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox