You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/11/13 18:47:21 UTC
[proposal] API change for Cornerstone socket handling
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] API change for Cornerstone socket handling
Posted by Peter Royal <pr...@managingpartners.com>.
On Tuesday 13 November 2001 04:31 pm, you wrote:
> > I think Pete's objection is that you are no longer passing in the
> > ServerSocket. He separated the creation of the Socket and the handling
> > into 2 separate blocks. In your change above, the ConnectionManager will
> > be opening the socket, correct?
>
> You are correct. Now that I see the Socket Manager Block, I see how it can
> be done using non-blocking IO.
kewl.
Pete's stuff is pretty simple and easy to use. I was pleasantly suprised :)
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] API change for Cornerstone socket handling
Posted by Berin Loritsch <bl...@apache.org>.
Peter Royal wrote:
> On Tuesday 13 November 2001 04:16 pm, you wrote:
>
>>>> public void connect( String name,
>>>> ServerSocket socket,
>>>> ConnectionHandlerFactory handlerFactory )
>>>>
>>>>
>>>>to this:
>>>>
>>>> public void connect( String name,
>>>> String host,
>>>> int port,
>>>> ConnectionHandlerFactory handlerFactory )
>>>>
>
> I think Pete's objection is that you are no longer passing in the
> ServerSocket. He separated the creation of the Socket and the handling into 2
> separate blocks. In your change above, the ConnectionManager will be opening
> the socket, correct?
You are correct. Now that I see the Socket Manager Block, I see how it can
be done using non-blocking IO.
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] API change for Cornerstone socket handling
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>I think Pete's objection is that you are no longer passing in the
>ServerSocket. He separated the creation of the Socket and the handling into 2
>separate blocks. In your change above, the ConnectionManager will be opening
>the socket, correct?
>
I think ConnectionManager block (or one of a few impls of the service)
*could* depend on the preexisting ServerSocketManager block (or again
one impl of many)
Peter D could have his seperated design, but there could be alternate
impls that are all in one.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] API change for Cornerstone socket handling
Posted by Berin Loritsch <bl...@apache.org>.
Peter Royal wrote:
> On Tuesday 13 November 2001 04:16 pm, you wrote:
>
>>>> public void connect( String name,
>>>> ServerSocket socket,
>>>> ConnectionHandlerFactory handlerFactory )
>>>>
>>>>
>>>>to this:
>>>>
>>>> public void connect( String name,
>>>> String host,
>>>> int port,
>>>> ConnectionHandlerFactory handlerFactory )
>>>>
>
> I think Pete's objection is that you are no longer passing in the
> ServerSocket. He separated the creation of the Socket and the handling into 2
> separate blocks. In your change above, the ConnectionManager will be opening
> the socket, correct?
Correct. So which block opens the socket?
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] API change for Cornerstone socket handling
Posted by Peter Royal <pr...@managingpartners.com>.
On Tuesday 13 November 2001 04:16 pm, you wrote:
> >> public void connect( String name,
> >> ServerSocket socket,
> >> ConnectionHandlerFactory handlerFactory )
> >>
> >>
> >>to this:
> >>
> >> public void connect( String name,
> >> String host,
> >> int port,
> >> ConnectionHandlerFactory handlerFactory )
I think Pete's objection is that you are no longer passing in the
ServerSocket. He separated the creation of the Socket and the handling into 2
separate blocks. In your change above, the ConnectionManager will be opening
the socket, correct?
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] API change for Cornerstone socket handling
Posted by Berin Loritsch <bl...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] API change for Cornerstone socket handling
Posted by Peter Donald <do...@apache.org>.
-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.
Besides doesn't nio work with ServerSockets still? You just go something like
ServerSocketChannel channel = myServerSocket.getChannel();
//do stuff with channel
So we should not need to change interface for 1.4 anyways - or am I missing
siomething?
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!
--
Cheers,
Pete
-------------------------------------------------------
To fight and conquer in all your battles is not supreme
excellence; supreme excellence consists in breaking the
enemy's resistance without fighting. - Sun Tzu, 300 B.C.
-------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] API change for Cornerstone socket handling
Posted by Mircea Toma <mi...@home.com>.
> 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!
>
+1
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] API change for Cornerstone socket handling
Posted by Paul Hammant <Pa...@yahoo.com>.
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!
>
+1
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] API change for Cornerstone socket handling
Posted by Eric Medlock <er...@yahoo.com>.
I realize my vote carries next to zero weight, but...
+1
--- Berin Loritsch <bl...@apache.org> 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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Find the one for you at Yahoo! Personals
http://personals.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] API change for Cornerstone socket handling
Posted by Gerhard Froehlich <g-...@gmx.de>.
+1
>-----Original Message-----
>From: Berin Loritsch [mailto:bloritsch@apache.org]
>Sent: Tuesday, November 13, 2001 6:47 PM
>To: avalon-dev@jakarta.apache.org
>Subject: [proposal] API change for Cornerstone socket handling
>
>
>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: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>