SCTP for Java

[Florian Weimer]

* Alan Bateman:

[Extensible socket types]

> 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).

Oh, not good.

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

It justs needs a semi-stable interface to create something that is
covered by the general machinery.  A lot of of the SocketAddress
machinery can be avoided if you're just interested in the basic
infrastructure for file descriptor management and interrupt handling
(which is the main reason I'm interested in the existing sockets
framework).

(Portable socket addresses are a bit of a nightmare anyway.)

> 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).

Do you think it would be possible to do this out-of-tree?  I think I
could port my client code to SocketChannel.  (If I require a customized
JDK, it will raise a few eyebrows.)