From: Christoph Paasch <cpaasch@apple.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: netdev@vger.kernel.org, Ian Swett <ianswett@google.com>,
Leif Hedstrom <lhedstrom@apple.com>,
Jana Iyengar <jri.ietf@gmail.com>
Subject: Re: [RFC 0/2] Delayed binding of UDP sockets for Quic per-connection sockets
Date: Wed, 31 Oct 2018 22:07:14 -0700 [thread overview]
Message-ID: <3F5491C5-7F64-4325-9D3B-6592F8EDFF33@apple.com> (raw)
In-Reply-To: <74393778-62e8-76f5-3bfc-ae280b407278@gmail.com>
> On Oct 31, 2018, at 10:04 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
>> On 10/31/2018 08:50 PM, Christoph Paasch wrote:
>>
>> What we had here is that we wanted to let a server initiate more than 64K
>> connections *while* binding also to a source-IP.
>> With TCP the bind() would then pick a source-port and we ended up hitting the
>> 64K limit. If we could do an atomic "bind + connect", source-port selection
>> could ensure that the 4-tuple is unique.
>>
>> Or has something changed in recent times that allows to use the 4-tuple
>> matching when doing this with TCP?
>
>
> Well, yes, although it is not really recent (this came with linux-4.2)
>
> You can now bind to an address only, and let the sport being automatically chosen at connect()
Oh, I didn’t knew about this socket option. Thanks :-)
Christoph
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=90c337da1524863838658078ec34241f45d8394d
>
next prev parent reply other threads:[~2018-11-01 14:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-31 23:26 [RFC 0/2] Delayed binding of UDP sockets for Quic per-connection sockets Christoph Paasch
2018-10-31 23:26 ` [RFC 1/2] net: Add new socket-option SO_DELAYED_BIND Christoph Paasch
2018-10-31 23:26 ` [RFC 2/2] udp: Support SO_DELAYED_BIND Christoph Paasch
2018-11-01 0:53 ` [RFC 0/2] Delayed binding of UDP sockets for Quic per-connection sockets Eric Dumazet
2018-11-01 3:50 ` Christoph Paasch
2018-11-01 5:04 ` Eric Dumazet
2018-11-01 5:07 ` Christoph Paasch [this message]
2018-11-01 5:08 ` Eric Dumazet
2018-11-01 5:17 ` Eric Dumazet
2018-11-01 17:58 ` Leif Hedstrom
2018-11-01 18:21 ` Eric Dumazet
2018-11-01 21:51 ` Willem de Bruijn
2018-11-01 22:11 ` Christoph Paasch
[not found] ` <CAKcm_gNZqgRGRj2J5yJDsavHsoaeXtozrbGp+TmAj_DRsCUOLQ@mail.gmail.com>
[not found] ` <CACpbDccs6WmLCknpu2GLMMBnkHwS4apsr3Z3sAKt4Ch_2HPwgg@mail.gmail.com>
2018-11-04 18:58 ` Eric Dumazet
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=3F5491C5-7F64-4325-9D3B-6592F8EDFF33@apple.com \
--to=cpaasch@apple.com \
--cc=eric.dumazet@gmail.com \
--cc=ianswett@google.com \
--cc=jri.ietf@gmail.com \
--cc=lhedstrom@apple.com \
--cc=netdev@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.