A new socket implementation / api

[Noctarius]

Am 25.08.2011 16:57, schrieb Alan Bateman:
> Noctarius wrote:
>> :
>> What does it mean?
>> Well you create a ServerSocket and tell him to listen for incoming
>> client request (bind()). At the other side you open a ClientSocket
>> to connect to the already opened server.
>> Now you can give both sockets a listener to retrieve events like
>> "clientConnected", "clientDisconnected", "dataReceived", ... by
>> adding such a listener with "listen(...)".
>>
> Have you looked at the asynchronous I/O API that is in jdk7.
So I did a look at the AsynchronousSocketChannel /
AsynchronousServerSocketChannel. I guess that's what you meant and
well it looks nice and a bit more what I was thinking of, but not
completely.

This asynchronous I/O API is exactly what it name says. You have to
set up a read(...) command every time again and have to give it a
ByteBuffer as buffer but yeah you can wait for an event as callback.
This is totally ok for normal asynchronous operations but I was
thinking of a real event driven API like Apache MINA (
http://mina.apache.org/mina-v20-quick-start-guide.html ) for
example. This could be a nice addition to simplify the process of
retrieving / sending data in protocol based mannor.

This means you set up a Socket (SocketChannel) and register an event
listener (something like the PropertyChangeListeners) which handles
events like ClientConnected, MessageReceived, ...

To achieve the messages you could either get the backing ByteBuffer
or you could hook in with some kind of ProtocolFilters to
"deserialize" the message.

I did something similar in my actual project (something
experimental) Jipcy.

The AbstractSocketReader (at the moment it's threading based, since
selector channel support is something tricky as you mentioned
before) retrieves the data from socket and buffers them. After every
read it tries to deserialize the bytes by asking the ProtocolHandler
to build the message. If this succeeds the
SocketListener.messageRetrieved(...) is fired.

At the moment the Message class itself is implementing the logic how
data should be retrieved from given DataInputStream or written to
the DataOutputStream. For this implementation it's totally ok, for a
real implementation I would make something more MINA like
ProtocolEncoder / ProtocolDecoder - something that way.

https://bitbucket.org/noctarius/jipcy/src/f8f9453a3f66/jipcy-core/src/main/java/org/bitbucket/jipcy/messaging/AbstractSocketReader.java

https://bitbucket.org/noctarius/jipcy/src/f8f9453a3f66/jipcy-core/src/main/java/org/bitbucket/jipcy/internal/messaging/DefaultInstanceMessageProtocol.java

But that's only an attempt to simplify the message handling (I guess
that is something more different than my original request for Named
Pipe / Unix Domain Socket support).
The question is:
Should the basic Socket API lifted up to support both or would an
implementation for SocketChannel be enough?

> -Alan.

Chris

PS: The asynchronous API lloks nice for another project I have. Nice
job.

PPS: @ Alan: sorry for wrong addressing

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4510 bytes
Desc: S/MIME Kryptografische Unterschrift
Url : http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20110826/f469ac17/attachment.bin