I wish more service-oriented protocols had this kind of feature.
...jay
----- Begin Included Message -----
Date: Fri, 27 Jun 1997 11:30:02 -0400
From: cgordon@digprod.com (Charles Gordon)
Subject: IPP> Suggestion for timed delay error code.
To: ipp@pwg.org
Content-Transfer-Encoding: 7bit
I think there is a potential problem with the Print-Job and
Send-Document operations. The problem occurs when a printer receives
a Print-Job or Send-Document request which it cannot accept because it
is busy. When a client receives the busy response, it's natural
action will be to try again. As far as I know, we have not defined a
delay interval between retries of the Print-Job and Send-Document
operations. So, there is no reason (in IPP as it is currently
defined) why a client cannot simply retry immediately. Given the
desire to print as soon as possible, it is quite likely that clients
will be written to retry immediately, or after a very short delay.
The problem occurs when many clients are trying to print to the same
printer and all of them are retrying. At the very least, this will
generate extra traffic. In addition, all of the retries may stress
some of the light weight implementations of IP used in embedded
systems. IPP should try to reduce unnecessary traffic when possible.
The retry situation will happen all the time on low end printers which
do not have a disk drive and therefore can only accept a single job at
a time. Since they can only print one job at a time, if 10 clients
are trying to print, 9 will get a busy indication and start retrying.
It can also happen on higher end printers when they run out of
spooling space, or if more clients try to establish connections than
the printer is capable of handling similtaniously.
I believe that this problem should be handled at the IPP level. There
are some IPP operations which should be supported even if the printer
cannot accept Print-Job and Send-Document requests. For example,
client should be able to use the Validate-Job and Get-Attributes
operations even if they cannot actually send jobs. This implies that
the HTTP layer should not be the one to reject the connection request
when the printer can no long accept more jobs. Instead, the request
should be passed onto IPP which should either process it if it is able
to, or reject it with an appropiate error code.
At the last IPP meeting we defined an error code which indicates that
the printer is not able to perform the indicated operation because of
a lack of resources and that the problem is temporary. I suggest an
additional parameter be passed back with this code which tells the
client how long it should wait before it retries the operation. This
will allow the printer to throttle down the clients if it starts to
get overwhelmed with requests it cannot accept. Since the printer
specifies the delay, it can change the delay to deal with the
particular problem. For example, if the printer cannot print because
it is out of paper, it could specify a delay of 5 minutes if this is
typically how long it takes an operator to load more paper into the
printer. If, on the other hande, the printer cannot accept jobs
because its fuser has burned out, it may want to specify a much larger
retry interval. The printer can also vary the delay according to how
many clients are attempting to send jobs.
The other alternative would be for the IPP protocol to specify a fixed
delay the client must wait before retrying after it gets the out of
resources error code from the printer.
I suggest making the delay a variable interval under the control of
the printer since this is more flexible.
--- Charles
----- End Included Message -----