Hvordan IPP-støtte gør CUPS til det bedste eksisterende valg

Mange udviklere var længe meget utilfredse med gode gamle LPD. En hel det nye projekter blev startet for at forbedre udskrift: LPRng er det bedst kendte eksempel. Andre er PDQ, PPR, PLP, GNUlpr og RLPR. Men ingen af de nye programmer blev set som “totalløsningen”; de fleste af dem implementerer blot den samme gamle LPD-specifikation med nogle få (eller mange) nye udvidelser, som igen gør dem inkompatible med hinanden.

Efter at have set udviklingen af ikke blot én, men forskellige brugbare alternativer til den ærværdige BSD-stil LPD, kaldte Grant Taylor, forfatteren til Linux Printing HOWTO, endelig til oprør LPD må dø! i hans “Campagne til at slå 'Line Printer Daemon' ihjel”.

Sammen med ovenstående var der en indsats på industrisiden af tingene for at besejre de velkendte svagheder i LPD. Det begyndte med ikke-åbne udvidelser til den almindelige gamle LPD, og gik så vidt som Hewlett-Packard®'s forsøg på at etablere HP®-JetDirect som en ny standard for en netværksudskriftsprotokol. Resultatet var endnu flere inkompatibiliteter.

Til slut var der et initiativ til at definere en ny fælles industri- og IETF-standard som tog form. “Printer Working Group” eller PWG, en løs forsamling af forhandlere i hardware, software og operativsystemer, skrev kladden til den nye “Internet Printing Protocol”, IPP. IPP v1.1 er nu blevet godkendt af IETF (Internet Engineering Task Force) som en foreslået standard, og nyder nu enstemmig støtte i industrien i Europa, USA og Japan. De fleste aktuelle netværksprinter-modeller har nu indbygget IPP-støtte oveni den traditionelle LPR/LPD eller JetDirect-udskrift.

IPP ser ud til at ville løse masser af de problemer netværksadministratorer står over for. I dette område drejer det sig normalt om heterogene netværks-miljøer og mere end halvdelen af tiden går med udskriftsproblemer.

Ved at lave et forenet sæt forespørgselsfunktioner for printere og servere der forstår IPP, for overførsler af filer og for at sætte job-kontrol-attributters osv., vil IPP før eller siden komme til at virke henover alle operativsystem platforme. Dette vil imidlertid ikke ske på et øjeblik idet mange gammeldags udskriftsenheder stadig vil være i brug i mange år. Derfor er der, i IPP en metode til bagudkompatibilitet for alle IPP-implementationer. CUPS beviser overlevelsesevnen for IPP-udskrift i alle miljøer.

Den mest slående fordel vil være dens integration i det eksisterende sæt af andre robuste IP-protokoller. Som en udvidelse af den trofaste, robust HTTP-1.1 protokol, for den specielle opgave at håndtere udskriftsfil og relateret data, er det også meget let at stikke andre standarder ind samtidig med at de bliver udviklede og taget i brug:

Har du nogensinde set en demonstration af CUPS formåen på et netværk? Du må hæve været ret imponeret hvis du ikke vidste i forvejen hvad du kunne forvente.

Forestil dig som administratoren for et “LAN”. For testformål installerede du en KDE/CUPS-felt på dit net fuldt ud, med et dusin printere indstillede og funktionelle: PostScript®, LaserJets, InkJets og BubbleJets og så videre. Dine KDE-brugere på den felt er meget glade, de kan udskrive som aldrig før, “med brug af hele pibetøjet” for hver printer. Det tog dig 2 timer at få dethele til at køre perfekt... og nu vil alle de andre 100 brugere på netværket gerne have det samme. To timer igen for hver felt? Ikke tale om du kan gøre dette før næste år, tror du?

Forkert. En enkelt ændring i en indstilling i den originale CUPS-felt gør den til en “server”. Installér CUPS på fem andre felte, som “klienter”. På dettidspunkt du vender tilbage til din første klient, vil du finde at brugerne er i gang med at lege med indstillingerne for det dusin printere du havde defineret tidligere på “serveren”. På en eller anden måde er printerne magisk kommet til syne på alle “Print”-dialogerne på den fem nye CUPS-klient felte.

Dine brugere udskriver, men ikke så meget som én enkelt driver var blevet installeret på klienterne, ej heller er en printerkø blevet defineret.

Så hvordan virker denne magi?

Svaret er slet ikke så kompliceret overhovedet.

Hvis en CUPS-server er på dit LAN, udsender den navnene på alle tilgængelige printere til dit LAN, ved brug af UDP-protokollen og port 631. Port 631 er reserveret som en “velkendt port” af IANA ( “Internet Assigning Numbers Authority”) til IPP-formål. Alle CUPS-klienter lytter efter CUPS-serverinfo sendt til deres port 631. Det er på den måde de kender til tilgængelige printere, og det er også på den måde de lærer om “stien” til printerne.

Ved at bruge IPP, som i birkeligheden er en smart udvidelse af HTTP v1.1, er CUPS i stand til at adressere alle objekter relateret til udskriftssystemet via “Universal Resource Locators” eller URL'er. Udskriftjobs der skal slettes eller genstartes, printere der skal forespørges eller ændres, admin-opgaver der skal udføres på serveren, med IPP og CUPS, er alt adresserbart med en vis URL. Mange vigtige ting kan gøres gennem netgrænsefladen til CUPS, tilgængelig for eksempel med Konqueror.

Og endnu mere, klienterne kan basalt set “administrere” og “bruge” en vilkårlig printer de ser, lige som hvis den var lokalt installeret. Du kan naturligvis sætte restriktioner på den med adgangskontrollister osv., så ikke en vilkårlig klient må bruge en vilkårlig printer som den vil.

Klienterne er ovenikøbet i stand til at udskrive uden det passende filter (eller den passende driver) installeret lokalt.

Så hvordan virker dette? Hvis en klient ønsker at kende til og vælge printer-specifikke tilvalg, sender den en forespørgsel (kaldet CUPS-get-ppd) til serveren. Serveren fortæller klienten alt om alle printer-specifikke tilvalg, som læst fra serversidens PPD. Brugeren på klientsiden kan se tilvalgene og vælge dem der kræves. Han sender så udskriftsfilen, sædvanligvis ufiltreret “raw” PostScript®, med printer-tilvalgene tilføjede til printerserveren, ved brug af IPP som transportprotokol. Al yderligere behandling, særlig filtreringen til at generere det endelige format for målprinteren, udføres så af serveren. Serveren har de nødvendige programmer (“drivere” eller “filtre”) til at gøre dette.

På denne måde udskriver klienterne uden at behøve at installere en driver lokalt.

En vilkårlig ændring på serveren, såsom at tilføje eller ændre en printer, bliver øjeblikkeligt “kendt” for klienterne uden yderligere indstilling.

En anden avanceret egenskab indbygget i CUPS er evnen til at lave “belastnings-balancering”.

Hvis du definerer de samme printerkøer på to eller flere forskellige servere, vil klienterne sende deres jobs til den der først svarer eller er tilgængelig. Dette giver en automatisk belastningsbalancering blandt servers. Hvis du bliver nødt til at tage en server af nettet for vedligeholdelse, vil de andre blot overtage dens opgaver uden at brugerne overhovedet opdager forskellen.