Subject: RE: IPP> Processing Algorithm

From: "Turner, Randy" <[email-masked]>
Date: Fri, 21 Nov 1997 07:55:24 -0800

In a very early protocol draft, I had a transaction identifier in
the packet so that clients could pipeline requests to
a server that, in theory, could be processed and responded
to out of order.

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:[email-masked]]
> Sent:	Friday, November 21, 1997 7:22 AM
> To:	[email-masked]
> 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:   [email-masked]          --
> --  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 >>

---

From: Jay Martin <[email-masked]>
Date: Fri, 21 Nov 1997 11:19:38 -0500

Randy,

> open additional (separate) connections to the server and

Yes, I recall this situation.  I thought your proposal to
include a transaction id was very well founded, and reflected
many, many protocol designs in use today.

It bothers me, though, that the decision is to just "open
another connection" (or two, or three) if the client wants
to perform parallel actions.  IHMO, this is far worse in
terms of resource utilization than simply using a transaction
id.

	...jay