AsynchronousByteCharChannel and Timeouts
cowwoc at bbs.darktech.org
Tue Aug 4 20:06:35 PDT 2009
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
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
> 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 :(
More information about the nio-discuss