river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: LookupLocator and ServiceRegistrar
Date Fri, 04 Jan 2013 12:28:41 GMT
Gregg Wonderly wrote:
> On Jan 3, 2013, at 6:58 AM, Peter Firmstone <jini@zeus.net.au> wrote:
>
>   
>> Gregg Wonderly wrote:
>>     
>>> I too use static locator configuration because I am usually one of the administrators
across a VPN connection, and my other users are remote users, not local to the multicast TTL.
>>>
>>> I wonder if we shouldn't think about a pluggable system something like URLStreamHandler.
 That is, an abstract class that has pluggable protocol handlers which could be added to the
system via configuration, or programmatically via a security based authorization.  Then, we
can use LookupLocator, but just move to a multi-protocol lookup facility.
>>>  
>>>       
>> Currently we're restricted to jini://host:port URI syntax in LookupLocator, although
we have various options for discovery, these are goverened by constraints, but then you have
the problem of the client and server being configured with different constraints and unicast
discovery protocols.
>>     
>
> I don't see such a restriction since there is a LookupLocator(String) constructor.  That
string can convey anything, and the history of "jini:" is just history, not a requirement.
 People using the other constructors get "jini:" behaviors.  The getRegistrar(…) methods
just need to use a pluggable protocol discovery/lookup function, and then return a ServiceRegistrar
implementation.   Whether or not that is a "remote" reference or a "proxy service" is a detail
for the protocol provider.
>
>   

LookupLocatorDiscovery uses the host and port fields from LookupLocator, 
it doesn't use getRegistrar(), although ConstrainableLookupLocator 
overrides getRegistrar(), but it too uses the host and port fields from 
LookupLocator. 

The host and port fields are parsed from a url string using URI during 
construction.

Any protocol other than jini:// throws a MalformedURLException.


>> We already have a number of different discovery protocol options, it would be nice
if LookupLocator reflected this.
>>     
>
> What are you imagining to be different?
>   
Unicast Discovery Protocols:
Plain text discovery v1 & v2.
Kerberos
SSL

For all these the URI scheme is still jini://host:port

It's up to clients and servers to set constraints and these may not 
match.  There's also a migration issue for people with Discovery V1 
deployments.

The serialized form of LookupLocator, is simply:

 /**
     * The name of the host at which to perform discovery.
     *
     * @serial
     */
    private final String host;
    /**
     * The port number on the host at which to perform discovery.
     *
     * @serial
     */
    private final int port;

No invariant checks are performed during deserialization only during 
object construction.

Scheme, userInfo, path, query and fragment are missing.

Although it could be argued that not all of these fields are important.

Implications of additional fields:

   1. Information is lost when deserialized in previous versions.
   2. State may be incorrect after deserialization eg some scheme
      foo://bar will be treated as jini://bar
   3. Doesn't work with existing multicast protocols.

Partial Solution:

   1. If using a scheme other than jini, store the entire URI in the
      host string. 
   2. New schemes will cause an error in older versions, but existing
      jini scheme's will continue to work, data will not be lost if
      re-serialized - good.
   3. Check total size doesn't exceed multicast packet limit.

The rest would take some working out.

Implement UnicastDiscoveryServer, UnicastDiscoveryClient and implement 
your own SocketFactory, or choose from one of the existing discovery 
options?

The class that creates the sockets for all discovery protocols (except 
for LookupLocator), is com.sun.jini.discovery.internal.MultiIPDiscovery

Sim was using a custom SocketFactory for LookupLocator with discovery 
v1, the best place to enable this would be MultiIPDiscovery, this class 
is not Serializable, it's only task is to perform socket creation for 
UnicastDiscovery version 1 or 2 with constraint support, this would be 
the right place to put a SocketFactory, provided by configuration, or 
perhaps an SPI.

All other discovery protocols are tunnelled over the sockets that 
MultiIPDiscovery provides.  So if you want to get around firewalls this 
is the place to do so, then you can have any of the existing protocols 
like SSL tunneled through.

The client not knowing which protocol the server's using isn't the end 
of the world, but it sure would be useful to help the client figure out 
which discovery protocol to use.

Perhaps that could be appended as a URI query or fragment.

Cheers,

Peter.
>> LookupLocator is often generated by way of a URI string found during multicast discovery
or from configuration, a string would also make sense for DNS-SRV.
>>     
>
> I generate lookup locator from/in configuration.  Even through I do enable multicast
discovery, unicast is also happening, and I've always managed multiple discoveries using a
ServiceID->ServiceItem (well with my deferred unmarshalling, it might not be ServiceItem)
map.
>
>   
>> A handler sounds like a good idea, Sim and I were discussing something like that
recently for RiverClassLoader.  Perhaps something using an SPI interface might be appropriate,
the URI scheme used to lookup up a suitable provider.
>>     
>
> Yes, this is what I am thinking along the lines of.
>
> Gregg
>
>   
>


Mime
View raw message