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