AsynchronousByteCharChannel and Timeouts

[cowwoc]

Alexander Libman wrote:
> 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.

	I don't think that it is safe to assume that timeouts are a form of 
execution error. When I asked about timeouts on the RXTX mailing list a 
lot of people responded that they expect to be able to use the channel 
after a read() timeout. For example, some comport protocols "frame" data 
packets using a timeout. So you read() and if a timeout occurs you 
assume that the *next* read denotes a new packet or connection. In such 
a case, you do not want to close and reopen the comport because you 
might miss some bytes.

	I think it is perfectly reasonable for some channel implementations to 
invalidate after a timeout, if this is the exception to the rule. What 
worries me is that you seem to be implying the opposite: that 
more-often-than-not a timeout error should result in the channel in an 
undefined state.

	For some category of channels, such as comports, an implementation that 
invalidates after a timeout is fairly useless.

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

	I'm not sure I understand you correctly, but if I am then this isn't 
ideal from a usability point of view. I want to read 1-n bytes within X 
milliseconds or timeout with 0 bytes read. This sort of thing should be 
implemented under the hood (since it's a common use-case) instead of 
forcing me to implement it on top of the API in terms of timers.

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

	I'm sorry. I couldn't understand what you're trying to say here :(

Gili