P1394 Mail Archive: P1394> API issue (cont. from Raleigh meeting)

P1394 Mail Archive: P1394> API issue (cont. from Raleigh meeting)

P1394> API issue (cont. from Raleigh meeting)

Takashi Isoda (isoda@cse.canon.co.jp)
Fri, 5 Nov 1999 15:43:30 +0900

Brian and folks,
We discussed on the API issue that Initiator can not distinguish
the orderly release of T2I queue by target from abortive release
in the last meeting.
To re-start the discussion on the reflector, let me introduce
the summary of my suggestion.

Problem
When Target shutdowns the T2I queue either orderly or abortive,
PPDT in initiator can not indicate to its clients that the T2I queue is
shutdowned
either orderly or abortive by target explicitly.
->NOT meet with WinSockAPI

(WinSockAPI provides the method that Clients can distinguish
the connection is disconnected either abortive or orderly
by Return code.

Orderly disconnect
Return for recv() Result OK
read 0 byte
Abortive disconnect
Return for recv() Result ERROR
Error code CONNECTION RESET)

Background
1 There is no signal on wire that indicates either the
T2I queue is disconnected abortive by target or orderly.

2 Initiator can not distinguish them by the order of
complete statuses for Shutdown control and for ORBs
in the T2I queue being disconnected .
- As Target executes ORBs independently by each queue bases,
though the order of complete status for ORBs for the same queue
is significant, the order of complete status for ORBs those are
for different queues is meaningless.

The solution I proposed at the meeting
Add new parameter "Abortive(4)" to the "status"( in the Status Block )

When Target aborts data transfer from target to system memory specified
by an ORB in a T2I queue being disconnected because of the abort
connection request from the client on target, Target shall set four
(Abortive) to status of the complete status for the ORB.

Conclusion
Initiator can distinguish the orderly release of T2I queue by target from
abortive release by status in complete status
-> meet with WinsockAPI..

Brian, I think at the meeting you suggested another solution on this
problem.
Would you be kind enough to give us the explanation on your solution?

Takashi Isoda
International Standard Development Dept.2
Canon Inc.
E_mail : isoda@cse.canon.co.jp