> Note that I am not sure we correctly test that a second connect() can be
> done, and I am not sure kernel would check that the remote IP and
> destination port is the same.
> Ie what should happen for
> setsockopt(fd, SOL_TCP, TCP_FASTOPEN_CONNECT, &on, 4)
> connect(fd, "1.2.3.4:80")
> connect
From: Wei Wang
Date: Wed, 25 Jan 2017 10:54:50 -0800
>> Yes sorry David, for me it's OK. If Wei runs his whole series of tests
>> on it again, it should be perfect.
>
> I just ran all the TFO related tests with Willy's patch on top of this
> patch series.
> And everything passes.
Great, I'll ap
On Wed, 2017-01-25 at 10:54 -0800, Wei Wang wrote:
> > Yes sorry David, for me it's OK. If Wei runs his whole series of tests
> > on it again, it should be perfect.
>
> I just ran all the TFO related tests with Willy's patch on top of this
> patch series.
> And everything passes.
Note that I am n
> Yes sorry David, for me it's OK. If Wei runs his whole series of tests
> on it again, it should be perfect.
I just ran all the TFO related tests with Willy's patch on top of this
patch series.
And everything passes.
On Wed, Jan 25, 2017 at 9:54 AM, Willy Tarreau wrote:
> On Wed, Jan 25, 2017 a
On Wed, Jan 25, 2017 at 12:22:05PM -0500, David Miller wrote:
> From: Wei Wang
> Date: Wed, 25 Jan 2017 09:15:34 -0800
>
> > Looks like you sent a separate patch on top of this patch series to
> > address double connect(). Then I think this patch series should be
> > good to go.
>
> Indeed, Wil
Hi Wei,
On Wed, Jan 25, 2017 at 09:15:34AM -0800, Wei Wang wrote:
> Willy,
>
> Looks like you sent a separate patch on top of this patch series to address
> double connect().
Yes, sorry, I wanted to reply to this thread after the git-send-email
and got caught immediately after :-)
So as suggest
From: Wei Wang
Date: Wed, 25 Jan 2017 09:15:34 -0800
> Looks like you sent a separate patch on top of this patch series to
> address double connect(). Then I think this patch series should be
> good to go.
Indeed, Willy please give some kind of ACK.
Thanks.
On Tue, Jan 24, 2017 at 10:51:25AM -0800, Eric Dumazet wrote:
> We do not return -1 / EINPROGRESS but 0
>
> Do not call connect() twice, it is clearly not supposed to work.
Yes it is, it normally returns -1 / EISCONN on a regular socket :
EISCONN
The socket is already connect
On Tue, 2017-01-24 at 19:34 +0100, Willy Tarreau wrote:
> Hi Eric,
>
> On Tue, Jan 24, 2017 at 09:44:49AM -0800, Eric Dumazet wrote:
> > I believe there is a bug in this application.
> >
> > It does not check connect() return value.
>
> Yes in fact it does but I noticed the same thing, there's s
On Tue, Jan 24, 2017 at 09:42:07AM -0800, Eric Dumazet wrote:
> On Tue, 2017-01-24 at 09:26 -0800, Yuchung Cheng wrote:
>
> > >
> > > Do you think there's a compelling reason for adding a new option or
> > > are you interested in a small patch to perform the change above ?
> > I like the proposal
Hi Eric,
On Tue, Jan 24, 2017 at 09:44:49AM -0800, Eric Dumazet wrote:
> I believe there is a bug in this application.
>
> It does not check connect() return value.
Yes in fact it does but I noticed the same thing, there's something causing
the event not to be registered or something like this.
On Mon, 2017-01-23 at 22:16 +0100, Willy Tarreau wrote:
> Hi Wei,
>
> first, thanks a lot for doing this, it's really awesome!
>
> I'm testing it on 4.9 on haproxy and I met a corner case : when I
> perform a connect() to a server and I have nothing to send, upon
> POLLOUT notification since I ha
On Tue, 2017-01-24 at 09:26 -0800, Yuchung Cheng wrote:
> >
> > Do you think there's a compelling reason for adding a new option or
> > are you interested in a small patch to perform the change above ?
> I like the proposal especially other stack also uses TCP_FASTOPEN
> https://msdn.microsoft.com
On Mon, Jan 23, 2017 at 11:30 PM, Willy Tarreau wrote:
>
> On Mon, Jan 23, 2017 at 10:59:22AM -0800, Wei Wang wrote:
> > This patch adds a new socket option, TCP_FASTOPEN_CONNECT, as an
> > alternative way to perform Fast Open on the active side (client).
>
> Wei, I think that nothing prevents fro
On Mon, Jan 23, 2017 at 10:59:22AM -0800, Wei Wang wrote:
> This patch adds a new socket option, TCP_FASTOPEN_CONNECT, as an
> alternative way to perform Fast Open on the active side (client).
Wei, I think that nothing prevents from reusin the original TCP_FASTOPEN
sockopt instead of adding a new
On Mon, Jan 23, 2017 at 02:57:31PM -0800, Wei Wang wrote:
> Yes. That seems to be a valid fix to it.
> Let me try it with my existing test cases as well to see if it works for
> all scenarios I have.
Perfect. Note that since the state 2 is transient I initially thought
about abusing the flags pass
On Mon, Jan 23, 2017 at 11:01:21PM +0100, Willy Tarreau wrote:
> On Mon, Jan 23, 2017 at 10:37:32PM +0100, Willy Tarreau wrote:
> > On Mon, Jan 23, 2017 at 01:28:53PM -0800, Wei Wang wrote:
> > > Hi Willy,
> > >
> > > True. If you call connect() multiple times on a socket which already has
> > > c
On Mon, Jan 23, 2017 at 10:37:32PM +0100, Willy Tarreau wrote:
> On Mon, Jan 23, 2017 at 01:28:53PM -0800, Wei Wang wrote:
> > Hi Willy,
> >
> > True. If you call connect() multiple times on a socket which already has
> > cookie without a write(), the second and onward connect() call will return
>
On Mon, Jan 23, 2017 at 01:28:53PM -0800, Wei Wang wrote:
> Hi Willy,
>
> True. If you call connect() multiple times on a socket which already has
> cookie without a write(), the second and onward connect() call will return
> EINPROGRESS.
> It is basically because the following code block in __ine
Hi Wei,
first, thanks a lot for doing this, it's really awesome!
I'm testing it on 4.9 on haproxy and I met a corner case : when I
perform a connect() to a server and I have nothing to send, upon
POLLOUT notification since I have nothing to send I simply probe the
connection using connect() again
On Mon, Jan 23, 2017 at 10:59 AM, Wei Wang wrote:
> From: Wei Wang
>
> This patch adds a new socket option, TCP_FASTOPEN_CONNECT, as an
> alternative way to perform Fast Open on the active side (client). Prior
> to this patch, a client needs to replace the connect() call with
> sendto(MSG_FASTOPE
On Mon, 2017-01-23 at 10:59 -0800, Wei Wang wrote:
> From: Wei Wang
>
> This patch adds a new socket option, TCP_FASTOPEN_CONNECT, as an
> alternative way to perform Fast Open on the active side (client). Prior
> to this patch, a client needs to replace the connect() call with
> sendto(MSG_FASTOP
From: Wei Wang
This patch adds a new socket option, TCP_FASTOPEN_CONNECT, as an
alternative way to perform Fast Open on the active side (client). Prior
to this patch, a client needs to replace the connect() call with
sendto(MSG_FASTOPEN). This can be cumbersome for applications who want
to use Fa
23 matches
Mail list logo
