Subject: IPP> Re: How should the server behave

From: "Puru Bish" <[email-masked]>
Date: Fri, 06 Feb 1998 20:02:46 PST

:: >> 3.   How should a non-spooling IPP-server handle concurrent 
::print-job
::>> requests?
:: >
::>Return server-error-service-unavailable (0x0502) to indicate that the
server is
>temporarily unable to handle a request.
>

>We also discussed that a server MAY keep a list of clients that are 
trying
>to connect in a "queue", and then serve each one one at a time.  Then 
the
>client doesn't receive an error (except if the "queue" is filled).  
This
>gives the end-user a much happier experience.

Consider the scenario:
	An IPP Client tries to print a job to an IPP server. A non-spooling 
HTTP/IPP server received TCP SYN pkt on port 80
 from the IPP 
client, responded back with a TCP SYN-ACK pkt, and then received 
an ACK pkt from the IPP client. At this point, the HTTP/IPP
server does not know whether the next pkt is going to be an IPP request
or a simple HTTP operation for its embedded web.
 Next comes the first HTTP POST 
pkt with IPP header and IPP data. However, at this time, the
 HTTP/IPP server realized that another IPP job is in the process
 of printing. What will the IPP server do? if we follow the first 
recommendation, it will immediately send a 0x0502 IPP status 
to indicate that the service is temporarily. However, if we follow the 
second recommendation, should the non-spooling IPP server just sit
idle and not respond to the new HTTP POST operation? 

Thanks,
PB

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

---

From: Paul Moore <[email-masked]>
Date: Sun, 8 Feb 1998 14:02:33 -0800

The fundamental mind shift would be to recognize that two people trying to
hit the printer at the same time is not an error condition, but is part of
the fundamental feature set of a network printer. (Imagine a deli-counter
that said to you 'sorry we have a problem please come back later' if there
was somebody else in line, even if they did tell you that the problem was
that there were other people in the line)

> -----Original Message-----
> From:	Jay Martin [SMTP:[email-masked]]
> Sent:	Saturday, February 07, 1998 10:33 AM
> To:	[email-masked]
> Cc:	Puru Bish
> Subject:	Re: IPP> Re: How should the server behave
> 
> Puru Bish's scenario and questions strike a strong chord
> with me, having long been involved in protocol design and
> development.
> 
> A robust protocol should allow a client to easily distinguish
> the difference between these two situations:
> 
>   1) The server is not available (program not running,
>      host not on the network, or unreachable in someway).
> 
>   2) The server is "too busy" to handle the client's request
>      at the moment; the client should try again "in the near
>      future" when the server has finished its current load.
> 
> All too many times the "too busy" situation is handled by
> a "silent" approach by the server...making it very, very
> difficult for the client to determine if a process problem
> exists (ie, a system component--the server--is not available,
> thereby making the "system" unusable), or if the client must
> "throttle back" and repeat the request at a later time.
> 
> I hope we don't suggest the "silent" approach for IPP,
> especially if we're interested in a "much happier experience"
> for the end-user (as Tom Hastings has pointed out).
> 
> In the case of an "IPP server too busy" situation, Carl Kugler
> has suggested:
> 
> > Return server-error-service-unavailable (0x0502) to indicate
> > that the server is temporarily unable to handle a request.
> 
> This is fine by me IFF that error code has precisely (and ONLY)
> the semantics of "too busy, try back later".  Otherwise, if
> this error code is overloaded, we should define a different
> and unique error code to declare the "too busy" condition.
> 
> I know it may be asking too much (particularly at this late
> stage), but it would be ideal if, for a "too busy" condition,
> the server not only returns a distinguishing error code, but
> also returns some sort of "hint" as to when the client should
> try again (eg, 5 minutes, 3 hours, etc.).  In doing so, the
> IPP protocol would be helping to reduce network traffic, as
> well as improving the predictability of the printing process.
> 
> Comments?
> 
> 	...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   --
> ----------------------------------------------------------------------
> 
> 
> Puru Bish wrote:
> >