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@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