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 <[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
