Toru Ueda wrote:
> If the buffer service provides segmentaion and reassembly,
> it may be more useful.
> (This might sucrifice the simplicity of buffer service.)
I don't think so. If the buffer service provides segmentaion and
reassembly,
it makes a transport architecture more complex. Actually segmentation
and reassembly is required due to limit of bus specification. However
any
requirements caused by bus specification shall be resolved in a data
link
layer such as IEEE 1284.3. And transport protocol shall be abstracted
from
any bus-specific requirements.
Toru, Brian, I am so sorry for my interruption for your discussion. Your
discussion bring us produvtive result. Thank you.
Fumio Nagasaka
>-----Original Message-----
>From: Toru Ueda [SMTP:ueda at tansu.slab.tnr.sharp.co.jp]
>Sent: Wednesday, October 29, 1997 9:16 PM
>To: Brian Batchelder
>Cc: 1394 PWG; PWG-C
>Subject: Re: P1394> 1394PWG Thick Transport Stack Requirements
>>>Hi Brian,
>>I understand the meaning of buffer service.
>>If the buffer service provides segmentaion and reassembly,
>it may be more useful.
>(This might sucrifice the simplicity of buffer service.)
>>Because IEEE1394 has maximum packet size(512 bytes for S100),
>segmentaion and reassembly service may be required if buffer
>service treats more than 512 bytes.
>>Toru Ueda
>Software Labs.
>Sharp Corporation
>>> >>At 09:54 PM 10/24/97 +0900, Toru Ueda wrote:
> >>--
> >>--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 ?
> >>
> >>The buffer service is used by clients who need to have data delivered
>with
> >>well-defined starting and ending points. For example, this data might be
>a
> >>message that needs to be delivered whole. If a byte stream service is
> >>used, the message might be broken into multiple buffers, or if might have
> >>other data appended to it. This might make the message impossible to
> >>interpret by the receiving service.
> >>--My understanding is the transport will handle the
> >>--differences of physical buffer sizes of sending and
> >>--receiving endpoints.
> >>
> >>Yes, the transport must handle varying buffer sizes in each direction.
>For
> >>the byte stream service it must be able to break up a large request
>buffer
> >>into multiple send buffers. For the buffer service it must either be
>able
> >>to somehow ommunicate to the client the largest buffer that can be sent
>or
> >>provide buffer segmentation and reassembly services. Maybe this should
>be
> >>added to the requirements?
> >>--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.
> >>
> >>I think the requirement is that the 30 bytes be delivered as a buffer if
> >>the transmitted buffer is 30 bytes and there is some indication that it
> >>should be delivered as a single, whole buffer. I don't think it is a
> >>requirement that the smaller packets be reassembled into one larger
>buffer
> >>(in other words, that a reassembly service be provided).
> >>
> >>--But buffer service allows to send only fixed(30bytes in this
> >>--case) data.
> >>
> >>The buffer service would allow UP TO 30 bytes of data to be delivered as
>a
> >>single, whole buffer. A buffer of less than 30 bytes could also be
> >>transmitted.
> >>
> >>--Does this help to write application ?
> >>
> >>It does help some applications that want to send messages without those
> >>messages inherently providing some way to be extracted from a byte
>stream.
> >>
> >>--I misunderstand buffer service ?
> >>
> >>I think that the requirements document is not complete. For now, we
> >>probably have many interpretations of the requirements. Our challenge is
> >>to refine the requirements list until we all agree on them.
> >>
> >>Brian
> >>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>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
> >>
>>>>>