zben@umd5.umd.edu (Ben Cranston) (07/07/90)
amanda@mermaid.intercon.com (Amanda Walker) writes: > If you invent a new protocol, no existing systems will speak it. Therefore > you are pretty well stuck distributing source for the printer driver. Given > wide variety of OSs you'll have to support, the code will have to be pretty > d**ned generic. "Ted Ede -- ted@mbunix.mitre.org" responds: > Well, just to put in a plug for QMS, they do support printing via > TCP/IP over Ethernet with their Imagen product line. The protocol is > fairly straightforward, and is documented. I never bothered to code > up a print symbiont/daemon for it. You can get one for cheap > from QMS for Un*x, cheap for VMS from Northlake software (providing > you already have IP for VMS [it supports CMU's PD product]), or free from > Columbia for VM and I think MVS. Combined with remote lpr/lpd > capabilities, it's pretty tough not to get to one of these printers if > you really want to. And yes, they support accounting. Last time we looked at Imagen's TCP product it was a simple byte pipe, with every byte sent being interpreted as Impress and no way to do statue querying or out-of-band commands. This means if your printer runs out of paper it can sit there idle all night because the drive software cannot determine WHY it is not printing and so cannot inform a human operator of that fact. In tomorrow's world of distributed printing resources we cannot assume the printer will be centrally located. The protocol DEC uses to talk to its LPS40 over TCP is documented in a series of technical notes. IMHO it is somewhat overkill for a LW-class printer, but it might serve as the starting point for a discussion of what people WANT from a TCP print service protocol. In particular, what KIND of "support for accounting" is needed? Number of pages printed out on that printer in the aggregate? Validation of Kerberos tickets for each page printed? :-) Something in between no doubt... -- Ben Cranston <zben@umd2.umd.edu> Warm and Fuzzy Networking Group, Egregious State University My cat is named "Perpetually Hungry Autonomous Carbon Unit"; I call him "Sam".
mark@imagen.UUCP (Mark Peek) (07/10/90)
In article <6834@umd5.umd.edu>, zben@umd5.umd.edu (Ben Cranston) writes: > Last time we looked at Imagen's TCP product it was a simple byte pipe, with > every byte sent being interpreted as Impress and no way to do statue querying > or out-of-band commands. This means if your printer runs out of paper it can > sit there idle all night because the drive software cannot determine WHY it > is not printing and so cannot inform a human operator of that fact. In > tomorrow's world of distributed printing resources we cannot assume the > printer will be centrally located. Well, according to my documentation (dated August 1986), Imagen TCP/IP supports a TCP "simple byte pipe" called TRANSPORT1 for sending data, a UDP connection for obtaining status called STATUS1 and a UDP based connection for accounting (both reliable and unreliable) called ACCOUNTING1. TRANSPORT1 and STATUS1 are seperable or can be used together. The status that is available through STATUS1 include: - Engine not ready - Engine out of paper - Paper jam - Lacking consumables (toner) - Job in progress Using our host software on a Berkeley system, lpq will report back the STATUS1 status for a given printer. I'm not sure how status is reported on System V. Tomorrow's printing will probably be like today's printing, you have work-group, satellite, or centralized printing. This boils down to whether you have an operator and how far you have to walk to pick up your printout. Mark ---- Name: Mark Peek Mail: Imagen Corp. 2650 San Tomas Expressway, P.O. Box 58101 Santa Clara, CA 95052-8101 AT&T: (408) 986-9400 UUCP: mark@imagen.com or ...!{decwrl,sun}!imagen!mark