IPP> transaction-based HTTP

IPP> transaction-based HTTP

Harald.T.Alvestrand at uninett.no Harald.T.Alvestrand at uninett.no
Tue Feb 4 08:36:05 EST 1997


Butting in as usual:


jkm at underscore.com said:
> A more likely scenario is "100 simultaneous requests for printer and/
> or job status".  If the world persists in assuming that the printer 
> itself is the place for every individual to seek the status of the 
> printer, then printer manufacturers will always have to worry about 
> these kinds of scaling issues. 


If answering each request takes < 0.1 seconds, and the average rate
of arrival is < 5 requests per second, this is Not A Problem, because
you can do these one at a time with no significant performance loss.
TCP retransmission will even queue requests for you for a while.


The "50 simultaneous print job attempts on a printer than can't buffer?"
scenario seems to me to be more damaging; either you impose a
near-infinite wait on the "latest" client, or you have to do an
error return from the "please print" operation.


               Harald A



More information about the Ipp mailing list