SCTP for Java

[Alan Bateman]

Florian Weimer wrote:
> :
> I've been wondering for a while if it is possible (with reasonable
> additional effort) to add new socket and socket address classes without
> patching the JDK sources.  Otherwise, you won't get any interoperability
> with existing code, you need to deal with the fine points of concurrent
> close, and you won't get proper thread interruption handling.
>
> Right now, we use a custom, sockets-like class for UNIX domain sockets,
> but it has the listed drawbacks (except that I think I worked around the
> concurrent close issue in a similar way to the JVM).
>
> (Obviously, an out-of-tree approach to new socket types would make it
> easier to experiment.)
>   
This is a good topic. For stream and datagram oriented protocols then it 
would indeed be desirable to allow for communication domains other than 
IP. In theory it should be possible to use a SocketImpl for this but 
there are checks in the Socket API that reject non-InetSocketAddress 
types (see 6402725). Furthermore, the Socket API itself has very IP 
oriented methods so it doesn't gel well with non-IP protocols. As 
regards an "out of tree" approach for experimentation - I'm not sure 
that this would be straightforward as it would require hooks for 
creating the socket and also when translating between the SocketAddress 
implementation and the native socket address type.

FWIW, a while back I prototyped an "in tree" solution for SocketChannel. 
The primary motive was to allow for Sockets Direct Protocol (which uses 
IP addressing) and Unix Domain Sockets (which required a new 
SocketAddress type). This isn't as extensible as what you might be 
looking for but the API did allow the protocol (and optionally the 
protocol family) to be specified when creating the SocketChannel. A 
Protocols class allowed for protocol lookup (essentially a 
getprotobyname equivalent).

-Alan.