Ok, I think I'm starting to get what's going on here on my windows box: 1) We try to connect non-blocking 2) There is no immediate error so an EWOULDBLOCK is thrown 3) The connection attempt magically continues in the background 4) We loop around and try to connect again 5) The process may be still connecting. In a sane OS we would get EALREADY.
Now instead of EALREADY we get WSAEINVALID. Microsoft says we have to treat that like EWOULDBLOCK or EALREADY. And in fact I can see one WSAEINVALID in a good connection. But in a connection refused, we just continually get WSAEINVALIDs. What should happen in my opinion is that at some point we should go from getting WSAEINVALID back to a single EWOULDBLOCK when the first connection is refused and then a brand new connection is started. But we never do see that. That transition would be a good place to realize we had a connection refused. And even then we'd still never know if the connection was silently ignored. The real problem is we need a way to set a timeout on the connection attempt in the background without making it blocking. Should we be making these socket connections from a separate thread so that it could block and use timeouts? --Steve On Mar 3, 12:30 pm, Steve <unetright.thebas...@xoxy.net> wrote: > Michael, > > Thank you for your detailed explanation. I did see what you checked > in before I started looking at the timeout capabilities. I have to > think there is a better way still. I've been doing some testing and > here is what I have found. > > On windows, with the timeout = 0, all you get are the WSAEINVALID > errors which should tell us something. Microsoft says this means: > "Some invalid argument was supplied (for example, specifying an > invalid level to the setsockopt function). In some instances, it also > refers to the current state of the socket—for instance, calling accept > on a socket that is not listening." > > I understand your concern about using a timeout = 10s, but please > humor me for a moment. > > On windows, with setttimeout(1), I still get an infinite loop because > of this code: > > elif hasattr(errno, "WSAEINVAL"): > if errorno == errno.WSAEINVAL: > print 'WSAEINVAL' > # If we are on windows, this will be the error instead > of EALREADY > # above. > assert(self.connecting==1) > return False > # Anything else is an error we don't handle > else: > print 'else' > raise socket.msg > > You see, we know we're on windows, but all we check and handle is the > WSAEINVAL. So if I change the code to catch _other_ windows errors > like so: > > elif hasattr(errno, "WSAEINVAL"): > if errorno == errno.WSAEINVAL: > print 'WSAEINVAL' > # If we are on windows, this will be the error instead > of EALREADY > # above. > assert(self.connecting==1) > return False > else: > # On windows and unsucessful > raise socket.msg > # Anything else is an error we don't handle > else: > print 'else' > raise socket.msg > > Now on windows, with settimeout(1), with the above code it Does The > Right Thing and raises a 10061 - WSAECONNREFUSED. Yes! > > Now, I understand not wanting to block the system, so I tried > settimeout(0.01). This is interesting because it catches a > socket.error exception, but then throws and exception trying to do > this line: > (errorno, errmsg) = socket.msg.args. So I'm about to try to dig out > the details from the socket.error that is caught to see if it is > something we can handle. > > Bottom line is unless you set some timeout, windows machines won't get > sane connection refused errors. And I can understand an aversion to > 10 secoonds, but what about 1 second? A half a second? What is the > shortest we can block and still get (somehow) a useful error? I'm > going to keep experimenting. > > --Steve --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@googlegroups.com To unsubscribe from this group, send email to kamaelia+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en -~----------~----~----~----~------~----~------~--~---