fwiw i also brought the TCP_DEFER_ACCEPT problems up the end of last year:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg28916.html
it's possible the final message in that thread is how we should define the
behaviour, i haven't tried the TCP_SYNCNT idea though.
-dean
-
To unsubs
There was no connection reset until I Ctrl-C'd
the server 15 minuets (!) laster.
> A typical tcpdump of what is happening for a tcp_defer_accept timeout of 20
> seconds is :
> [1]08:52:47.480291 IP client.60930 > server.http: S
> 2498995442:2498995442(0) win 5840 0,nop,wsca
Felix von Leitner a écrit :
I am trying to use TCP_DEFER_ACCEPT in my web server.
There are some operational problems. First of all: timeout handling. I
would like to be able to set a timeout in seconds (or better:
milliseconds) for how long the socket is allowed to sit there without
data
From: Felix von Leitner <[EMAIL PROTECTED]>
Date: Fri, 2 Nov 2007 02:33:21 +0100
> I am trying to use TCP_DEFER_ACCEPT in my web server.
You aren't going to reach many Linux kernel networking
exports on this mailing list. Please post your question
instead to [EMAIL PROTECTED], a
I am trying to use TCP_DEFER_ACCEPT in my web server.
There are some operational problems. First of all: timeout handling. I
would like to be able to set a timeout in seconds (or better:
milliseconds) for how long the socket is allowed to sit there without
data coming in. For high load
i was digging around for info on TCP_DEFER_ACCEPT and found this claim in
the thttpd mailing list archive:
> Alexey Kuznestov mentioned to me that on SMP servers, this option may
> not be desired as it creates a new contention point
is this still the case?
i haven't played with it
On Sun, Oct 22, 2000 at 05:33:53PM +0400, [EMAIL PROTECTED] wrote:
> About uglyness. Violations of protocol are ugly. When all
> the things proceed in a legal way undistingushable,
> it is beautiful. 8)
Ok, I'm convinced. The only thing I don't like is that to untrained
observers, the repeated S
Hello!
> Ok, this surely is incorrect. However, sending spurious SYNACK packets
> doesn't seem like the way to solve this problem.
They are _not_ spurious. Connection did not enter ESTABLISHED state.
If it entered this state, we would have no rights to timeout.
It should be closed with FIN etc.
On Sun, Oct 22, 2000 at 04:56:41PM +0400, [EMAIL PROTECTED] wrote:
> Hello!
>
> > Connection established, and I send no data
>
> But why did you set DEFER_ACCEPT then? 8)
I was just experimenting.
> It becomes legal, as soon as we do not enter ESTABLISHED
> state. Your ACK is just ignored and
Hello!
> Connection established, and I send no data
But why did you set DEFER_ACCEPT then? 8)
I explained when it can be used.
> packet. Why would we lose the connection?
Not enter "quit", wait until connection will timeout.
(It is not very soon normally). And look what happens.
Hint: the p
On Sun, Oct 22, 2000 at 04:25:39PM +0400, [EMAIL PROTECTED] wrote:
> Until actively connecting client will send some data,
> service will and must retransmit syn-ack. Otherwise you will lose connection.
I don't see why. This is a trace with my patch applied, can you tell me
what's wrong with it?
Hello!
> The SYN/ACK handshake appears to go well, and telnet reports a connection
> (the daemon doesn't, no data has been sent). However, Linux keeps sending
> SYNs, which keep getting ACKed. I'm not sure if this is desired behavior. It
> appears to be a side effect o
On Sun, Oct 22, 2000 at 02:03:37PM +0200, bert hubert wrote:
> From a userland perspective, it works very well. It just wastes packets.
>
> > Sorry for advertising it as a working feature.
>
> The fix should be easy. I'm looking in to it.
This patch fixes TCP_DEFER_AC
On Sun, Oct 22, 2000 at 11:48:22AM +0200, Andi Kleen wrote:
> > Patch follows beneath. On a related note, I'm not sure if this is right
> > (connecting to a daemon using TCP_DEFER_ACCEPT)
>
> Yes, looks very broken. I guess there was a reason why it was never
> doc
On Sat, Oct 21, 2000 at 09:44:31PM +0200, bert hubert wrote:
> On Sat, Oct 21, 2000 at 08:50:54AM +0200, Andi Kleen wrote:
>
> > Linux 2.4 has the "dataready" filter in form of the (currently undocumented)
> > TCP_DEFER_ACCEPT option.
>
> Patch follows beneat
On Sat, Oct 21, 2000 at 08:50:54AM +0200, Andi Kleen wrote:
> Linux 2.4 has the "dataready" filter in form of the (currently undocumented)
> TCP_DEFER_ACCEPT option.
Patch follows beneath. On a related note, I'm not sure if this is right
(connecting to a daemon u
16 matches
Mail list logo
