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:jkm at underscore.com]
> Sent: Saturday, February 07, 1998 10:33 AM
> To: ipp at pwg.org> 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: 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 --
> ----------------------------------------------------------------------
>>> Puru Bish wrote:
> >
> > :: >> 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