Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Knute Johnson Newsgroups: comp.lang.java.programmer Subject: Re: Picking an unused port number Date: Tue, 7 Jun 2016 09:40:52 -0700 Organization: A noiseless patient Spider Lines: 64 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 7 Jun 2016 16:40:52 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="fc10d1b501433caa198830294d826923"; logging-data="29447"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19ULemUdWbgT7cCqK2kQGkK" User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 In-Reply-To: Cancel-Lock: sha1:vklTHVhiI4yGDDEmPhOA36e3vWo= Xref: csiph.com comp.lang.java.programmer: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