When an initiator assume a target will reply 500 bytes,
but the target device only replies 300 bytes, then this
input ORB will not be completed. The initiator is waiting
for 200 bytes as rest of the contents. If we do not have
any timer to detect this situation and if the transport
layer software does not resolve hanging ORB to avoid input
pipe stalling, a higher level client software need to solve
this problem.
One possible solution for the problem is that the transport
software of the target fills padding data (null data) when
this timer over runs, and the target force to complete this
input ORB, and also the target shall reply the valid length
of data in the input buffer.
However I do not feel that we need to define this timer.
Because I prefer to design a predictable transport like CBT.
If we choose a CBT style solution, the target may ask the
initiator to provide credit to receive data from the target.
Then the target sends a packet which contains length field
of valid data length and real data itself. Thus I believe
timer design depends upon whether we can define predictable
transport or not. Actually IEEE 1284.4 does not require to
have this sort of timer, because it does not need to assume
a communication pipe to be stalled.
Fumio
Alan wrote:
>August 25, 1998
>
>This is a call for discussion on Timers for the 1394 Image Profile.
>At the last meeting we attempted to address this issue and only identified 3
>timers. Are there others we missed? Please submit comments and suggestions.
>
>1) Reconnect Timer - This one is taken care of by SBP-2 as part of the Login
>process.
>
>2) Management ORB Timer - When the Initiator writes a Management ORB address to
>the Management Agent Register, how long should it wait for a response to be
>written to the management ORBs status fifo? How is the timeout value determined
>and communicated?
>
>3) Abort Task Set Timer - An Abort Task Set may issued by an Initiator in
>response to Target Inactivity. How is the timeout value determined and
>communicated?
>
>Any other timers that we did not include at the last meeting?
>
>
>
--- Fumio Nagasaka EPSON Software Deveopment Lab., Inc. voice: +81 268 25-4111