That's fine if the initiator's transport client is a print spooler,
but what about other higher layer apps such as:
a Status/Event Monitor?
a file transfer protocol?
a scanning app?
We're working on a generic protocol. I don't want to impose any
more requirements on the application than does TCP. TCP itself
takes care of timeout/lost link detection. I think this protocol
should also. Once detection by the initiator's protocol driver is
taken care of, then recovery is easy. Have we now ended up with
a case where the initiator's side needs to poll for FETCH_AGENT status
or do we let the node hosting the target side generate a Bus Reset?
> SBP-2 E.4 >Any target resources allocated to the ORB should be released by
> thetarget.
>
> ...so, ORB_POINTER is unusable to examine the last ORB which
> was consumed. Thus this initiator shall ask the target to report the last
> ORB
> address utilizing higher level command sounds like "TRANSPORT_I2T_ABORT".
I don't think so. The ORB_POINTER register can still point to
the offending ORB. The ORB itself can no longer be referenced
by the target. Since it is in the initiator's memory space, the
initiator can still examine it.
-- Greg Shue Hewlett-Packard Company All-in-One Division gregs@sdd.hp.com ----------------------------------------------------------------