However, it was decided that requests over a single
connection would be processed in order (FIFO), and that
if overlapping requests are desired, then the client could
open additional (separate) connections to the server and
issue them.
Randy
> -----Original Message-----
> From: Jay Martin [SMTP:jkm@underscore.com]
> Sent: Friday, November 21, 1997 7:22 AM
> To: ipp@pwg.org
> Cc: Scott Lawrence; Zhi-Hong Huang
> Subject: Re: IPP> Processing Algorithm
>
> I think Zhi-Hong has raised a very valid concern here, one that we
> should address in a clean and unambiguous manner within IPP.
>
> If IPP allows multiple posts (requests) in which the client is
> expecting to receive multiple responses, then IPP should be
> clearly defined to do one (and only one) of the following:
>
> a) Ensure the order of responses is *exactly* in the same
> order as the requests, or
>
> b) Define and force mandatory usage of a client-specified
> transaction id (included as part of a request) that the
> server attaches to all responses. The transaction id
> would be considered completely opaque to the server (ie,
> no semantic meaning whatsoever).
>
> If we wish to provide maximum performance potential, then the
> second choice would be the second (b) option. Adding such a
> transaction id wouldn't add that much "baggage" to the protocol.
>
> ...jay
>
> ----------------------------------------------------------------------
> -- JK Martin | Email: jkm@underscore.com --
> -- Underscore, Inc. | Voice: (603) 889-7000 --
> -- 41C Sagamore Park Road | Fax: (603) 889-2699 --
> -- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
> ----------------------------------------------------------------------
> << Message: Re: IPP> Processing Algorithm >>