river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: Participation
Date Wed, 13 Sep 2017 10:28:55 GMT
Although probably not well known, River 3.0's remote method calls are 
communicated at native socket speed.

I have considered writing deflate endpoints for JERI, which would 
compress and further improve throughput, one case against doing so is, 
when compression is used with encryption, there is a possiblity that an 
attacker may use a side channel attack to break the encryption, by 
causing an endpoint to transmit known data, the attacker can then 
determine the keys.

Of course if we really want to make River attractive to new users, it 
has to be secure, fast and easy to use.

There are many serialization frameworks out there now, the most popular 
are selected because of their speed, but while fast, most are insecure, 
or operate without a security manager.  Now there's one thing for sure, 
no other security manager on the face of this earth will match the speed 
or scalability of River's security manager.

So as security becomes more of an issue, we can breath new life into 
River by addressing our known security issues and ensuring that we also 
achieve optimum performance.



On 12/09/2017 9:57 PM, Peter wrote:
> Thanks Bryan,
> Be good to have a release to address the memory bug (no pun intended).
> Even better will be future binary releases based on Modules.  Services 
> built with modules are so much simpler.  But so no one gets upset, all 
> existing build tools, systems and conventions will continue to work too.
> Cheers,
> Peter.
> On 12/09/2017 6:55 AM, Bryan Thompson wrote:
>> Peter,
>> Just reviewed the release.  My apologies for taking so long to get
>> this done.  It's been a busy time.  Thanks for all the effort to pull
>> this together.
>> Bryan
>> On Fri, Jun 16, 2017 at 12:42 AM, Peter<jini@zeus.net.au>  wrote:
>>> Anyone have some cycles to participate in the release vetting process?
>>> River 3.0.1 is a bug fix release.
>>> Remember if we're unable to continue this project, then we lose the 
>>> ability
>>> to maintain River / Jini and we also lose the legal protections and
>>> visibility of Apache.
>>> Apart from modularity (which lowers technical barriers to entry) and
>>> improved security, I think the most important upcoming feature is IPv6
>>> support, it would be ironic to see River fall over before IPv6 becomes
>>> ubiquitous, given that the deficiencies of IPv4 is likely 
>>> responsible for
>>> Jini's failure to gain widespread adoption.
>>> Note also that in spite of "new features" River remains backward 
>>> compatible
>>> (in the net.jini.* namespace) with earlier releases.  I'm also 
>>> working on a
>>> compatibility layer for easier migration away from com.sun.jini to
>>> org.apache.river namespaces.
>>> We can't do it by ourselves, we need you too.
>>> Regards,
>>> Peter.

View raw message