All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Nebojsa Miljanovic <neb@alcatel-lucent.com>
Cc: linux-kernel@vger.kernel.org, "Kittlitz,
	Edward (Ned)" <nkittlitz@alcatel-lucent.com>,
	asweeney@alcatel-lucent.com, "Polhemus,
	William (Bart)" <bpolhemus@alcatel-lucent.com>,
	netdev@vger.kernel.org
Subject: Re: SO_REUSEADDR not allowing server and client to use same port
Date: Thu, 28 Feb 2008 21:36:17 +0100	[thread overview]
Message-ID: <20080228203616.GD8953@1wt.eu> (raw)
In-Reply-To: <47C6FA2A.5030302@alcatel-lucent.com>

[cc'd netdev]

On Thu, Feb 28, 2008 at 12:15:06PM -0600, Nebojsa Miljanovic wrote:
> Hello all,
> I have seen similar complaints about this issue before in the list archive, but
> I have not seen any resolution. So, I am posting the question again in hope of
> getting some replies.
> 
> Currently, Linux does not allow reuse of same local port for both TCP server and
> TCP client. I understand that there may be a need to prevent two servers from
> binding to the same local port, but having 1 server and 1 outgoing client use it
> should be allowed. Other Unix like operating systems do allow it.

I've been encountering the need for SO_REUSEPORT as implemented on some BSD
for instance. It allows any process to explicitly permit another one to bind
to the same IP:port provided that it also sets its socket with SO_REUSEPORT.
This is a real requirement when you need to restart a service without any
service disruption.

In the end, I've written a trivial patch for 2.4 (but most likely 2.6 would
use nearly the same one). I noticed that the conflict detection logic already
distinguished between 3 cases: sk->reuse==0, sk->reuse==1, sk->reuse >1.
sk->reuse was set to 1 with SO_REUSEADDR. I simply had to make SO_REUSEPORT
do sk->reuse |= 2 to get everything working as expected.

I don't know yet if it is as easy to do in 2.6, but if there is a possible
acceptance of including this useful feature into mainline, I can try to
work a patch (possibly cleaner than my existing one for 2.4).

Regards,
Willy


  parent reply	other threads:[~2008-02-28 20:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-28 18:15 SO_REUSEADDR not allowing server and client to use same port Nebojsa Miljanovic
2008-02-28 18:30 ` Phil Oester
2008-02-28 20:19 ` Alan Cox
2008-02-28 20:41   ` Willy Tarreau
2008-03-13 19:18   ` Nebojsa Miljanovic
2008-03-15 13:34     ` Alan Cox
2008-03-17 16:43       ` Nebojsa Miljanovic
2008-03-17 17:30         ` Alan Cox
2008-03-17 18:17           ` Nebojsa Miljanovic
2008-03-18  5:48             ` Willy Tarreau
2008-02-28 20:36 ` Willy Tarreau [this message]
2008-02-28 20:44   ` Nebojsa Miljanovic
  -- strict thread matches above, loose matches on Subject: below --
2008-02-28 19:00 Nebojsa Miljanovic

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=20080228203616.GD8953@1wt.eu \
    --to=w@1wt.eu \
    --cc=asweeney@alcatel-lucent.com \
    --cc=bpolhemus@alcatel-lucent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neb@alcatel-lucent.com \
    --cc=netdev@vger.kernel.org \
    --cc=nkittlitz@alcatel-lucent.com \
    /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.