AsynchronousByteCharChannel and Timeouts

[Alexander Libman]

In addition to Alan comments.
we can consider timed operations as a contract to finish operation in
specified time interval.
Timeout error can be interpereted as kind of execution error and  it leaves
the channel in undefined state.
This is major difference between asynchronous and sychnoronous non-blocking
ways of programming.



For the algorithms  when  the content of the next portion data to send
depends depends not only on peer reply,
but also on the time of reply arrival or timeouts, we have to inroduce
imaginable "AsynchronousTimers"  with completion handlers.
Currently, we can use  Timer and TimerTask in java.util as
"AsynchronousTimer" and CompletionHandler.

Usually, the  Completion Handler invocation works as signal for protocol
state machine.
Now, we simply add  the number of signals to our state machine.
The main advantages are :
1) the single  TimerTask can be used as signal for several channels, i.e.
"watch dog" approach.
Would be nice, if the user can facility to register the watch dog time
interval and timer task for whole AsynchronousGroup.
This task can iterate over group channel and  for each channel invoke a
special callback.
Inside such callback the developer can  calculate the time expired from the
last started read/write operations.

2) very often we are not interested in time interval for particular I/O
operation, but rather we are inetresrted in transition from state A to state
B in specified time interval.
Between states A and B, it can be executed a lot of read/write operations.
AsynchronousTimer approach allows to resolve this task and keep the channel
in consistent state if we decide to change our actions in timed manner.

I am not sure do we want timed operations for artificial
AsynchronousChannels (Filters). Example, AsynchronousSSLChannel.
We have different timeout meaning for external and internal channels.
Support of general timeouts for the filters -I think it is too much
overhead.
Independent AsynchronousTimer makes life easy here as well.

For SerialPort  communications  AsynchrnousTimer aprproach works too.
You can setup: "A value of zero for both the ReadTotalTimeoutMultiplier and
ReadTotalTimeoutConstant members indicates that total time-outs are not used
for read operations."
Or it is possible to use both Windows  Comm timeouts to control the rate of
arriving bytes (like for low level data link protocol ) and  high
level-timeouts "Timers" for the application layer.

Alex








> -----Original Message-----
> From: nio-discuss-bounces at openjdk.java.net
> [mailto:nio-discuss-bounces at openjdk.java.net]On Behalf Of Alan Bateman
> Sent: Monday, August 03, 2009 4:15 PM
> To: Gili
> Cc: nio-discuss at openjdk.java.net
> Subject: Re: AsynchronousByteCharChannel and Timeouts
>
>
> Gili wrote:
> > :
> > Here is a simple counter-example that comes to mind:
> >
> > write() to request a computation on the remote end
> > read() with a timeout waiting for the result
> > if a timeout occurs, write() telling the queue to abort the computation
> >
> > In the above case you could disconnect on timeout, reconnect
> and request an
> > abort. Forcing a disconnect on a timeout is not the end of the
> world, but it
> > seems like an unnecessary limitation. Instead of invalidating
> the channel,
> > couldn't you have specified that in case of a timeout the API
> will return
> > the number of bytes that were written by the underlying implementation
> > (ideally zero) and leave it up to the user to decide if he wishes to
> > disconnect or do something else?
> >
> AsynchronousSocketChannel doesn't close the channel on timeout. Rather
> it just invokes the completion handler's failed method with the
> InterruptedByTimeoutException. In many cases the application will close
> the channel at this point because the peer is not responding and there
> is nothing it can do. The wording in the spec related to continued use
> of the channel is to deal with possible implementations where it is
> completely unfeasible to cancel an I/O operation and leave the
> connection and channel is a consistent state. For example, suppose an
> implementation is using blocking I/O then there may be thread blocked in
> read or write and no way to unblock it cleanly. Another example may be
> where it is possible to cancel an I/O but have no way to guarantee that
> bytes haven't been transferred in/out of the socket buffer. That would
> completely break stream communication and clearly this an area where
> serial port I/O will differ (because you are at lower level and I assume
> there is some protocol to over errors, right?. In other words, the
> protocol will recover from data loss and other protocol errors).
>
> -Alan.
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.392 / Virus Database: 270.13.43/2280 - Release Date:
> 08/03/09 17:56:00
>