[issue28447] socket.getpeername() failure on broken TCP/IP connection

2016-10-24 Thread R. David Murray
R. David Murray added the comment: Your example does not show a destroyed socket object, so to what are you referring? Python won't recycle an object as garbage until there are no remaining references to it. If you think that there is information the socket object "knows" that it is

[issue28447] socket.getpeername() failure on broken TCP/IP connection

2016-10-24 Thread Georgey
Georgey added the comment: Not only does the getpeername() method not work, but the socket instance itself has been destroyed as garbage by python. - I understand the former, but cannot accept the latter. -- resolution: not a bug -> wont fix status: closed -> pending

[issue28447] socket.getpeername() failure on broken TCP/IP connection

2016-10-21 Thread R. David Murray
R. David Murray added the comment: The socket module is a relatively thin wrapper around the C socket library. 'getpeername' is inspecting the *current* peer of the socket, and if there is no current peer, there is no current peer name. Retaining information the socket library does not is

[issue28447] socket.getpeername() failure on broken TCP/IP connection

2016-10-20 Thread Georgey
Georgey added the comment: Hello David, Yes I had the same thought with you that the information of socket is lost at operating syetem level. However, I hope at Python level this kind of information will not be lost. Once the socket has been created by incoming connection, the

[issue28447] socket.getpeername() failure on broken TCP/IP connection

2016-10-20 Thread R. David Murray
R. David Murray added the comment: Unless I'm missing something, this indicates that the problem is that once the far end closes, Windows will no longer return the peer name. And, unless I'm misreading, the behavior will be the same on Unix. The man page for getpeername says that ENOTCONN

[issue28447] socket.getpeername() failure on broken TCP/IP connection

2016-10-19 Thread Georgey
Georgey added the comment: The socket close accident is not caused by queue or calling handle_sock_error at all, it happened right after select error After changing the Exception handling of main Thread: except Exception as err:

[issue28447] socket.getpeername() failure on broken TCP/IP connection

2016-10-19 Thread Georgey
Georgey added the comment: I have changed the code to report any error that occurs in receiving message, and it reports: [WinError10054] An existing connection was forcibly closed by the remote host Well, this error is the one we need to handle, right? A server need to deal with abrupt

[issue28447] socket.getpeername() failure on broken TCP/IP connection

2016-10-19 Thread Martin Panter
Martin Panter added the comment: When I run your program on Linux (natively, and I also tried Wine), the worst behaviour I get is a busy loop as soon as a client shuts down the connection and recv() returns an empty string. I would have to force an exception in the top level code to trigger

[issue28447] socket.getpeername() failure on broken TCP/IP connection

2016-10-19 Thread Georgey
Georgey added the comment: so when do you think the error socket closes? -- ___ Python tracker ___ ___

[issue28447] socket.getpeername() failure on broken TCP/IP connection

2016-10-19 Thread Martin Panter
Martin Panter added the comment: I haven’t tried running your program, but I don’t see anything stopping multiple references to the same socket appearing in the “mailbox” queue. Once the first reference has been processed, the socket will be closed, so subsequent getpeername() calls will be

[issue28447] socket.getpeername() failure on broken TCP/IP connection

2016-10-19 Thread Georgey
Georgey added the comment: As your request, I simplify the server here: -- import socket import select, time import queue, threading ISOTIMEFORMAT = '%Y-%m-%d %X' BUFSIZ = 2048 TIMEOUT = 10 ADDR = ('', 15625) SEG = "◎◎" SEG_ =

[issue28447] socket.getpeername() failure on broken TCP/IP connection

2016-10-16 Thread Martin Panter
Martin Panter added the comment: So is your “automatic closing” due to your program, or a bug in Python? You will have to give more information if you want anyone else to look at this. When I run the code you posted (with various modules imported) all I get is NameError: name 'yellow_page' is

[issue28447] socket.getpeername() failure on broken TCP/IP connection

2016-10-16 Thread Georgey
Georgey added the comment: Yes that is definitely a closed socket. But it is strange that in a single thread server without select module, the socket is never closed until I explicitly use close() method. except: print(sock) #<- here it looks normal time.sleep(3)

[issue28447] socket.getpeername() failure on broken TCP/IP connection

2016-10-15 Thread Martin Panter
Martin Panter added the comment: I still think something is closing your socket object. I cannot see what it is from the code you posted though. If you update the print() call, I expect you will see that it is closed, and the file descriptor is set to -1: print("sock_err @ ", msg[1],

[issue28447] socket.getpeername() failure on broken TCP/IP connection

2016-10-14 Thread Georgey
Georgey added the comment: "Without code or something demonstrating the bug, I’m pretty sure it is a bug in your program" Here is the main Thread --- mailbox = queue.Queue() while True: #print(addr_groups) unknown_clients=[] for key in yellow_page.keys():

[issue28447] socket.getpeername() failure on broken TCP/IP connection

2016-10-14 Thread Martin Panter
Martin Panter added the comment: This indicated to me that the socket object has indeed been closed _before_ you call getpeername(): - print(sock)>>> sock.getpeername()>>> OS.Error[WinError10038]an operation was attempted on something that is not a socket === In this case, I

[issue28447] socket.getpeername() failure on broken TCP/IP connection

2016-10-14 Thread Georgey
Georgey added the comment: I have changed my Username, thanks martin. " But it sounds like you may be closing the socket in one thread, and trying to use it in another thread" -- I do not attempt to "close" it in main thread. Main only detect the connection failure and report the socket

[issue28447] socket.getpeername() failure on broken TCP/IP connection

2016-10-14 Thread Martin Panter
Martin Panter added the comment: The getpeername() method is just a wrapper around the OS function, so it is not going to work if the socket file descriptor is closed or invalid (-1). You haven’t provided enough code or information for someone else to reproduce the problem. But it sounds like

[issue28447] socket.getpeername() failure on broken TCP/IP connection

2016-10-14 Thread George,Y
New submission from George,Y: I need to know the IP address on the other side of a broken TCP/IP connection. "socket.getpeername()" fails to do the job sometimes because the connection has been closed, and Windows Error 10038 tells the connection is no longer a socket so that the method