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: Implementing means to allow NAT-ed clients to provide services [was roadmap]
Date Thu, 04 Feb 2010 10:15:19 GMT
Ok sounds interesting, lets work together, we need both types of 
functionality, one for scalibility and the other for reliability, if NAT 
p2p TCP fails we need to fall back on a routing service.

As soon as the latest release is approved, we're free to work on the 
codebase again.  I've got Concurrent library replacements for Policy, 
Permissions, including a wrapper object for a PermissionCollection that 
allows multi reads, but locks on write (ReentrantReadWriteLock) that I'd 
like to add to the codebase to fix some of the problems Gregg has been 
experiencing with the single thread synchronization of the JAVA platform 
implementations.

In my library, it is advantageous not to add any synchronization code to 
a PermissionCollection (unless it mutates on read), the JAVA 
implementation of Permissions uses synchronisation anyway (albeit 
poorly) so PermissionCollection should have never been required to be 
synchronized.  A Parallel to Vector, ArrayList and the Collections 
libraries.

I also have a Concurrent Weak Hash map utility library.

Cheers,

Peter.

Sim IJskes - QCG wrote:
> Peter Firmstone wrote:
>> I would like to start by implementing the Natblaster technique of 
>> traversing NAT's with TCP, using JAVA.  I'm not 100% how to fit this 
>> in with JERI, however the following classes appear relevant.
>
> For my deployment i'm going to prototype a (Server)Endpoint factory as 
> a jini service. clients behind NAT can expose their services within 
> the scope of this factory. I'm not so worried about the performance.
>
> For me it's the shortest path to fullfill my requirements.
>
> Maybe it works... :-)
>
> Gr. Sim
>


Mime
View raw message