3 ms·

Interesting. It seems like one potential hazard is that bonafide port conflicts are not detected. If SO_REUSEPORT is preferred for performance reasons, and mos

Interesting. It seems like one potential hazard is that bonafide port conflicts are not detected. If SO_REUSEPORT is preferred for performance reasons, and most/all servers are using it, then starting up a server that uses the same port as an existing service becomes a silent error. It could even work as expected for a while (since the kernel gets to arbitrarily decide what port to deliver incoming requests to) only to intermittently fail later.

geocar 13y ago
I can't imagine people will start using SO_REUSEPORT by default, since the "performance reasons" are a happy accident of having a hint (that the process wants wakeups distributed across all CPUs). I'd rather get that hint in another way- perhaps by sharing an epollfd with multiple processes. I would however like SO_REUSEPORT to run experiments: Right now we use iptables/tc to direct some traffic at "new versions" of some of our systems so we can run tests with live data, but connection tracking for localhost is lame. I'd much rather use SO_REUSEPORT.
wicknicks 13y ago
I imagine production servers would run monitoring processes to remove such "listening bugs".
MertsA 13y ago
The second process would have to be run under the same user for that to happen though so a real production system would probably never be impacted by this but what would be nice is a flag to restrict the port to children of a particular PID or just lock it to one particular PPID.
ikeepforgetting 13y ago
Listening to the same port requires processes with the same uid.
rbanffy 13y ago
> then starting up a server that uses the same port as an existing service becomes a silent error. Only if it has the same uid as the other one. It'd also be trivial to check whether the other processes listening to your port are "friendly" (as in "you don't want both Apache and Nginx listening on port 80").
- cbr 13y ago
  Having Apache and Nginx both listening on port 80 might be an interesting way to A/B test them.

geocar 13y ago

I can't imagine people will start using SO_REUSEPORT by default, since the "performance reasons" are a happy accident of having a hint (that the process wants wakeups distributed across all CPUs). I'd rather get that hint in another way- perhaps by sharing an epollfd with multiple processes. I would however like SO_REUSEPORT to run experiments: Right now we use iptables/tc to direct some traffic at "new versions" of some of our systems so we can run tests with live data, but connection tracking for localhost is lame. I'd much rather use SO_REUSEPORT.

wicknicks 13y ago

I imagine production servers would run monitoring processes to remove such "listening bugs".

MertsA 13y ago

The second process would have to be run under the same user for that to happen though so a real production system would probably never be impacted by this but what would be nice is a flag to restrict the port to children of a particular PID or just lock it to one particular PPID.

ikeepforgetting 13y ago

Listening to the same port requires processes with the same uid.

rbanffy 13y ago

> then starting up a server that uses the same port as an existing service becomes a silent error. Only if it has the same uid as the other one. It'd also be trivial to check whether the other processes listening to your port are "friendly" (as in "you don't want both Apache and Nginx listening on port 80").

cbr 13y ago
Having Apache and Nginx both listening on port 80 might be an interesting way to A/B test them.