You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <ji...@zeus.net.au> on 2011/12/29 02:22:30 UTC
Future development plans
1. Run qa and jtreg tests again, confirm there are no regressions.
2. Peer code review, remove some features from new code if necessary,
(eg unimplemented deny, opposite of grant, checked prior to grants).
3. Merge new policy providers and security manager with trunk (I'm
going to need some merge help).
4. Branch for release.
5. Get everyone to test as much as possible to weed out any remaining
bugs.
6. Release.
Other upcoming tasks / features II'd like to see after next release
(other releases may occur before all are implemented):
1. Fix jtreg so it doesn't rely on keytool, update it to use Java 6,
like the rest of the qa suite, rather than being dependent on 5.
2. Allow proxy CodeSource (proxy.jar) to carry advisory permissions,
as previously discussed so clients are aware of what a
permission's code requires, this fits in well with
BasicProxyVerifier.getPermissions(), we can use a custom
CodeSource, created by PreferredClassLoader that contains the
advisory permissions, but does not grant them, that's left up to
the proxy verifier. There might be additional constraints on
granting these permissions, eg server principal.
3. UDT Socket communications, UDT has a 10x performance advantage
over TCP on wide area networks and can traverse NAT routers, using
rendezvous connections (p2p not apple rendezvous) where TCP cannot go.
4. StreamServiceRegistrar - use delayed unmarshalling and stream like
iteration of results (similar to net.jini.space.MatchSet).
5. DNS-SRV Discovery (in addition to current Multicast Discovery) to
find lookup services.
6. DNS-SRV based URL scheme for code base annotations, use
certificates for integrity and identity, rather than the scheme,
so we can change our codebases if we want.
Cheers,
Peter.
Re: Future development plans ; UDT
Posted by Peter Firmstone <ji...@zeus.net.au>.
Simon IJskes - QCG wrote:
> On 29-12-11 13:19, Peter wrote:
>>>> On 29-12-11 02:22, Peter Firmstone wrote:
>>>>>
>>>>> 3. UDT Socket communications, UDT has a 10x performance advantage
>>>>> over TCP on wide area networks and can traverse NAT routers,
>>>>> using
>>>>> rendezvous connections (p2p not apple rendezvous) where TCP
>>>>> cannot
>>>>> go.
>>>>
>>>>
>
> Peter, do you already have a solution for exposing a service in a nat
> lan, and having a client in another nat lan connecting to it? I've
> tried several prototypes for fixing this, and the major problem is
> identitying the endpoint (from within the serverendpoint) in such a
> way, that 2 lans can connect. Most lans run in the 192.168.1/24
> adressing space. Every time i seem to end up with a strong wish to
> remove the dependency on ip adressses from river.
>
> Gr. Sim
>
I don't have a working solution yet, however this is roughly how it
will, when it does:
UDT multiplexes (many connections on one port), it's network address
will have a name, port and socketID, (this minimises the number of ports
a firewall must have, in the UDT java case, 1 per jvm).
Rendezvous mode is when two clients reside behind firewalls, the
protocol supports this, however both clients must try to contact each
other at the same time and it doesn't have anything to coordinate that,
this would need to be synchronised by a public third party.
UDT is based on UDP, some corporate firewall admin's block UDP packets
and it won't work on Symmetric NAT's, however it will work where UDP
STUN connections are possible (alhough it shouldn't need to use STUN).
So for example if a djinn had a public lookup service (PLS), the lookup
service would know the public address and port of it's clients NAT's.
If clients register services with the PLS, the connection will need to
be kept alive to keep the NAT port open (play with lease timeout's),
since UDT multiplexes, service proxy's may use the same NAT port that
has been opened for the registrar, using a different socketID.
It makes sense that the Registrar node could coordinate the connections.
I haven't thought about it much lately, I've been busy finishing off the
policy providers and security manager, but most resources you'll find on
the UDT websites, if you're interested, I could use some help.
Cheers,
Peter.
Re: Future development plans ; UDT
Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 29-12-11 13:19, Peter wrote:
>>> On 29-12-11 02:22, Peter Firmstone wrote:
>>>>
>>>> 3. UDT Socket communications, UDT has a 10x performance advantage
>>>> over TCP on wide area networks and can traverse NAT routers, using
>>>> rendezvous connections (p2p not apple rendezvous) where TCP cannot
>>>> go.
>>>
>>>
Peter, do you already have a solution for exposing a service in a nat
lan, and having a client in another nat lan connecting to it? I've tried
several prototypes for fixing this, and the major problem is identitying
the endpoint (from within the serverendpoint) in such a way, that 2 lans
can connect. Most lans run in the 192.168.1/24 adressing space. Every
time i seem to end up with a strong wish to remove the dependency on ip
adressses from river.
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Future development plans ; UDT
Posted by Peter <ji...@zeus.net.au>.
You can browse the java sockets version here, it's incomplete, I'm working on multiplexing similar to the C++ version.
http://udt-java.svn.sourceforge.net/viewvc/udt-java/udt-java/skunk/
----- Original message -----
> From a quick review I'd say UDTServerSocket has the same issue as UDTSocket.
>
> I'd also say it'd be possible to write adapters for both. There'd be
> some socket options that wouldn't transfer but basics like inputstream
> etc would be no worries. Wiring in support for channels (nio) also
> looks doable.
>
> On 29 December 2011 11:20, Simon IJskes - QCG <si...@qcg.nl> wrote:
> > On 29-12-11 02:22, Peter Firmstone wrote:
> > >
> > > 3. UDT Socket communications, UDT has a 10x performance advantage
> > > over TCP on wide area networks and can traverse NAT routers, using
> > > rendezvous connections (p2p not apple rendezvous) where TCP cannot
> > > go.
> >
> >
> > I've had a look at the java UDT implementation, and currently it is not
> > directly pluggable into river. The UDTSocket and UDTServerSocket are not
> > derived from Socket and ServerSocket.
> >
> > Therefore the UDTSocket cannot be used as a parameter in the
> > javax.net.ssl.SSLSocketFactory.createSocket(...) method used in
> > net.jini.jeri.ssl.SslConnection.establishNewSocket().
> >
> > Either an adaptor for converting a UDTSocket into a Socket needs to be
> > provided, or a new jeri family for TLS connections needs to be build, cloned
> > from net.jini.jeri.ssl where the SSLSocket is replaced by an SSLEngine based
> > construct.
> >
> > The server side possibly has the same problem.
> >
> > Gr. Sim
> >
> > --
> > QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> > Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Future development plans ; UDT
Posted by Dan Creswell <da...@gmail.com>.
>From a quick review I'd say UDTServerSocket has the same issue as UDTSocket.
I'd also say it'd be possible to write adapters for both. There'd be
some socket options that wouldn't transfer but basics like inputstream
etc would be no worries. Wiring in support for channels (nio) also
looks doable.
On 29 December 2011 11:20, Simon IJskes - QCG <si...@qcg.nl> wrote:
> On 29-12-11 02:22, Peter Firmstone wrote:
>>
>> 3. UDT Socket communications, UDT has a 10x performance advantage
>> over TCP on wide area networks and can traverse NAT routers, using
>> rendezvous connections (p2p not apple rendezvous) where TCP cannot
>> go.
>
>
> I've had a look at the java UDT implementation, and currently it is not
> directly pluggable into river. The UDTSocket and UDTServerSocket are not
> derived from Socket and ServerSocket.
>
> Therefore the UDTSocket cannot be used as a parameter in the
> javax.net.ssl.SSLSocketFactory.createSocket(...) method used in
> net.jini.jeri.ssl.SslConnection.establishNewSocket().
>
> Either an adaptor for converting a UDTSocket into a Socket needs to be
> provided, or a new jeri family for TLS connections needs to be build, cloned
> from net.jini.jeri.ssl where the SSLSocket is replaced by an SSLEngine based
> construct.
>
> The server side possibly has the same problem.
>
> Gr. Sim
>
> --
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Future development plans ; UDT
Posted by Peter <ji...@zeus.net.au>.
I've got a skunk implementation that uses java sockets.
I'm working on it.
Peter.
----- Original message -----
> On 29-12-11 02:22, Peter Firmstone wrote:
> > 3. UDT Socket communications, UDT has a 10x performance advantage
> > over TCP on wide area networks and can traverse NAT routers, using
> > rendezvous connections (p2p not apple rendezvous) where TCP cannot
> > go.
>
> I've had a look at the java UDT implementation, and currently it is not
> directly pluggable into river. The UDTSocket and UDTServerSocket are not
> derived from Socket and ServerSocket.
>
> Therefore the UDTSocket cannot be used as a parameter in the
> javax.net.ssl.SSLSocketFactory.createSocket(...) method used in
> net.jini.jeri.ssl.SslConnection.establishNewSocket().
>
> Either an adaptor for converting a UDTSocket into a Socket needs to be
> provided, or a new jeri family for TLS connections needs to be build,
> cloned from net.jini.jeri.ssl where the SSLSocket is replaced by an
> SSLEngine based construct.
>
> The server side possibly has the same problem.
>
> Gr. Sim
>
> --
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Future development plans ; UDT
Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 29-12-11 02:22, Peter Firmstone wrote:
> 3. UDT Socket communications, UDT has a 10x performance advantage
> over TCP on wide area networks and can traverse NAT routers, using
> rendezvous connections (p2p not apple rendezvous) where TCP cannot
> go.
I've had a look at the java UDT implementation, and currently it is not
directly pluggable into river. The UDTSocket and UDTServerSocket are not
derived from Socket and ServerSocket.
Therefore the UDTSocket cannot be used as a parameter in the
javax.net.ssl.SSLSocketFactory.createSocket(...) method used in
net.jini.jeri.ssl.SslConnection.establishNewSocket().
Either an adaptor for converting a UDTSocket into a Socket needs to be
provided, or a new jeri family for TLS connections needs to be build,
cloned from net.jini.jeri.ssl where the SSLSocket is replaced by an
SSLEngine based construct.
The server side possibly has the same problem.
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Future development plans
Posted by Peter Firmstone <ji...@zeus.net.au>.
I almost forgot, setup the Jini TCK in trunk and get it building again too.
Peter Firmstone wrote:
> 1. Run qa and jtreg tests again, confirm there are no regressions.
> 2. Peer code review, remove some features from new code if necessary,
> (eg unimplemented deny, opposite of grant, checked prior to grants).
> 3. Merge new policy providers and security manager with trunk (I'm
> going to need some merge help).
> 4. Branch for release.
> 5. Get everyone to test as much as possible to weed out any remaining
> bugs.
> 6. Release.
>
>
> Other upcoming tasks / features II'd like to see after next release
> (other releases may occur before all are implemented):
>
> 1. Fix jtreg so it doesn't rely on keytool, update it to use Java 6,
> like the rest of the qa suite, rather than being dependent on 5.
> 2. Allow proxy CodeSource (proxy.jar) to carry advisory permissions,
> as previously discussed so clients are aware of what a
> permission's code requires, this fits in well with
> BasicProxyVerifier.getPermissions(), we can use a custom
> CodeSource, created by PreferredClassLoader that contains the
> advisory permissions, but does not grant them, that's left up to
> the proxy verifier. There might be additional constraints on
> granting these permissions, eg server principal.
> 3. UDT Socket communications, UDT has a 10x performance advantage
> over TCP on wide area networks and can traverse NAT routers, using
> rendezvous connections (p2p not apple rendezvous) where TCP
> cannot go.
> 4. StreamServiceRegistrar - use delayed unmarshalling and stream like
> iteration of results (similar to net.jini.space.MatchSet).
> 5. DNS-SRV Discovery (in addition to current Multicast Discovery) to
> find lookup services.
> 6. DNS-SRV based URL scheme for code base annotations, use
> certificates for integrity and identity, rather than the scheme,
> so we can change our codebases if we want.
>
> Cheers,
>
> Peter.
>
>