Newsletter Archiv

Tech?Update!: Druckprotokoll LPD/LPR – RFC-konform oder "The Microsoft Way"

Das plattformunabhängige Druckprotokoll LPD/LPR haben wir bereits in einem Tech?Update! vorgestellt. Es ist im Request for Comment (RFC) 1179 der Internet Engineering Task Force (IETF) definiert und hat sich als Standard etabliert. Dennoch verhält sich der Microsoft Windows Standard TCP/IP Port beim Drucken über dieses Protokoll in einem Punkt eben nicht "standardgemäß" RFC-konform, was in manchen Fällen zu Fehlermeldungen führt.

Druckjoblänge beim Drucken über LPD/LPR
Zu den Merkmalen eines Druckauftrags gehört auch die Angabe zu seiner Länge als "Byte Count". Laut RFC 1179 muss beim Drucken über LPD/LPR die Druckjoblänge bei der Datenübertragung angegeben werden. Wenn die Druckjoblänge bzw. der Byte Count eines Druckjobs unbekannt ist, muss er laut LPD/LPR-Standard mit dem Wert "0" angegeben werden. Zur Ermittlung des Byte Count muss der Druckauftrag zweimal gespoolt werden: Einmal, um die Druckjoblänge festzustellen, und dann noch einmal, um den Druckauftrag an den Spooler zu schicken. Das allerdings kostet Zeit und senkt die Performance.

"The Microsoft Way": Abweichung vom LPD/LPR-Standard im Microsoft-Verfahren
Der Microsoft Windows Standard TCP/IP Port umgeht dieses doppelte Spoolen und schickt den Druckauftrag direkt zum Drucken an den Spooler. Dabei wird die tatsächliche Druckjoblänge nicht ermittelt. Statt dessen wird eine willkürlich festgelegte, sehr große Druckjoblänge angegeben ("999..."), um den Druck schnellstmöglich einzuleiten. Sobald der Druckauftrag übermittelt ist, bricht der Port Monitor die Verbindung einfach ab. Auf diese Weise spart das Verfahren die Zeit für einen Spool-Vorgang und erhöht die Performance. Allerdings ist dieses Vorgehen nicht konform mit dem im RFC 1179 festgelegten Standard für LPD/LPR.

Für Drucker, die sich strikt RFC-konform verhalten, bricht die Verbindung zu früh ab – die angegebene Druckjoblänge ist auch ihrer Sicht ja noch nicht übertragen – und es kommt zu einer Fehlermeldung. Dies betrifft häufig Netzwerke mit Schnittstellen zwischen Windows und Unix/Linux.

Umgekehrt gibt es aber auch Druckermodelle, die das LPD/LPR-Druckprotokoll nicht RFC-konform implementiert haben. Für sie gilt nur der "Microsoft Way". Wenn solche Drucker als Byte Count den RFC-konformen Wert "0" für eine unbekannte Druckjobgröße übermittelt bekommen, reagieren sie sehr häufig mit Verbindungsabbrüchen.

SEH TPG ThinPrint Gateways können jetzt beides
Unsere ThinPrint Gateways TPG60 und TPG120 verhalten sich in ihrer Werkseinstellung beim Drucken über LPD/LPR RFC-konform. Mit der aktuellen Firmware-Version 10.2.13 lassen sich die Geräte auf das von diesem Standard abweichende Verfahren von Microsoft umstellen, wenn es die Einstellung der Netzwerkdrucker erfordert. In diesem Fall sollten Anwender den Parameter "LPD Mode" benutzen und die Werkseinstellung "RFC [on] / MS Windows [off]" ändern zu "RFC [off] /MS Windows [on]". Danach verhalten sich die TPGs konform zum Microsoft Windows Standard TCP/IP Port. Diese Neuerung in unserer letzten Firmware ermöglicht es unseren Kunden, die TPGs auch problemlos in Umgebungen einzusetzen, in denen Drucker nur den "Microsoft Way" beim Drucken über LPD/LPR akzeptieren.

Weitere Informationen finden Sie im Internet:

Microsoft.com: "Windows 2003 - Printer Connectivity Technical Overview"
Microsoft TechNet: How Network Printing Works
Microsoft TechNet: Network Printer Ports