>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 <[email protected]> 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
