Brian,
Thank you for forwarding your client requirements for thick
transport stack document.
I have one question about thick "MUST".
I don't understand how to use buffer service.
Why must thick transport have buffer service ?
My understanding is the transport will handle the
differences of physical buffer sizes of sending and
receiving endpoints.
I assume that the indication of receiving the 30bytes packet
to upper layer will issue when 30bytes data receives whether
this packet is divided into 2-15 bytes or 3-10 bytes data if
the transport packet size is 30 bytes.
But buffer service allows to send only fixed(30bytes in this
case) data.
Does this help to write application ?
I misunderstand buffer service ?
>>* Provide in-order, byte-stream and in-order, buffer (datagram?) services
>> Buffer (datagram?) - Data is guaranteed to be delivered to the
>> receiving endpoint in the same form as it was
>> presented by the sending endpoint.
>> For example, if data is presented in a buffer of
>> 30 bytes, it must be delivered in a buffer of 30
>> bytes. The transport stack may limit the size of
>> buffers. It does not have to support segmentation
>> and reassembly.
>>To: 1394 PWG <p1394 at pwg.org>, PWG-C <pp1394 at cpdc.canon.co.jp>
>>From: Brian Batchelder <brianb at vcd.hp.com>
>>Subject: P1394> 1394PWG Thick Transport Stack Requirements
>>Mime-Version: 1.0
>>Content-Type: text/plain; charset="us-ascii"
>>Sender: p1394-owner at pwg.org
>>
>>1394PWG - Client Requirements for Our Thick Transport Stack
>>-----------------------------------------------------------
>>The following is a list of requirements the client places on the thick
>>transport stack. The requirements are split into two sections: musts and
>>wants. They are intentionally brief, with definitions of terms following
>>each requirement.
>>
>>Musts
>>-----
>>* Support multiple, concurrent, independent, symmetrical connections
>> Multiple, concurrent - Allows for more than one connection at a time.
>> Independent - Activity on one connection has no effect on other
>> connections.
>> Symmetrical - Either endpoint can open and close the connection, and
>> send data.
>> Connection - well-bounded communication path between two endpoints.
>> The endpoints can be on the same device or on different
>> devices.
>>* Provide in-order, byte-stream and in-order, buffer (datagram?) services
>> In-order - Data is delivered to the receiving endpoint in the same
>> order as it was presented by the sending endpoint.
>> Byte-stream - Data is delivered as a stream of bytes. The stream of
>> bytes is not guaranteed to be delivered to the
>> receiving endpoint in the same form as it was
>> presented by the sending endpoint. For example, a
>> stream of 80 bytes of data may be presented as 4-20
>> byte buffers, but delivered as 2-40 byte buffers.
>> Buffer (datagram?) - Data is guaranteed to be delivered to the
>> receiving endpoint in the same form as it was
>> presented by the sending endpoint.
>> For example, if data is presented in a buffer of
>> 30 bytes, it must be delivered in a buffer of 30
>> bytes. The transport stack may limit the size of
>> buffers. It does not have to support segmentation
>> and reassembly.
>>* Provide a directory service
>> Endpoints on a specific device may be referenced by their service name.
>> This allows connections to be opened without any knowledge of the
>> underlying layer's implementation of sockets, etc.
>>* Transparently handle transient link interruptions
>> The transport stack shall handle transient link interruptions without
>> affecting the endpoints. These link interruptions include: temporary
>> cable disconnect, 1394 bus reset, etc. Do we want to provide a service
>> to optionally notify clients when there is a link interruption?
>>* Reliability
>> What level of reliability is required by the clients?
>>
>>Wants
>>-----
>>* Connectionless service
>> A non-bounded communication path between two endpoints. Data may be
>> sent without "opening" a connection.
>>* Multi-casting
>> Simultaneously sending data from one endpoint to multiple endpoints.
>> Does this need to be bidirectional? Does it need to be reliable?
>>* Data tagging
>> Data can be tagged as "special data" by the sending endpoint. The
>> transport will indicate to the receiving endpoint that the data is
>> tagged. This is also known as out-of-band data.
>>* Provide endpoints with fair access to other endpoints
>> The transport will prevent endpoints from monopolizing the link and
>> preventing other endpoints from access.
>>* Selectable quality of service
>> The ability to adjust various quality of service parameters, including:
>> Isochronous delivery
>> Priority
>> Propagation Delay
>> Rate of transfer (bandwidth)
>>
>>
>>Internal Thick Transport Stack Requirements
>>-------------------------------------------
>>The following are the requirements the transport stack places on itself.
>>
>>Musts
>>-----
>>* Be data, application and O/S independent
>> The transport stack shall not put any requirements on the format of
>> the data, nor shall it interpret the data in any way. The transport
>> stack shall work with any application that correctly uses the
>> appropriate interfaces. The transport shall be implementable under
>> any operating system.
>>* Do not preclude concurrent operation of other protocol stacks
>> Devices may implement and use other protocol stacks concurrently with
>> this transport stack.
>>* Provide efficient data transmission
>> Prevent unnecessary bus traffic (e.g. retransmissions) by not
>> transferring data until that data can be handled by the receiving
>> device. Balance bus traffic with protocol overhead.
>>
>>Wants
>>-----
>>* Bus-independent transport layer
>> The transport layer may be used on other busses.
>>* Reuse existing protocols
>> Save time by reusing existing protocols, rather than inventing new ones.
>>
>>Brian Batchelder
>>Greg Shue
>>
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>Brian Batchelder | Hewlett-Packard | mailto:brianb at vcd.hp.com
>>Connectivity Futurist | 1115 SE 164th Ave. | Phone: (360) 212-4107
>>DeskJet Printers | Vancouver, WA 98684 | Fax: (360) 212-4227
>>
Toru Ueda
Sharp Corp
Software labs.