Details
-
Improvement
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
River_2.2.0
-
None
-
None
Description
Dan Creswell wrote:
Indeed, I feel there's something slightly broken design-wise in adding a
SocketFactory parameter to LookupLocator.
See the URL basically defines the kind of connectivity (consider http
versus https) and thus the kind of socket used. It would be possible, for
example, to pass a socket factory that produces sockets that aren't
"compatible" with the URL type.
The documentation would suggest there is only one type of URL acceptable:
The syntax of the URL must be that of a hierarchical
URI<http://java.sun.com/j2se/1.4.2/docs/api/java/net/URI.html> with
a server-based naming authority. Requirements for the components are as
follows:
- A scheme of "jini" must be present.
- A server-based naming authority must be present; user-info must
not be present. The port, if present, must be between 1 and 65535
(both included). If no port is specified, a default value of 4160 is
used. - A path if present, must be "/"; *path segment*s must not be present.
- There must not be any other components present.
Which implies a socket factory isn't required because there's only one way
to "do" unicast and it's all taken care of under the covers.
Thus adding a socket factory implies a change to the mechanism for
discovery and support for different kinds of URLs etc.
So, when we added a socket factory, what were we trying to do? That might
then tell us a bit more about the vector of solutions we're looking at.
On 14 November 2012 02:57, Gregg Wonderly <gergg@cox.net> wrote:
> > Of course, the practical matter, is that in this day and age, server port
> > numbers indicate specific types of services for the things in
> > /etc/services. But, really, we should move the whole discovery business
> > away from "socket creation parameters" and into a "mechanism" using an
> > interface or abstract class so that through Configuration, it would be
> > pluggable at deployment.
> >
> > Gregg
> >
> > On Nov 13, 2012, at 6:05 PM, Peter <jini@zeus.net.au> wrote:
> >
>> > > Hi Greg,
>> > >
>> > > LookupLocatorDiscovery uses LookupLocator to find a Registrar, however
> > it only uses the host name and port, it doesn't use LookupLocator to
> > perform discovery.
>> > >
>> > > LookupLocator requires a defined static port, otherwise 4160 is used if
> > no port is defined.
>> > >
>> > > Recently a SocketFactory was added to LookupLocator, however this is
> > only used by the obsolete version 1 discovery in LookupLocator and not by
> > LookupLocatorDiscovery.
>> > >
>> > > LookupLocator is also Serializable, but it's constructed with multicast
> > discovery where the SocketFactory cannot be transferred.
>> > >
>> > > It seems we'd be better off using URI, in fact when LookupLocator is
> > constructed, it uses URI to assist parsing the host name and port.
>> > >
>> > > Instead of mandating Socket we could consider using a jeri Endpoint.
>> > >
>> > > A URI scheme provider could be used for plugging in different schemes to
> > obtain the Endpoint.
>> > >
>> > > This might allow the use of maven provisioning or similar to obtain an
> > unknown scheme or Endpoint.
>> > >
>> > > This would allow plugging in dns-srv URI's and other unknown future
> > protocols for obtaining a registrar proxy.
>> > >
>> > > A default jini://host:port provider can be supplied for backward
> > compatibility.
>> > >
>> > > Thoughts?
>> > >
>> > > Peter.
>> > >
>> > >
>> > > ----- Original message -----
>>> > >>
>>> > >> On Tue, 2012-11-13 at 08:31, Peter Firmstone wrote:
>>>> > >>> Presently LookupLocator is practically a URI of the form
>>>> > >>> "jini://hostname:port"
>>>> > >>>
>>>> > >>> LookupLocator is constructed during multicast discovery at the client.
>>>> > >>>
>>>> > >>> ConstrainableLookupLocator is a subclass that implements constraints.
>>>> > >>>
>>>> > >>> LookupLocatorDiscovery also accepts LookupLocator to perform unicast
>>>> > >>> discovery using constraints.
>>>> > >>>
>>>> > >>> We modified LookupLocator to accept a SocketFactory via a constructor
>>>> > >>> (approx 2 years ago).
>>>> > >>>
>>>> > >>> LookupLocator is built around tcp, but there are obviously many
> > protocols.
>>>> > >>>
>>>> > >>> Any ideas?
>>> > >>
>>> > >> I'm not sure I understand the question. Is there a problem with
>>> > >> LookupLocator?
>>> > >>
>>> > >> Cheers,
>>> > >>
>>> > >> Greg.