Re: Talking to LPR over sockets

Hi Doc,

> The RFC itself isn't too long, but it seems kinda involved.  I'd like to
> avoid writing a bunch of code to format LPR requests, if possible.  For
> example, initiate an LPR printer session, I have to:
>
> 1. Contact the LPR service on the target box
> 2. Send a transfer printer job/receieve control file
> 3. Wait for an ack from the service
> 4. Send print short form/receive data file
> 5. Wait for an ack from the service
> 6. Send the data to the service
>    (LPR sends data to the printer immedately, no spooling.)
>    (LPR receives an ack from the printer)
> 7. LPR sends a "printer ack".
> 8. Repeat either 2-7 or 6-7 as needed.
> 9. Close the connection to the LPR service.


I'm not sure that I follow what you're saying.  You want to write an LPR
client.  But, you don't want to write code to format the LPR requests?
Huh?

You could just use the system's LPR client if you don't want to write it
yourself...



> I have two questions about this:
>
> 1.  Has anyone done this before (written an RPG, C, or Java program to
> talk LPR over a socket)?  What were the pitfalls?  What problems did you
> encounter?

Yes, I did one in RPG.  The only pitfall that I ran into was that when a
job had an error, the LPD would try to e-mail me back at the same domain
that the request came from.  For example, if my RPG program was running on
"iseries.example.com" the LPD would try to submit e-mail to
"user@xxxxxxxxxxxxxxxxxxx" despite that my email address is
"user@xxxxxxxxxxx"

I worked around this problem by specifying the host that I want to receive
e-mail on in the "H" parameter of the control file, but still used the
fully qualified hostname on the "C" parameter of the control file.  I
don't know if this will eventually cause me some problems?

Right now I'm only using it with one LPD server, on one of my FreeBSD
boxes, and it hasn't caused me any problems yet there.  But, haven't
tested with other LPD implementations.


> 2.  The RFC is a little thin on how LPD is supposed to behave,
> specifically with errors.  The RFC that says the LPR returns a 0 for
> success, and a non-zero for failure.  What I'm trying to figure out is
> if I write code to support the scheme I've just mentioned, what happens
> if I turn the printer off halfway through a large document?

This is certainly not unique to LPR or even sockets!

With ANY communications program (not just TCP/IP, but anything, APPC,
Serial Ports, parallel ports, etc, etc.) you have to account for the fact
that the power could go out on the remote end, rendering the remote host
unable to respond.  Or the line could be cut.  Or a router in between
could go down.  Or a modem could go bad.  Or a glitch in telephone
switching equipment could happen, etc, etc.

The best way to deal with this is to use non-blocking sockets and the
select() API.  Use select() to time-out your socket after a reasonable
amount of time.

If the timeout does occur, assume that the document never printed.  Return
an error message to whatever program asked you to print the document.
Make sure that someone using your LPR implementation will know that it
didn't work.


> (Assume spooling is turned off.)  Will the non-zero return code be sent
> back to the AS/400?  (I'm skeptical that it will-- if you're printing a
> large document through LPR over a remote output queue, and turn the
> printer off halfway through a print session, the spool file in the
> remote outq gets 'jammed' with a status of 'SND'... and never seems to
> time out.)

As you suspect -- a computer that is off cannot send a response code.
Indeed, it also can't send the packets to tell you that it's disconnecting
it's TCP session.  If you don't time-out, your program will sit and wait
for data forever.

This is why I keep saying on these forums -- a robust application will
always use non-blocking sockets.