Picking an unused port number
Spud
what the heck:
Are there any conventions out there for selecting what port(s) your app
should use for application-specific communication?
Our app runs on multiple servers that must communicate. We're using
http, but can't use port 80 because there is another webserver using it
on each server. (And we don't want to use more IPs than we have to, or
do something ugly like virtual hosts across processes.)
So we have to pick another port number. We could use 8080 like Tomcat,
but there might also be a Tomcat instance running that we don't control.
So, in general, is there any rule you should use when selecting a port
number, other than picking one > 1024?
Martin Gregorie
>
> So, in general, is there any rule you should use when selecting a port
> number, other than picking one > 1024?
>
Look at /etc/services or http://www.iana.org/assignments/port-numbers
and pick one that isn't being used. Usage above 20,000 is fairly sparse.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
Steve W. Jackson
Martin Gregorie <mar...@address-in-sig.invalid> wrote:
> On Wed, 20 Oct 2010 15:02:41 -0500, Spud wrote:
>
> >
> > So, in general, is there any rule you should use when selecting a port
> > number, other than picking one > 1024?
> >
> Look at /etc/services or http://www.iana.org/assignments/port-numbers
> and pick one that isn't being used. Usage above 20,000 is fairly sparse.
That's what we've done with our application. I'd also suggest making it
possible to reconfigure it to another user-configurable port just in
case they happen to be using the one you default to.
--
Steve W. Jackson
Montgomery, Alabama
Nigel Wade
Don't use a "well-known" port which is already assigned by IANA to
another application/protocol. Just because you don't currently use that
application/protocol doesn't mean you won't want to next week. Make it
configurable so you can move it to a different port if you have to.
On UNIX/Linux systems a fairly comprehensive list is available in
/etc/services, also available at the following URL:
http://www.iana.org/assignments/port-numbers.
--
Nigel Wade
Roedy Green
<stevew...@knology.net> wrote, quoted or indirectly quoted someone
who said :
>That's what we've done with our application. I'd also suggest making it
>possible to reconfigure it to another user-configurable port just in
>case they happen to be using the one you default to.
You can make it a system property. If the client needs to modify it,
they can just use a -D command line switch.
--
Roedy Green Canadian Mind Products
http://mindprod.com
Microsoft has a new version out, Windows XP, which according to everybody is the "most reliable Windows ever." To me, this is like saying that asparagus is "the most articulate vegetable ever."
~ Dave Barry
Roedy Green
quoted or indirectly quoted someone who said :
>
>So, in general, is there any rule you should use when selecting a port
>number, other than picking one > 1024?
Some programs let the user choose the port number during the install
process. It can then burn it in to the program in any of a number of
ways.
markspace
> Are there any conventions out there for selecting what port(s) your app
> should use for application-specific communication?
Yes. Let the operating system pick an unused one for you.
> So we have to pick another port number. We could use 8080 like Tomcat,
> but there might also be a Tomcat instance running that we don't control.
If you are going to pick one manually, you MUST have control of the OS
and all ports to assign one. Otherwise, you just really can't. Talk
the administrator and see if he or she will reserve one for you.
> So, in general, is there any rule you should use when selecting a port
> number, other than picking one > 1024?
Don't select ports close to 1024, they're typically used by NAT and
other temporary ports. Talk to the sys-ops, hopefully they'll have a
block of ports that are manually assigned and can give you one out of
that block.
Lew
>> So, in general, is there any rule you should use when selecting a port
>> number, other than picking one> 1024?
Roedy Green wrote:
> Some programs let the user choose the port number during the install
> process. It can then burn it in to the program in any of a number of
> ways.
Excellent point. One such way is
<http://download.oracle.com/javase/6/docs/api/java/util/prefs/package-summary.html>
--
Lew
Nigel Wade
> On 10/20/2010 1:02 PM, Spud wrote:
>
>> Are there any conventions out there for selecting what port(s) your app
>> should use for application-specific communication?
>
>
> Yes. Let the operating system pick an unused one for you.
>
Not very wise for a server/service. How do the clients get to know what
port the operating system allocated to the server when it started?
OTOH, that's exactly why portmapper and other similar services were
developed. To allow a server to listen on whatever port was available,
register that port and the service with portmapper, and then clients can
query the portmapper to locate them. Then along came firewalls...
--
Nigel Wade
Arne Vajhøj
Or a simple properties file.
I have never liked the prefs API.
Arne
Mike Schilling
"Nigel Wade" <nmw-...@ion.le.ac.uk> wrote in message
news:8id1s5...@mid.individual.net...
It's kind of amusing how the most sophisticated networking apps sit upon
something as ancient as IP. Imagine if you were building a registry for
networked services: would you have each one identify itself to the world
solely by a 16-bit integer?
RedGrittyBrick
> It's kind of amusing how the most sophisticated networking apps sit upon
> something as ancient as IP.
It's also kind of amusing how the most sophisticated intellect sits upon
something as ancient as meat.
http://baetzler.de/humor/meat_beings.html
> Imagine if you were building a registry for
> networked services: would you have each one identify itself to the world
> solely by a 16-bit integer?
Its probably more a question of management. If IANA rented out 16-bit
port number registrations by the year and if you lost registration for
any protocol that constituted less than (say) 0.01% of Internet traffic
in a year, the range of "well known port numbers" would probably be
adequate for quite some time.
Anyway, a ridiculous (and increasing?) number of services now sit on a
single port, HTTP, mainly as a way of bypassing uncooperative firewall
administrators? For example, you can have a stupidly large number of
distinct SOAP services sitting on port 80.
On a related note, a 16-bit port number plus a 128-bit IP address† seems
to me to be a address space with sufficient room to swing the occasional
cat. A port-mapper approach makes the limit of less than 65,536 distinct
types of service per single computer somewhat irrelevant.
Just my 2-bits worth.
--
RGB
†V6
Tom Anderson
> On 23/10/2010 03:13, Mike Schilling wrote:
>> It's kind of amusing how the most sophisticated networking apps sit upon
>> something as ancient as IP.
>
> It's also kind of amusing how the most sophisticated intellect sits upon
> something as ancient as meat.
>
> http://baetzler.de/humor/meat_beings.html
There's a rather good short film version of that:
http://www.youtube.com/watch?v=gaFZTAOb7IE
On the subject of portmappers, don't forget good old TCPMUX:
http://en.wikipedia.org/wiki/TCP_Port_Service_Multiplexer
tom
--
I really don't know what any of this shit means, but it looks
impressive. -- zerolives, on YVFC
nathant...@gmail.com
Knute Johnson
--
Knute Johnson
Jerry Stuckle
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================
Eric Douglas
> 8787 is always nice.
This was an ancient thread, but...I've always wondered about port numbers, they seem so random. There's a bunch of examples here all using different numbers.
http://cs.lmu.edu/~ray/notes/javanetexamples/
Knute Johnson
then that separates the easy from the hard.
--
Knute Johnson
Wayne
> On 6/4/2016 11:24 AM, nathant...@gmail.com wrote:
>>> So, in general, is there any rule you should use when selecting a port
>>> number, other than picking one > 1024?
>>
>
> Make it configurable, and > 4095, not 1024.
>
--
Wayne
Jerry Stuckle
can change it when a conflict exists.
Arne Vajhøj
> On 6/6/2016 6:44 PM, Wayne wrote:
>> On 6/4/2016 8:50 PM, Jerry Stuckle wrote:
>>> On 6/4/2016 11:24 AM, nathant...@gmail.com wrote:
>>>>> So, in general, is there any rule you should use when selecting a port
>>>>> number, other than picking one > 1024?
>>>>
>>>
>>> Make it configurable, and > 4095, not 1024.
>>
>> Why?
>>
>
> Ports 0-4095 are reserved.
0-1023 are system ports
1024-49151 are registered ports
49152–65535 are ephemeral ports
80XX port numbers are very frequently used in the Java world.
> And making it configurable means the user
> can change it when a conflict exists.
Arne
Jerry Stuckle
the Java world?
0-4095 are generally considered "reserved" by commonly used protocols.
Others are used by other protocols, but not generally considered "in use".
Arne Vajhøj
> On 6/6/2016 9:28 PM, Arne Vajhøj wrote:
>> On 6/6/2016 8:52 PM, Jerry Stuckle wrote:
>>> On 6/6/2016 6:44 PM, Wayne wrote:
>>>> On 6/4/2016 8:50 PM, Jerry Stuckle wrote:
>>>>> On 6/4/2016 11:24 AM, nathant...@gmail.com wrote:
>>>>>>> So, in general, is there any rule you should use when selecting a
>>>>>>> port
>>>>>>> number, other than picking one > 1024?
>>>>>>
>>>>>
>>>>> Make it configurable, and > 4095, not 1024.
>>>>
>>>> Why?
>>>>
>>>
>>> Ports 0-4095 are reserved.
>>
>> ????
>>
>> 0-1023 are system ports
>> 1024-49151 are registered ports
>> 49152–65535 are ephemeral ports
>>
>> 80XX port numbers are very frequently used in the Java world.
>>
> the Java world?
- they may have been assigned to the Java purpose
- they may have been assigned to a general purpose that is compatible
with Java usage
- they may not have been assigned yet
> 0-4095 are generally considered "reserved" by commonly used protocols.
> Others are used by other protocols, but not generally considered "in use".
Arne
a.laf...@gmail.com
Nigel Wade
some method such as rpcbind, or in the Java world, rmiregistry. These two methods are primarily for registering remote
procedures/methods, but can also be used for simply registering an assigned port to provide a named service.
A client can query portmap or rmiregistry to find out what port a particular service is registered, and listening, on.
The only port numbers which then need to be well defined are those used by portmap or rmiregistry. rpcbind/portmap is
required by NFS and NIS (formerly YP). I use rmiregistry with some of my applications where I need to operate a server
but don't wish to define a fixed port number (to avoid possible future conflicts).
Jerry Stuckle
>> 0-4095 are generally considered "reserved" by commonly used protocols.
>> Others are used by other protocols, but not generally considered "in
>> use".
>
> That is not how IANA looks at it.
>
> Arne
>
>
Knute Johnson
Do you know where I can get more detailed information on how to do that?
I've never played with rmiregistry.
Thanks,
--
Knute Johnson
Nigel Wade
is a good place to start.
This FAQ is something I used to use. The Java version does indicate how long ago it was that I last programmed RMI,
http://docs.oracle.com/javase/1.5.0/docs/guide/rmi/faq.html#netcontact
The code I have was mostly written in Java 1.4, so it's a bit out of date.
In essence, RMI allows you to invoke remote methods on a server without having to worry about Sockets and ports and the
low level nastiness normally associated with client/server communication. You declare your methods, parameters and
return result as normal. The low level socket creation, object serialisation/deserialisation and method invocation is
all taken care of for you.
An RMI server extends some implementation of Remote, and registers it with rmiregistry using Naming or Registry
bind/rebind methods. A client wishing to invoke remote methods on the server uses the Naming or Registry lookup method
to locate the server, and receives a copy of the Remote object. The methods in the Remote object can be invoked just as
if they were methods in a local class in the same JVM. I can't offhand remember why there is the duplication of Naming,
Registry and LocateRegistry.
It's not entirely as simple as that, but it's essentially all there is to it. Apart from classpaths, and locating the
classes. That can be a bit more interesting, especially for the rmiregistry.
Knute Johnson
--
Knute Johnson
Lew
So it's not Arne. It's Jerry Stuckle.
--
Lew
Jerry Stuckle
troll, and not just in this newsgroup.
Lew
> On 6/7/2016 4:46 PM, Lew wrote:
> > On Tuesday, June 7, 2016 at 6:50:15 AM UTC-7, Jerry Stuckle wrote:
> >> On 6/6/2016 11:07 PM, Arne Vajhøj wrote:
> >>>> 0-4095 are generally considered "reserved" by commonly used protocols.
> >>>> Others are used by other protocols, but not generally considered "in
> >>>> use".
> >>>
> >>> That is not how IANA looks at it.
> >>>
> >>> Arne
> >>>
> >>>
> >>
> >> Whatever. You're the expert on EVERYTHING. Trolls always are.
> >
> > The troll is the one who engages in the ad hominem attack, not the person providing valid information.
> >
> > So it's not Arne. It's Jerry Stuckle.
> >
>
> ROFLMAO! I call them as I see them. Arne has repeatedly proven to be a
> troll, and not just in this newsgroup.
You are behaving like a jerk, Jerry.
--
Lew
Jerry Stuckle
around and you can find it out for yourself.
And quite frankly, I learned a long time ago not to worry about what
people like you think of me. My life has been much happier since then.
Arne Vajhøj
Many ports - many reasons.
>>> 0-4095 are generally considered "reserved" by commonly used protocols.
>>> Others are used by other protocols, but not generally considered "in
>>> use".
>>
>> That is not how IANA looks at it.
>
Nor to understand RFC 6335 about pot number ranges:
<quote>
6. Port Number Ranges
TCP, UDP, UDP-Lite, SCTP, and DCCP use 16-bit namespaces for their
port number registries. The port registries for all of these
transport protocols are subdivided into three ranges of numbers
[RFC1340], and Section 8.1.2 describes the IANA procedures for each
range in detail:
o the System Ports, also known as the Well Known Ports, from 0-1023
(assigned by IANA)
o the User Ports, also known as the Registered Ports, from 1024-
49151 (assigned by IANA)
o the Dynamic Ports, also known as the Private or Ephemeral Ports,
from 49152-65535 (never assigned)
Of the assignable port ranges (System Ports and User Ports, i.e.,
port numbers 0-49151), individual port numbers are in one of three
states at any given time:
o Assigned: Assigned port numbers are currently assigned to the
service indicated in the registry.
o Unassigned: Unassigned port numbers are currently available for
assignment upon request, as per the procedures outlined in this
document.
o Reserved: Reserved port numbers are not available for regular
assignment; they are "assigned to IANA" for special purposes.
Reserved port numbers include values at the edges of each range,
e.g., 0, 1023, 1024, etc., which may be used to extend these
ranges or the overall port number space in the future.
In order to keep the size of the registry manageable, IANA typically
only records the Assigned and Reserved service names and port numbers
in the registry. Unassigned values are typically not explicitly
listed. (There are very many Unassigned service names and
enumerating them all would not be practical.)
As a data point, when this document was written, approximately 76% of
the TCP and UDP System Ports were assigned, and approximately 9% of
the User Ports were assigned. (As noted, Dynamic Ports are never
assigned.)
</quote>
Arne
Nigel Wade
make your server application its own rmiregistry, or use an external registry is one is available.
All that's required for RMI to work is that the client knows what port the rmiregistry (with which the RMI server has
registered) is listening on. After that the rest is up to you. You can make your server an RMI server, or just use an
RMI wrapper to deliver the assigned port number to the client, which can then use that port number to connect to a
traditional Socket server. Once RMI is being used you can add as many services to it as you deem necessary.
My main usage for RMI is delivering real-time radar data to the internet. Each data channel from each radar has a
separate RMI server, each of which register with the rmiregistry. When a client wants data from a particular radar it
queries rmiregistry to get a Remote interface to the RMI server. This interface includes the methods for requesting data
from the RMI server.
Personally, I don't trust rmiregistry over the Internet, so rmiregistry is blocked by the firewall for anything other
than local networks. For remote access I use a GenericServlet inside Tomcat which accepts requests, uses rmiregistry to
locate the relevant radar data server, reads the requested data and returns the result as a serialized Java object.
Eric Douglas
Nigel Wade
Why use a web server when you can use an RMI server? It's dynamic, and can be completely contained within your application.
Eric Douglas
> Why use a web server when you can use an RMI server? It's dynamic, and can be completely contained within your application.
RMI may be the easy way to ask for the current port number, though it's also easy to use a web server if you already have one set up, and you just said RMI may not work over the internet - while the web server should work everywhere.
I wrote a socket communication app though I just hard coded a port number because it's just for our small business internal network without much concern for conflict.
Martin Gregorie
> I wrote a socket communication app though I just hard coded a port
> number because it's just for our small business internal network without
> much concern for conflict.
>
programs/processes use a common configuration file. Failing that, a
command line parameter is equally simple. Either makes your system future-
proof against some app or standard finding that it *must* have the port
number - probably because some new standard uses it.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
Lew
> I don't need to prove anything to the likes of you, Lew. Just look
> around and you can find it out for yourself.
> And quite frankly, I learned a long time ago not to worry about what
> people like you think of me. My life has been much happier since then.
I have, as I said and you ignored, followed Arne's posts for many years. Stating relevant facts about which you were wrong is not trolling; it's furthering the knowledge of all participants.
Of course, you are never going to admit that every drop of venom that you spew is anything but the Milk of Human Wisdom. But you'd be the better person if you'd at least be responsible for the statements that you assert as fact. This business of snide innuendo from you is just garbage.
Despite your egotistical ranting, it's not all about you, Jerry.
--
Lew