client derived from async_chat

[Patrick Useldinger]

Has anybody got such an example? My server works fine, but my client
does not :-(

 

[Patrick Useldinger]

I tried to run your sample but you didn't include enough material for me
to run it as a standalone application. When I tried to stub out the
additional material you didn't include, I got connection refused errors,
presumably because the server wasn't running at the point your clients
tried to connect.

Look at the following code:

sock=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
#sock.setblocking(0)
print 'connect rc=',sock.connect_ex((EBHost,EBPort))
try:
sock.send(message+BLOCKEND)
response=sock.recv(BUFFSIZE)
finally:
sock.close()

If I run it without the 'sock.setblocking(0)', it works fine. If
uncomment that line, I receive the following error:

File "I:\My Programs\sas\sasLA0.py", line 18, in ?
response=sock.recv(BUFFSIZE)
socket.error: (10035, 'The socket operation could not complete without
blocking')

This is exactly what seems to happen with the async_chat class, as in
dispatcher.create_socket the same setblocking(0) is done.

If you just could shed some light on what this error means, I haven't
found any explanation up to now.

Thanks.

 

[Erik Max Francis]

This is exactly what seems to happen with the async_chat class, as in
dispatcher.create_socket the same setblocking(0) is done.

If you just could shed some light on what this error means, I haven't
found any explanation up to now.

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).

 

[Patrick Useldinger]

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

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

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

 

[Patrick Useldinger]

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