I finally had the chance to look through the org.apache.river name
change work Dennis Reedy has done, it all looks very impressive, he's
even taken the time to tidy up the qa suite. I haven't had time to run
any tests or look at the jtreg test suite, I promise I'll make some time
in the near future. Before we release this code there is an opportunity
to tidy up the org.apache.river name space even further. In the Jini
days, com.sun.jini.* was implementation code, it wasn't part of the Jini
public API, should we now use org.apache.river.* for this purpose? There
is some new public api, in org.apache.river.api.* and at the time new
implementation code was being placed into org.apache.river.impl.* and
now the com.sun.jini.* namespace has been moved to org.apache.river.*.
Should we consider placing the new api in the net.jini.* namespace? It's
worth looking at the javadoc as most of the new classes are package
private. There are also discovery constraints in the implementation
namespace that should be moved into the public api in my opinion, thoughts?
IPv6, for River, this is big, IPv6 has auto network configuration,
powerful multicast abilities, IPSec and no need for NAT. IPv6 is going
to allow our existing discovery protocols to work over the internet.
The examples project looks promising, I like how Greg Trasuk has
structured the examples into api, server and clients, Greg has done a
lot of work to tidy this up. Our existing example code is relatively
old, I did notice some bad practices by current standards as a
consequence. If we want to reduce our support burden, we should
encourage new users to use best practise.
The issue that stuck out the most was letting 'this' escape during
construction. All River service implementations now implement the
Starter interface to avoid letting 'this' escape during construction,
however since there are a number of downstream “Container” projects and
there was controversy surrounding the start method; if someone wants to
propose something less controversial for user examples, please do so,
hopefully it won't upset anybody still clinging to unsafe publication.
On the topic of “Letting 'this' escape”, because readObject methods
behave like constructors, the jvm performs a final freeze after the
readObject method completes, however there are a number of places where
River lets 'this' escape during deserialization, I did have some
solution options for this, including a better way to deserialize...
I try not to discuss River security after another developer raised
concerns it was scaring off new developers. I'm going to take the
liberty to discuss security and performance briefly.
Some points:
*
IPv6 will enable River to traverse the internet, easily.
*
IPv6 is plug and play – autoconfiguration of network devices.
*
River is well positioned for the internet of things, but needs IPv6.
*
IPv4 NAT is pretty much what killed the Jini iot tech 20 years
ago, as Jini was distributed, not centralised, web services have
grown up around this centralised model.
*
River security isn't ready, our crypto protocols need updating and
proxy trust is currently flawed.
The issue with proxy trust:
*
We can discover a lookup service securely.
*
We can't connect to services securely, service proxy's are
downloaded and deserialized before trust is established.
Don't despair, the security issues are easily fixed.
Back in the early days, Jini used RMI and RMI used skeletons and stubs.
The stubs had to be downloaded, so you always had codebase downloads.
Now, codebase downloads aren't always required, but the lookup service
implementation, is still designed around codebase downloads.
When security was enhanced in Jini 2.0, we were given the concept of a
bootstrap proxy, which is just a reflective proxy that doesn't require a
codebase download. So what does River do, it downloads a codebase,
deserializes a service proxy and then requests a bootstrap proxy from
it. At this point in time the river client authenticates the service,
then River asks the bootstrap proxy for a TrustVerifier instance to
check the service proxy, permissions are dynamically granted (but how do
we know what permissions are required?) and method constraints are
applied. This is called proxy preparation and it's a configuration
concern, as are the exporters. Yep this is a complex processs.
How could this flaw be fixed without impacting the client?
Easy, the lookup service shouldn't contain the service proxy, only the
bootstrap proxy. Guess what, big performance increase, just like delayed
codebase downloads, thank you Gregg Wonderly, for identifying and
trailblazing that path at least a decade ago.
During proxy preparation (a process determined by configuration),
instead of asking the service proxy for a bootstrap proxy, the lookup
service should only contain the bootstrap proxy and clients obtain the
service proxy from it, after authentication, constraints are applied,
permissions granted to the proxy and the process is complete. This is
much simpler than our current proxy trust establishment. Less
serialization overhead, less network traffic, more performance. A
configuration flag could restore the old behaviour of course.
The client is none the wiser, it still receives a fully prepared and
constrained proxy. All River services already implement
ServiceProxyAccessor, although part of the start package, it's an
interface that provides access to the service proxy.
We only need a new Exporter (easy) that creates the bootstrap proxy and
ensures it doesn't implement any interfaces that would require a
codebase download.
Then when a service is registered with a lookup service, Reggie obtains
the bootstrap proxy from the exported service proxy in the client jvm.
It also means the entire process is simpler, developers no longer need
to learn the complex TrustVerifier process as it becomes an Endpoint and
system concern.
Thoughts?
Regards,
Peter.
