Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #34460 > unrolled thread

Re: Picking an unused port number

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Picking an unused port number nathanturner369@gmail.com - 2016-06-04 08:24 -0700
    Re: Picking an unused port number Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2016-06-04 09:56 -0700
      Re: Picking an unused port number Eric Douglas <e.d.programmer@gmail.com> - 2016-06-06 05:28 -0700
        Re: Picking an unused port number Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2016-06-06 15:40 -0700
          Re: Picking an unused port number Nigel Wade <nmw@ion.le.ac.uk> - 2016-06-07 09:43 +0100
            Re: Picking an unused port number Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2016-06-07 07:43 -0700
              Re: Picking an unused port number Nigel Wade <nmw@ion.le.ac.uk> - 2016-06-07 17:28 +0100
                Re: Picking an unused port number Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2016-06-07 09:40 -0700
                  Re: Picking an unused port number Nigel Wade <nmw@ion.le.ac.uk> - 2016-06-08 10:32 +0100
                    Re: Picking an unused port number Eric Douglas <e.d.programmer@gmail.com> - 2016-06-08 06:45 -0700
                      Re: Picking an unused port number Nigel Wade <nmw@ion.le.ac.uk> - 2016-06-08 15:06 +0100
                        Re: Picking an unused port number Eric Douglas <e.d.programmer@gmail.com> - 2016-06-08 07:36 -0700
                          Re: Picking an unused port number Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-08 18:03 +0000
    Re: Picking an unused port number Jerry Stuckle <jstucklex@attglobal.net> - 2016-06-04 20:50 -0400
      Re: Picking an unused port number Wayne <wayne@nospam.invalid> - 2016-06-06 18:44 -0400
        Re: Picking an unused port number Jerry Stuckle <jstucklex@attglobal.net> - 2016-06-06 20:52 -0400
          Re: Picking an unused port number Arne Vajhøj <arne@vajhoej.dk> - 2016-06-06 21:28 -0400
            Re: Picking an unused port number Jerry Stuckle <jstucklex@attglobal.net> - 2016-06-06 21:45 -0400
              Re: Picking an unused port number Arne Vajhøj <arne@vajhoej.dk> - 2016-06-06 23:07 -0400
                Re: Picking an unused port number Jerry Stuckle <jstucklex@attglobal.net> - 2016-06-07 09:50 -0400
                  Re: Picking an unused port number Lew <lewbloch@gmail.com> - 2016-06-07 13:46 -0700
                    Re: Picking an unused port number Jerry Stuckle <jstucklex@attglobal.net> - 2016-06-07 19:31 -0400
                      Re: Picking an unused port number Lew <lewbloch@gmail.com> - 2016-06-07 17:26 -0700
                        Re: Picking an unused port number Jerry Stuckle <jstucklex@attglobal.net> - 2016-06-07 21:34 -0400
                          Re: Picking an unused port number Lew <lewbloch@gmail.com> - 2016-06-08 13:52 -0700
                            Re: Picking an unused port number Jerry Stuckle <jstucklex@attglobal.net> - 2016-06-08 17:49 -0400
                  Re: Picking an unused port number Arne Vajhøj <arne@vajhoej.dk> - 2016-06-07 21:53 -0400
          Re: Picking an unused port number a.laforgia@gmail.com - 2016-06-07 00:11 -0700

Page 1 of 2  [1] 2  Next page →

#34460 — Re: Picking an unused port number

On Wednesday, October 20, 2010 at 1:02:41 PM UTC-7, Spud wrote:
> This isn't really java-specific, but I've been posting here lately and 
> 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?

[toc] | [next] | [standalone]

#34461

On 6/4/2016 08:24, nathanturner369@gmail.com wrote:
> On Wednesday, October 20, 2010 at 1:02:41 PM UTC-7, Spud wrote:
>> This isn't really java-specific, but I've been posting here lately and
>> 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?
>

8787 is always nice.

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#34493

On Saturday, June 4, 2016 at 12:56:14 PM UTC-4, Knute Johnson wrote:
> 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/

[toc] | [prev] | [next] | [standalone]

#34505

On 6/6/2016 05:28, Eric Douglas wrote:
> On Saturday, June 4, 2016 at 12:56:14 PM UTC-4, Knute Johnson wrote:
>> 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/
>

Any port works until there is a conflict.  It's what you do about it 
then that separates the easy from the hard.

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#34519

On 06/06/16 23:40, Knute Johnson wrote:
> On 6/6/2016 05:28, Eric Douglas wrote:
>> On Saturday, June 4, 2016 at 12:56:14 PM UTC-4, Knute Johnson wrote:
>>> 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/
>>
>
> Any port works until there is a conflict.  It's what you do about it then that separates the easy from the hard.
>

The best way to avoid conflicts is to allow the system to give you an unallocated port and then register that port using 
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).

[toc] | [prev] | [next] | [standalone]

#34536

On 6/7/2016 01:43, Nigel Wade wrote:
> On 06/06/16 23:40, Knute Johnson wrote:
>> Any port works until there is a conflict.  It's what you do about it
>> then that separates the easy from the hard.
>>
>
> The best way to avoid conflicts is to allow the system to give you an
> unallocated port and then register that port using 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).
>

Nigel

Do you know where I can get more detailed information on how to do that? 
  I've never played with rmiregistry.

Thanks,

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#34537

On 07/06/16 15:43, Knute Johnson wrote:
> On 6/7/2016 01:43, Nigel Wade wrote:
>> On 06/06/16 23:40, Knute Johnson wrote:
>>> Any port works until there is a conflict.  It's what you do about it
>>> then that separates the easy from the hard.
>>>
>>
>> The best way to avoid conflicts is to allow the system to give you an
>> unallocated port and then register that port using 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).
>>
>
> Nigel
>
> Do you know where I can get more detailed information on how to do that?  I've never played with rmiregistry.
>

http://docs.oracle.com/javase/tutorial/rmi/index.html
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.

[toc] | [prev] | [next] | [standalone]

#34538

On 6/7/2016 09:28, Nigel Wade wrote:
> On 07/06/16 15:43, Knute Johnson wrote:
>> On 6/7/2016 01:43, Nigel Wade wrote:
>>> On 06/06/16 23:40, Knute Johnson wrote:
>>>> Any port works until there is a conflict.  It's what you do about it
>>>> then that separates the easy from the hard.
>>>>
>>>
>>> The best way to avoid conflicts is to allow the system to give you an
>>> unallocated port and then register that port using 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).
>>>
>>
>> Nigel
>>
>> Do you know where I can get more detailed information on how to do
>> that?  I've never played with rmiregistry.
>>
>
> http://docs.oracle.com/javase/tutorial/rmi/index.html
> 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.
>
>

Thanks Nigel!

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#34562

One more point. The rmiregistry is not necessarily an external application which you have to run separately. You can 
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.

[toc] | [prev] | [next] | [standalone]

#34566

On Wednesday, June 8, 2016 at 5:32:46 AM UTC-4, Nigel Wade wrote:
> One more point. The rmiregistry is not necessarily an external application which you have to run separately. You can 
> 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.

Google "dynamic Java socket port" and you'll find you can just set the port = 0 and Java will assign you the next available port number to avoid conflict.  Then you just need an alternate method (query web server?) to get the current port for the client connection.

[toc] | [prev] | [next] | [standalone]

#34567

On 08/06/16 14:45, Eric Douglas wrote:
> On Wednesday, June 8, 2016 at 5:32:46 AM UTC-4, Nigel Wade wrote:
>> One more point. The rmiregistry is not necessarily an external application which you have to run separately. You can
>> 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.
>
> Google "dynamic Java socket port" and you'll find you can just set the port = 0 and Java will assign you the next available port number to avoid conflict.  Then you just need an alternate method (query web server?) to get the current port for the client connection.
>

Yes, I know how to get a ephemeral port number.

Why use a web server when you can use an RMI server? It's dynamic, and can be completely contained within your application.

[toc] | [prev] | [next] | [standalone]

#34568

On Wednesday, June 8, 2016 at 10:06:23 AM UTC-4, Nigel Wade wrote:
> Why use a web server when you can use an RMI server? It's dynamic, and can be completely contained within your application.

Because a server JVM can talk to a client JVM using sockets if they know what port to connect to, anyone can post a request to a web server to ask for the current port number, and I'm not familiar with RMI?

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.

[toc] | [prev] | [next] | [standalone]

#34572

On Wed, 08 Jun 2016 07:36:12 -0700, Eric Douglas wrote:

> 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.
>
Making it configurable is almost as simple, particularly if related 
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       |

[toc] | [prev] | [next] | [standalone]

#34475

On 6/4/2016 11:24 AM, nathanturner369@gmail.com wrote:
> On Wednesday, October 20, 2010 at 1:02:41 PM UTC-7, Spud wrote:
>> This isn't really java-specific, but I've been posting here lately and 
>> 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?
> 

Make it configurable, and > 4095, not 1024.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#34506

On 6/4/2016 8:50 PM, Jerry Stuckle wrote:
> On 6/4/2016 11:24 AM, nathanturner369@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?

-- 
Wayne

[toc] | [prev] | [next] | [standalone]

#34508

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, nathanturner369@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.  And making it configurable means the user
can change it when a conflict exists.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#34510

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, nathanturner369@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.

That is obvious good.

Arne

[toc] | [prev] | [next] | [standalone]

#34511

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, nathanturner369@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.
> 
> That is obvious good.
> 
> Arne
> 
> 

If 1024-49151 are registered ports, then why would 80xx ports be used in
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".


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#34513

On 6/6/2016 9:45 PM, Jerry Stuckle wrote:
> 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, nathanturner369@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.
>>

> If 1024-49151 are registered ports, then why would 80xx ports be used in
> the Java world?

Many possible reasons:
- 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".

That is not how IANA looks at it.

Arne

[toc] | [prev] | [next] | [standalone]

#34533

On 6/6/2016 11:07 PM, Arne Vajhøj wrote:
> On 6/6/2016 9:45 PM, Jerry Stuckle wrote:
>> 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, nathanturner369@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.
>>>
> 
>> If 1024-49151 are registered ports, then why would 80xx ports be used in
>> the Java world?
> 
> Many possible reasons:
> - 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
>

"May" does not work.  Which is it?

>> 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.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web