Best TCP port number range for internal applications

NetworkingTomcat

Networking Problem Overview


I work in a place where each of our internal applications runs on an individual Tomcat instance and uses a specific TCP port. What would be the best IANA port range to use for these apps in order to avoid port number collisions with any other process on the server?

Based on http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml, these are the options as I currently see them:

  1. System Ports (0-1023): I don't want to use any of these ports because the server may be running services on standard ports in this range
  2. User Ports (1024-49151): Given that the applications are internal I don't intend to request IANA to reserve a number for any of our applications. However, I'd like to reduce the likelihood of the same port being used by another process, e.g., Oracle Net Listener on 1521.
  3. Dynamic and/or Private Ports (49152-65535): This range is ideal for custom port numbers. My only concern is if this were to happen: >a. I configure one of my applications to use port X
    >b. The application is down for a few minutes or hours (depending on the nature of the app), leaving the port unused for a little while,
    >c. The operating system allocates port number X to another process, for instance, when that process acts as a client requiring a TCP connection to another server. This succeeds given that it falls within the dynamic range and X is currently unused as far as the operating system is concerned, and
    >d. The app fails to start because port X is already in use

Networking Solutions


Solution 1 - Networking

I decided to download the assigned port numbers from IANA, filter out the used ports, and sort each "Unassigned" range in order of most ports available, descending. This did not work, since the csv file has ranges marked as "Unassigned" that overlap other port number reservations. I manually expanded the ranges of assigned port numbers, leaving me with a list of all assigned port numbers. I then sorted that list and generated my own list of unassigned ranges.

Since this stackoverflow.com page ranked very high in my search about the topic, I figured I'd post the largest ranges here for anyone else who is interested. These are for both TCP and UDP where the number of ports in the range is at least 500.

Total 	Start 	End
829		29170	29998
815		38866	39680
710		41798	42507
681		43442	44122
661		46337	46997
643		35358	36000
609		36866	37474
596		38204	38799
592		33657	34248
571		30261	30831
563		41231	41793
542		21011	21552
528		28590	29117
521		14415	14935
510		26490	26999

Source (via the CSV download button):

http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

Solution 2 - Networking

I can't see why you would care. Other than the "don't use ports below 1024" privilege rule, you should be able to use any port because your clients should be configurable to talk to any IP address and port!

If they're not, then they haven't been done very well. Go back and do them properly :-)

In other words, run the server at IP address X and port Y then configure clients with that information. Then, if you find you must run a different server on X that conflicts with your Y, just re-configure your server and clients to use a new port. This is true whether your clients are code, or people typing URLs into a browser.

I, like you, wouldn't try to get numbers assigned by IANA since that's supposed to be for services so common that many, many environments will use them (think SSH or FTP or TELNET).

Your network is your network and, if you want your servers on port 1234 (or even the TELNET or FTP ports for that matter), that's your business. Case in point, in our mainframe development area, port 23 is used for the 3270 terminal server which is a vastly different beast to telnet. If you want to telnet to the UNIX side of the mainframe, you use port 1023. That's sometimes annoying if you use telnet clients without specifying port 1023 since it hooks you up to a server that knows nothing of the telnet protocol - we have to break out of the telnet client and do it properly:

telnet big_honking_mainframe_box.com 1023

If you really can't make the client side configurable, pick one in the second range, like 48042, and just use it, declaring that any other software on those boxes (including any added in the future) has to keep out of your way.

Solution 3 - Networking

Short answer: use an unassigned user port

Over achiever's answer - Select and deploy a resource discovery solution. Have the server select a private port dynamically. Have the clients use resource discovery.

The risk that that a server will fail because the port it wants to listen on is not available is real; at least it's happened to me. Another service or a client might get there first.

You can almost totally reduce the risk from a client by avoiding the private ports, which are dynamically handed out to clients.

The risk that from another service is minimal if you use a user port. An unassigned port's risk is only that another service happens to be configured (or dyamically) uses that port. But at least that's probably under your control.

The huge doc with all the port assignments, including User Ports, is here: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt look for the token Unassigned.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionJuanalView Question on Stackoverflow
Solution 1 - NetworkingDavid VerebView Answer on Stackoverflow
Solution 2 - NetworkingpaxdiabloView Answer on Stackoverflow
Solution 3 - NetworkingBen HydeView Answer on Stackoverflow