If the Target is a scanner, the initiator is a PC host. There would be
a lot of TRANSPORT_T2I_DATA ORBs.
1. If the initiator (PC host) wants the target(scanner) to transfer a image.
It will begin as following. I add my question below:
> 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.
If the scanner has four modes,(i) A4 size 16bit fullcolor (ii)A4 size
B/W 2 color (iii) B4 size 16bit fullcolor (iv) B4 size B/W 2 color. which
solution is correct ? (a) the initiator would allocate memory for each mode.
Or (b) the initiator would just allocate only one maximum size memory which
is found out by TRANSPORT_CAPABILITES request.If the solution is (b). It
doesn't have good performance in host's OS. And If the initiator find out
that the data buffer is less than the target's maximum size. which one is
correct??? (c) the initiator will stop this ORB. delete it from the list.
(d)the initiator would seperate the Target's data into several T2I ORBs.
When the initator's data buffer is full, initiator will put them into disk
or append them into a file. But this cause a problem. The target cannot know
initiator's data buffer is full.
> 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
I do not really know what is message-based service and stream-based
service. I should miss these paragraph in specification. Could you please
explain these to me??? Thanks.
-----原始郵件-----
寄件者: Greg Shue <gregs@sdd.hp.com>
收件者: johnson ho <johnsonh@avance.com>
副本抄送: bob@sismicro.com <bob@sismicro.com>; p1394@pwg.org <p1394@pwg.org>
日期: 1998年8月22日 AM 01:01
主旨: Re: P1394> Some question about Command Set Proposal Revision 0d
>
>Hi Johnson,
>
>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
>----------------------------------------------------------------
>
>