How IPP Support Makes CUPS the Best Choice Around
Prev
Next

How IPP Support Makes CUPS the Best Choice Around

LPD Must Die!

For a long time many developers were deeply dissatisfied with good old LPD. Quite a few new projects were started to improve printing: LPRng is the best known example. Others are PDQ, PPR, PLP, GNUlpr and RLPR. But none of the new programs were seen as a “big shot”; most of them are just implementing the same old LPD specification with a few (or many) new extensions, which again make them incompatible with each other.

Having seen the development of not just one, but different viable alternatives to venerable BSD-style LPD, Grant Taylor, author of the Linux Printing HOWTO, finally rallied the call LPD Must Die! in his “Campaign To Abolish The Line Printer Daemon”.

How the IPP Came to Be

Along with the above, on the industry side of things, there were efforts to overcome the well-known weaknesses of LPD. It started with proprietary extensions to plain old LPD, and stretched as far as Hewlett-Packard®'s attempt to establish HP® JetDirect as a new standard for a network printing protocol. The result were even more incompatibilities.

In the end, an initiative to define a new common industry and IETF standard took shape. The “Printer Working Group” or PWG, a loose aggregation of vendors in hardware, software, and operating systems, drafted the new “Internet Printing Protocol”, IPP. IPP v1.1 has now been approved by the IETF (Internet Engineering Task Force) as a proposed standard, and now enjoys the unanimous support throughout the industry in Europe, USA and Japan. Most current network printer models have now built in IPP support on top of traditional LPR/LPD or JetDirect Printing.

Why IPP is Solving Many Problems

IPP promises to solve a lot of problems network administrators face. This trade normally deals with heterogeneous network environments and spends more than half of its working hours dealing with printing problems.

By creating a unified set of query functions for IPP enabled printers and servers, for transferring files and setting job-control attributes etc., IPP is destined to work across all operating system platforms. It's rollout however, will not happen overnight, as many legacy print devices will still be in use for many years to come. Therefore, in IPP there is a provision made for backwards compatibility of all IPP implementations. CUPS is proving the viability of IPP printing in all environments.

The most striking advantage will be it's integration into the existing set of other robust IP protocols. Being an extension of the proven and robust HTTP 1.1 protocol, for the special task of handling print file and related data, it is also very easy to plug in other standards as they are being developed and deployed:

  • Basic, Digest, and Certificate Authentication for users seeking access to print services.

  • SSL3 and TLS encryption for transferring data.

  • Bi directional communication of clients with print devices, using the HTTP/IPP GET and POST mechanism.

  • LDAP directory service integration to keep a consistent database of available printers, their capabilities and page-costs, etc., as well as user passwords, ACLs etc..

  • Pull” (as opposed to the usual “Push” model) printing, where a server or printer just needs to be told the URL of a document, whereupon it is retrieved from the resource on the internet and printed.

Printer “Plug'n'Play” for Clients

Have you ever seen a demonstration about CUPS capabilities in the network? You must have been quite impressed if you didn't know in advance what to expect.

Imagine you as the administrator of a “LAN”. For testing purposes you fully installed one TDE/CUPS box on your net, complete with a dozen printers configured and functional: PostScript®, LaserJets, InkJets and BubbleJets, and so on. Your TDE users on that box are very happy, they can print like never before, “ringing all the bells and whistles” of every printer. It took you 2 hours to make everything run perfectly... and now all the other 100 users on the network want the same. Two hours again for every box? No way you could do that before next year, you think?

Wrong. Just change one setting in the original CUPS box to make it a “server”. Install CUPS on five other boxes, as “clients”. By the time you turn back to your first client, you find the users happily playing with the settings for the dozen printers you had defined earlier on the “server”. Somehow magically the printers had appeared on all the “Print” dialogs of the five new CUPS client boxes.

Your users print, but not a single driver had been installed on the clients, nor a printer queue defined.

So, how does this magic work?

Seeing” Printers Not Installed Locally?

The answer is not complicated at all.

If a CUPS server is on the LAN, it broadcasts the names of all available printers to the LAN, using the UDP protocol and port 631. Port 631 is reserved as a “well-known port” by IANA (the “Internet Assigning Numbers Authority”) for IPP purposes. All CUPS clients listen to CUPS server info sent to their port 631. That's how they know about available printers, and that's how they learn about the “path” to the printers as well.

Using IPP, which is really a clever extension to HTTP v1.1, CUPS is able to address all objects related to the printing system via “Universal Resource Locators” or URLs. Print jobs to be deleted or restarted, printers to be queried or modified, admin tasks to be performed on the server, with IPP and CUPS, everything is addressable by a certain URL. Many important things can be done through the web interface to CUPS, accessible for example with Konqueror.

Printing Without Installing a Driver

And more, the clients basically can “administer” and “use” any printer they see, just as if it was a locally installed one. Of course, you can set restrictions on it with access control lists etc., so that not any clients may use any printer as it likes.

The clients even are able to print without the appropriate filter (or driver) installed locally.

So how does this work? If a client wants to know about and select printer-specific options, it sends a request (called CUPS-get-ppd) to the server. The server tells the client all about all printer-specific options, as read from the server side PPD. The user on the client side can see the options and select the required ones. He then sends the print file, usually unfiltered “rawPostScript®, spiced up with the printer-options to the printer server, using IPP as the transport protocol. All further processing, especially the filtering to generate the final format for the target printer, is then done by the server. The server has the necessary programs (“drivers” or “filters”) to do this.

This way a client prints without needing to install a driver locally.

Any change on the server, such as adding or modifying a printer, is instantly “known” to the clients with no further configuration.

Zero Administration”, Load Balancing, and “Failover Switching

Some other advanced features built into CUPS are the capacity to do “load balancing”.

If you define the same printer queues on two or more different servers, the clients will send their jobs to the first responding or available server. This implies an automatic load balancing amongst servers. If you have to take one server off the network for maintenance, the others will just take over its tasks without the users even noticing the difference.

Prev
Next
Home


Would you like to comment or contribute an update to this page?
Send feedback to the TDE Development Team