Perhaps I can add to Robert's good explaination of command set behavior.
> If I want to using a TRANSPORT_T2I_DATA command to demand the target to
> send a file (unknown size). If the information of the size of memory address
> range is got from TRANSPORT_CAPABILITES command. If the size of memory
> address range is smaller than file size. The target shall send a Status ORB
> with the field of sbp_status is 8 (resource unavailable).But it doesn't make
> sense. If I have printer with 4M memory and I want to print 8M's file. The
> printer will reject my command. Or is there any way to send this file in
> several times into the same memory address range??? It must prevent the
> target rewrite the same memory address range before initiator put these data
> into buffer or file.
I'm confused by your model. Memory address ranges are not
specified. They are not required to be fixed beyond those for
the SBP-2 registers. The transport clients on either end have no
access to or knowledge of 1394 system addresses assocaited with
the transport.
The model of the transport is:
Targets provide services.
Initiators access services.
A pair of independent opposing unidirectional ordered data flows
provides bidirectional communication.
The (Login/TRANSPORT_OPEN, TRANSPORT_CLOSE/Logout) mechanism
provides access control and connection bounding.
A typical model is for a target to provide a Print Job
Consumption service. In this case:
a) an initiator does a Login to a target
b) the initiator issues a TRANSPORT_CAPABILITIES request
to find out the maximum number of ORBs that can be
queued up at once (across both directions), and the
maximum size of the buffer that can be carried on
a TRANSPORT_I2T_DATA ORB.
c) The initiator partitions up the print file into pieces
<= MAX_I2T_DATA_SIZE bytes. Each piece is referenced
by an ORB carrying a TRANSPORT_I2T_DATA command.
d) The initiator queues up the ORB for the next piece of the
file when space exists in the active task set. Note that
an initiator is not allowed to have more than MAX_TASK_SET_SIZE
ORBs on the Task List.
d) When the whole print job is sent, the initiator will put a
TRANSPORT_CLOSE command on the I2T queue. Anything else
needed for cleanup of the connection is application-specific.
It sounds like your model is a target providing a Print Job
GENERATION service. This is highly unorthodox, but still workable.
For this scenario:
a) an initiator does a Login to a target
b) the initiator issues a TRANSPORT_CAPABILITES request to
find out the maximum number of ORBs that can be queued
up at once (across both direcitons), and the maximum size
of the data buffer that can be carried on a TRANSPORT_T2I_DATA
ORB.
c) The initiator queues up one or more TRANSPORT_I2T_DATA
commands, with an empty buffer for receiving the data.
NOTE -- Somehow, the initiator needs to determine whether
or not a print job is available. This is beyond the scope
of a tranport protocol. It must be done at a higher layer.
d) When the target has data available, it copies whatever data
is appropraite (and fits) into the buffer supplied by the
ORB, and completes the ORB with the appropriate value in
the _residual_ field. The completion policy, and results,
depend on whether the service is message-based or stream-based.
Since you are talking about a file transfer, and we have
no addressing information, I'll assume it's stream-based.
Any data which could not be put into one TRANSPORT_T2I_DATA ORB
is put into the following one. The task of indicating
"end-of-file" is left to the data format being sent across
the transport. It seems simple enough to send an "end-of-file"
indication in the data block of a TRANSPORT_T2I_DATA ORB
with the tag bit set differently than the normal data. Or your
service could simply "close" the T2I queue from the target side
resulting in the initiator receiving a status of:
REQ_COMPLETE:
NO ADDL INFO:
CHECK COND:
ILLEGAL REQ:
END-OF-DATA DETECTED
on all further TRANSPORT_T2I_DATA ORBs.
Exactly which model you choose depends on the service you
specify. In either case, this model is above the transport layer.
> As you say "The initiator transport client (e.g. application layer)
> only knows the size of the target's data by pre-arrangement". Does the way
> of pre-arrangement show protocol in sbp-2 ???? or it shall get by
> self-defined way???
The above comment only applies to message-based services and is
characterized by the service itself.
Does this help?
-- Greg Shue Hewlett-Packard Company All-in-One Division gregs@sdd.hp.com ----------------------------------------------------------------