Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Reserved network ports
Posted Feb 25, 2010 12:36 UTC (Thu) by hppnq (guest, #14462)
I think this patch would not solve that particular problem. It does not aim to solve the problem that two separate processes might try to grab the same reserved port through bind(reserved_port): it is that of accidental use of a reserved port through bind(whatever_port).
Besides, isn't this trivially solved in userspace, for instance by simply grabbing the desired port -- more complicated solutions that do this can be devised -- and complaining loudly if this fails? Of course there is a small race window, but unless you can tell the kernel that port X should be reserved for process Y, you won't be able to completely rule that out anyway.
(Ironically, that portmapper is not such a bad idea. ;-)
Posted Feb 25, 2010 14:51 UTC (Thu) by mrshiny (subscriber, #4266)
I have this problem on my windows PC at work: Windows assigns misc ports in a range that JBoss expects to be able to bind to, so if I don't start JBoss first it may not start at all. I work around it by shifting JBoss's ports to some other ports which are not allocated right after boot. But this doesn't really solve the problem.
This feature lets me say to the OS that it should never hand out a specific port unless an app requests it. Yes, you have a race if two processes want to open port 80* as a web server, but now you at least don't have to worry about _something else_ opening port 80 by accident and blocking your webserver.
Sounds like a good idea to me.
*(ok, that port isn't usally one of the randomly assigned ones, but it serves an a example)
Posted Feb 25, 2010 17:37 UTC (Thu) by nix (subscriber, #2304)
Posted Feb 25, 2010 23:26 UTC (Thu) by hppnq (guest, #14462)
But sure, if the patch is not too intrusive, it can't really hurt. On somewhat recent Windows systems,
you actually can reserve ports. ;-)
Posted Feb 26, 2010 6:40 UTC (Fri) by dlang (✭ supporter ✭, #313)
The other thing that should be made easier is using a port for more than one thing at a time.
a connection is defined by 4 items, source IP, source port, destination IP, destination port.
a listening service is defined by the destination IP and destination port.
Thus you could have a connection from port 1234 on your local IP to some destination while still having a server listening for new connections on port 1234. The kernel can tell when a packet arrives if it is for an existing connection or not.
the only place this can't be done is for connectionless protocols like UDP, but is it really the best thing to block the port from being used by anything else? or would it be good enough to let an app (or a wrapper for the app, possibly including firewall-like logic in the kernel like IPTables uses) define a connection and deliver return traffic on that connection to one app, while delivering other traffic hitting that port to other app(s)?
even on TCP the inability to re-use ports can be a problem. With the default TCP timeouts you cannot do more than ~16,000 connections/sec before you start running out of ports. If ports could be re-used with different remote points this limit would be ~16,000 connections/sec with a single remote IP/port combination
Posted Feb 26, 2010 13:56 UTC (Fri) by hppnq (guest, #14462)
how would you implement this in userspace without having to change every program (that uses ephemeral ports) on the system? Remember to include closed source and staticly linked programs in your solution.
Just to be clear: you need to reliably bind a specific fixed address in the ip_local_port_range to a socket, where a multitude of other processes may be competing for the same resource. If it is impossible to do this using whatever configuration options the software offers to move the desired port out of ip_local_port_range, or by starting it early enough, or through the use of another layer like inetd or a proxy and/or NAT, I wouldn't rule out admitting defeat and moving it to its own interface or even (virtual) system.
The measures mentioned here need to be considered anyway unless you have good reasons to assume that no other process will attempt to bind(reserved_port), and in any case it seems a bit more reasonable to expect software to honour the concept of an ephemeral port than it is to expect a kernel to facilitate programs that completely ignore it.
Of course, only a fool would run an important service on a fixed ephemeral port without taking additional measures to make sure it is actually the intended service handling the communication.
So to me, the more interesting question would be: what would you do if you had more than one of those programs you mention using the same fixed port number?
Posted Feb 26, 2010 18:29 UTC (Fri) by dlang (✭ supporter ✭, #313)
if you have multiple programs attempting to explicitly use the same port you have problems, but there should be no reason for the explicitly bound ports to conflict with kernel allocated ports.
Right now ip_local_port_range is a single range of ports. This patch allows the admin of the box to tell the kernel to skip over specific ports in that range. This effectivly makes ip_local_port_range be a list of ranges rather than a single range.
the problem is that right now there _are_ no 'additional measures' that a sysadmin can take to make sure that ephemeral port requests don't get this port other than just narrowing the range of available ports to not include that port, but that can drasticly cut the number of ephemeral ports available to the system.
In the cases where I have two services that need to use the same port I add a second IP address to the interface and bind one service to each IP address. but that isn't the case that these patches are addressing.
Posted Feb 26, 2010 19:29 UTC (Fri) by mrshiny (subscriber, #4266)
Seems like an obvious improvement to me with no obvious downside.
Sure there are other problems not addressed by this patch, but I feel it _is_ progress. Heck, just put all the ports in /etc/services in here and you're already off to a good start.
Posted Feb 27, 2010 14:39 UTC (Sat) by nix (subscriber, #2304)
For a while it looked like POHMELFS was just the thing: a faster better
more reliable distributed NFS, with pretty much the same system
administration model ('oops, I want to make this FS networked, bang,
done'). But now Evgeniy has started to move POHMELFS to this elliptics
cloud-based thing, and as far as I can tell this requires you to *recreate
the filesystem* when you want to POHMELFSize it.
I don't *have* a cloud. I have one or two great big servers and I want to
distribute stuff between them and export their filesystems, possibly at
short notice, to a bunch of clients. And NFS is slow and inefficient and
non-POSIX and generally nasty.
Is there anything better? For a while it looked like POHMELFS would be,
but I no longer know. I've been hoping for something better for a couple
of decades now...
Posted Feb 28, 2010 22:18 UTC (Sun) by hppnq (guest, #14462)
I must be starting to sound like I have something against this patch, which is not the case, so I'll
drop it here.
Posted Mar 1, 2010 1:14 UTC (Mon) by dlang (✭ supporter ✭, #313)
Posted Feb 27, 2010 0:18 UTC (Sat) by nlucas (subscriber, #33793)
Posted Feb 27, 2010 0:33 UTC (Sat) by dlang (✭ supporter ✭, #313)
Posted Feb 27, 2010 13:52 UTC (Sat) by nix (subscriber, #2304)
Posted Apr 1, 2012 0:59 UTC (Sun) by foom (subscriber, #14868)
This new kernel functionality is for the much more common case of basically every program that makes outgoing connections (or does a bind with port specified as 0).
So the kernel functionality does not obsolete bindresvport, and bindresvport does not allow doing what the kernel functionality does.
The bindresvport workaround is necessary, because there isn't really any unallocated space < 1024.
The kernel workaround should really not be necessary, since nobody should actually be allocating fixed ports > 32k. Those are reserved for ephemeral allocation, and there's plenty of <32k ports that people could be using instead. But, a glance in /etc/services shows quite a few *official* services with such ports assigned, never mind all the random ports private services might be incorrectly using. So...despite it being terrible that it's necessary, this feature does sound useful.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds