[Python] client derived from async_chat

It'd doing what you asked it to do. Functions that would block return
an error of EWOULDBLOCK (which is translated into a socket.error
exception in Python) if they would have blocked but you have set the
socket not to block. The error is not an error, it's just the system
telling you, "I would have blocked here, but you told me not to, so I'm
telling you that."

The bigger question is why you're asking the socket to not block when it
appears that you really want it to (since your logic isn't handling the
case when it doesn't).

See my answer to Heiko; it's the class asyncore which handles the
(non-)blocking staff, and I relied on that. Now that I've overridden the
connect() method for my client, it works fine.

Thanks for your help.

-Patrick

(still-connecting) socket you created is set to non-blocking, but still
you try to receive data from it, so this means that the operation would
have to block until the socket is finally connected (or fails to
connect).

Remember: connecting is also a non-blocking operation, if the socket is
set to non-blocking mode.

I even think that exactly this error is telling you (IIRC from reading
the UNIX socket docs) that the connection is still in progress; when the
socket later returns some other exception, this means that the socket
could not be established, when read() returns something for the first
time, the socket has been established.

I dunno why async_chat doesn't work with this on Windows (on *nix, this
is exactly what it does), but I guess it has something to do with
decoding the error codes, as a *nix-socket would return EWOULDBLOCK in
this case, for which it checks, I am certain of that.

HTH!

If you need more info on this, feel free to mail me privately.

Heiko.

I should have read some more about sockets before trying to use
async_chat; I thought I would get by 'just adding a few methods'. Shame
on me ;-)

Anyway, what happened is that 'create_socket()' and 'connect()' were
called to quickly one after the other; as async_chat (asnycore,
actually) sets the socket on creation to non-blocking, my connect failed.

I solved the problem by adding a method 'connect()' in my derived class
which looks like this:

def connect(self,*args):
timeOut=self.gettimeout()
self.settimeout(None)
SingleServer.connect(self,*args)
self.settimeout(timeOut)

This did the trick for my chat client.
I think it works as designed, but it was not designed to open sockets
for clients, only for servers. I could have opened the socket outside
the method, probably, but I really wanted the class to handle all of the
network stuff.

Anyway, it works fine now.

Thanks for your explanation.

-Patrick

This is as it should be: "setblocking(0)" tells all socket operations
not to wait but to return immeadiately. If the operation could
not be performed, you receive this exception.
Sure. "async" stands for "asynchronous".

Your program above uses a "synchronous" programming style:
you wait until the socket can perform the operation.
Once, this synchronization is done, the operation is performed
and your program continues. This style calls for "setblocking(1)".

"async_chat" on the other hand uses an "asynchronour" programming
style. Your program registers requests and waits on a main
loop (the "asyncore" main loop) when it has no more requests to do.
The "asyncore" main loop notices when one of the requests
can execute. Then, it calls back the corresponding request handler
It performs the request and may register more requests.


We have implemented clients and servers with "asyncore/async_chat".


Dieter