Peter Donald wrote:
> -1
>
> for same reason I discussed with respect to extending SocketManager. I spent
> six months moving away from a single Block that is both a socket factory and
> a connection manager.
I am not advocating one block to handle both client and server sockets. I am
advocating a change in the interface to hide the implementation when available.
> Besides doesn't nio work with ServerSockets still? You just go something like
>
> ServerSocketChannel channel = myServerSocket.getChannel();
> //do stuff with channel
Won't work.
From the API docs on SocketChannel:
--------------------------------------------------------------------------------
A selectable channel for stream-oriented connecting sockets.
Socket channels are not a complete abstraction of connecting network sockets. Binding,
shutdown, and the manipulation of socket
options must be done through an associated Socket object obtained by invoking the
socket method. It is not possible to create a
channel for an arbitrary, pre-existing socket, nor is it possible to specify the
SocketImpl object to be used by a socket associated
with a socket channel.
A socket channel is created by invoking one of the open methods of this class. A
newly-created socket channel is open but not yet
connected. An attempt to invoke an I/O operation upon an unconnected channel will
cause a NotYetConnectedException to be thrown. A
socket channel can be connected by invoking its connect method; once connected, a
socket channel remains connected until it is
closed. Whether or not a socket channel is connected may be determined by invoking its
isConnected method.
Socket channels support non-blocking connection: A socket channel may be created and
the process of establishing the link to the
remote socket may be initiated via the connect method for later completion by the
finishConnect method. Whether or not a connection
operation is in progress may be determined by invoking the isConnectionPending method.
The input and output sides of a socket channel may independently be shut down without
actually closing the channel. Shutting down
the input side of a channel by invoking the shutdownInput method of an associated
socket object will cause further reads on the
channel to return -1, the end-of-stream indication. Shutting down the output side of
the channel by invoking the shutdownOutput
method of an associated socket object will cause further writes on the channel to
throw a ClosedChannelException.
Socket channels support asynchronous shutdown, which is similar to the asynchronous
close operation specified in the Channel class.
If the input side of a socket is shut down by one thread while another thread is
blocked in a read operation on the socket's
channel, then the read operation in the blocked thread will complete without reading
any bytes and will return -1. If the output
side of a socket is shut down by one thread while another thread is blocked in a write
operation on the socket's channel, then the
blocked thread will receive an AsynchronousCloseException.
Socket channels are safe for use by multiple concurrent threads. They support
concurrent reading and writing, though at most one
thread may be reading and at most one thread may be writing at any given time. The
connect and finishConnect methods are mutually
synchronized against each other, and an attempt to initiate a read or write operation
while an invocation of one of these methods is
in progress will block until that invocation is complete.
-------------------------------------------------------------------------------
The Socket needs to be initiated by the SocketChannel!
>
> So we should not need to change interface for 1.4 anyways - or am I missing
> siomething?
The interface change I am proposing works NOW as well as for 1.4. It just
gives us the flexibility of not being bound to the Socket object as an implementation
detail. We can use non-blocking IO when it is available--without changing the
API later. Otherwise, there is no chance of that.
>
> On Wed, 14 Nov 2001 04:47, Berin Loritsch wrote:
>
>>The way we have the Socket handling API for Cornerstone does not provide
>>us the flexibility to upgrade to non-blocking IO when it is available.
>>I propose making the change from this:
>>
>> public void connect( String name,
>> ServerSocket socket,
>> ConnectionHandlerFactory handlerFactory )
>>
>>
>>to this:
>>
>> public void connect( String name,
>> String host,
>> int port,
>> ConnectionHandlerFactory handlerFactory )
>>
>>
>>The change is using a host/port pair instead of the ServerSocket/Socket for
>>the APIs. One of the benefits of Non blocking I/O is an optimization of
>>multiple sockets being handled in one thread!
>>
>>This allows the interface to be consistent now and when JDK 1.4 is finally
>>released. It also allows us to take advantage of a JDK 1.4 environment
>>when it is available--without rewriting our apps!
>>
>
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
