You are correct. I didn't. It should be in a final draft.
> host and device. As I understand it, "message-based
> communication" implies that the initiator knows when
> the target has data to send, but doesn't necessarily
> know the length of the data.
The model we have been using is that a message is a
bounded set of data to be transferred within one ORB.
It is to be transferred as a composite whole, and may
be transferred at any time. The idea is best described
as a "reliable point-to-point datagram service". So the
receiver doesn't know when a message will come or how
long it is. It just knows the maximum length of any single
message, and that the whole message will be transferred
within one ORB. The size of the message is limited by
primarily by the command set used, and otherwise limited
by the packet negotiation size (if the command set takes
care of de/fragmentation).
> "Stream-based
> communication" allows more initiation on the part of
> the target, so that the initiator must post a Store
> Data ORB, to support the possibility that the target
> will have data to transfer.
A STORE DATA (or TRANSPORT_I2T_DATA) ORB will have to
be posted whether it's a message or stream connection.
It's the only means to move data from the Target to the
Initiator. :-)
> I think the question to be answered is whether there needs
> to be negotiation between target and initiator (or maybe
> just information from target to initiator) over when, under
> stream-based comm., the target is allowed to complete the
> Store Data Orb. As I thought about this, the only reasons
> that I identified for termination were application
> related. And the application (transport client in the
> device) seemed to have it's own good reason.
This is the essence of the issue. In Stream-based communication,
a target could complete an ORB:
as soon as _any_ data is available (possibly wasting bus
bandwidth)
only when it must (full or target internally blocked because
output must be sent before proceeding).
or anywhere in between.
> So, what was the intent for the STREAM_COMPLETION
> variable? Is there something I'm missing related
> to the early completion of Store Data Commands
> for stream-based communication?
If commands are completed immediately, then extra bus
bandwidth is consumed for having to requeue additional
ORBs.
Does this help?
> --
> Bob Morford (bob@sismicro.com)
> SIS Microelectronics, Inc.
> A Subsidiary of Aspec Technology, Inc.
> 1831 Lefthand Cir., Suite #E
> Longmont, CO 80501
> 303-776-1667 x226
>
-- Greg Shue Hewlett-Packard Company All-in-One Division gregs@sdd.hp.com ----------------------------------------------------------------