Gregg Wonderly wrote:
On Jan 3, 2013, at 6:58 AM, Peter Firmstone <[email protected]> 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
