IPP> Suggestion for timed delay error code.

IPP> Suggestion for timed delay error code.

IPP> Suggestion for timed delay error code.

Charles Gordon cgordon at digprod.com
Fri Jun 27 11:30:02 EDT 1997


     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



More information about the Ipp mailing list