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
