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
-~----------~----~----~----~------~----~------~--~---

Reply via email to