How to clean up socket connection to printer

[loial]

I have a socket application that is connecting to a HP printer via port 9100.

Occassionally I get a "Connection reset by peer" error which I am trapping and exiting the script with an error message.

That works Ok, the issue I have is that the next time I run the script I get
"Connection refused" from the printer, which suggests that the printer still thinks the port is is busy, though nothing is printing. I suspect that in some way my socket connection has not been closed correctly?

When I get the "Connection rest by peer" error, I attempt to close the port as follows :

try:
sock.close()
del sock
except Exception, e:
pass

Is there anything else I should do in these circumstances to ensure that my socket connection is closed OK?

 

[Ulrich Eckhardt]

Am 09.07.2013 11:39, schrieb loial:

I have a socket application that is connecting to a HP printer via port 9100.

Occassionally I get a "Connection reset by peer" error which I am
trapping and exiting the script with an error message.

Strange. Why does the remote terminate the connection?

That works Ok, the issue I have is that the next time I run the
script I get "Connection refused" from the printer, which
suggests that the printer still thinks the port is is busy,
though nothing is printing. I suspect that in some way my socket
connection has not been closed correctly?

I'm assuming you are using TCP. Getting a "connection refused" rather
means that there is no server process that is listening on that port. It
sounds a bit as if the printer was kind-of rebooting itself, which first
resets the existing connection and then, after a rebooting, opens the
port again for connections.

Question here:
1. Does the printer accept connections again after some time?
2. Does the printer accept connections if you close and re-open the
Python interpreter?
3. Is there actually a limit to the number of concurrent connections? In
other words, what happens when you try to create a second connection
without closing the first?

When I get the "Connection rest by peer" error, I attempt to close
the port as follows :

[...]

This is useless, the connection is already closed at that point.


Your description suggests that it is a remote problem. I still wouldn't
rule out that it is somehow caused by your code though, but without
seeing that, it's impossible to tell.

Good luck!

Uli

 

[loial]

Replies to questions :

1. Does the printer accept connections again after some time?

Yes, bit seems to vary how long that takes

2. Does the printer accept connections if you close and re-open the
Python interpreter?

Not after a Connection reset error. The script exits after trapping the "Connection reset by peer" error and it is only when a new instance of the script is kicked off that the "Connection refused" issue is encountered.

3. Is there actually a limit to the number of concurrent connections? In
other words, what happens when you try to create a second connection
without closing the first?

I get the Connction refused error in that scenerio too, but as my script exits after detecting the "Connection reset by peer error" there is only everone instance of my script running(and therefore one attempt to connect) ata time, Which is why I am wondering whether the connection is closed properly by my code when the script exits afer the "Connection reset by peer" error. Or is it the printer not cleaning up the connection.?

 

[Chris Angelico]

Replies to questions :

1. Does the printer accept connections again after some time?

Yes, bit seems to vary how long that takes

2. Does the printer accept connections if you close and re-open the
Python interpreter?

Not after a Connection reset error. The script exits after trapping the "Connection reset by peer" error and it is only when a new instance of the script is kicked off that the "Connection refused" issue is encountered.

What's the network between you and the printer like? Are you, for
instance, going through an el cheapo NAT router? I've had some routers
that have a tendency to just randomly dump their NAT mappings (or so
it seems), which results in all manner of fun.

The "connection reset" error most likely means that you thought you
had a connection but the printer (or a router along the way, shouldn't
happen but see above) thought it didn't. You won't actually get the
error until you try to send some more data [1], which can result in
the variance in time. In fact, if the printer is indeed rebooting (as
per Ulrich's suggestion), you could get immediate success (reset,
reconnect, succeed), or you could get a delay of anything up to the
time it takes to reboot (if you "got in" straight after it went down).
What's the longest you've ever seen it take from conn reset to able to
connect again?

It's almost [2] certainly not that you're failing to properly close
the connection, though. I'd be inclined to simply code in a retry loop
(NOT instant, chances are you'll get some fast failures and you don't
want to spin; a progressive back-off delay is usually appropriate
here) and treat the failures as uninteresting.

ChrisA

[1] Unless you're using TCP keepalive, which you probably aren't.
[2] Insane stuff can be done, but hardware is presumed sane until
proven otherwise.

 

[loial]

Well, I certainly suspect the customers network connection to the printer which is over a WAN across half of Europe, but proving that is the problem is another matter.

I can replicate a "Connection reset by peer" error on own printer by pulling the network cable out of the printer. And again I thereafter get the issue of "Connection refused" for what seems a variable amount of time.

But at least I am now reassured that the "Connection Refused" is not due to something my script has not cleaned up.

Thanks