IPP> Processing Algorithm

IPP> Processing Algorithm

IPP> Processing Algorithm

Jay Martin jkm at underscore.com
Fri Nov 21 10:21:41 EST 1997


This is a multi-part message in MIME format.
--------------99B48168D1A685467C47661C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


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 at 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   --
----------------------------------------------------------------------
--------------99B48168D1A685467C47661C
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by uscore.underscore.com (8.8.4/8.7.2) with ESMTP id KAA21797; Fri, 21 Nov 1997 10:14:15 -0500 (EST)
Received: from localhost (daemon at localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA15312; Fri, 21 Nov 1997 10:14:13 -0500 (EST)
Received: by pwg.org (bulk_mailer v1.5); Fri, 21 Nov 1997 10:12:00 -0500
Received: (from daemon at localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA14699 for ipp-outgoing; Fri, 21 Nov 1997 09:58:26 -0500 (EST)
Message-Id: <199711211447.JAA06431 at devnix.agranat.com>
To: zhi-hong at zeno.com (Zhi-Hong Huang)
cc: ipp at pwg.org
Subject: Re: IPP> Processing Algorithm
In-reply-to: <3474D9D4.9DDD1B1 at zeno.com>
Date: Fri, 21 Nov 1997 09:47:39 -0500
From: "Scott Lawrence" <lawrence at agranat.com>
Sender: ipp-owner at pwg.org
Content-Type: text




>>>>> "ZH" == Zhi-Hong Huang <zhi-hong at zeno.com> writes:


ZH> Since client may POST several IPP requests on a single HTTP 1.1
ZH> connection, if the server replys before consuming all the data
ZH> the client sends, it would be difficult for the server to locate
ZH> where the next message starts.


  I'm not entirely sure that I'm addressing the right concern here,
  but... an HTTP/1.1 server can detect the end of an entity body in
  any of three ways: a Content-Length header, Transfer-Encoding:
  chunked, or a Multipart encoding that is self-descriptive.


  It is true that an HTTP client using persistent connections (either
  1.1-style or the Netscape Keep-Alive style) must keep track of the
  order of requests, and the server must preserve that order in
  sending responses as there is no transaction identifier.


  Did that answer your question?



--
Scott Lawrence           EmWeb Embedded Server       <lawrence at agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/




--------------99B48168D1A685467C47661C--




More information about the Ipp mailing list