client derived from async_chat

Discussion in 'Python' started by Patrick Useldinger, Aug 17, 2003.

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

    --
    Real e-mail address is 'cHVAdm8ubHU=\n'.decode('base64')
    Visit my Homepage at http://www.homepages.lu/pu/
    Patrick Useldinger, Aug 17, 2003
    #1
    1. Advertising

  2. Erik Max Francis wrote:

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

    --
    Real e-mail address is 'cHVAdm8ubHU=\n'.decode('base64')
    Visit my Homepage at http://www.homepages.lu/pu/
    Patrick Useldinger, Aug 17, 2003
    #2
    1. Advertising

  3. Patrick Useldinger wrote:

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

    --
    Erik Max Francis && && http://www.alcyone.com/max/
    __ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
    / \ Defeat is a school in which truth always grows strong.
    \__/ Henry Ward Beecher
    Erik Max Francis, Aug 17, 2003
    #3
  4. Heiko Wundram wrote:

    > 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

    --
    Real e-mail address is 'cHVAdm8ubHU=\n'.decode('base64')
    Visit my Homepage at http://www.homepages.lu/pu/
    Patrick Useldinger, Aug 18, 2003
    #4
  5. Erik Max Francis wrote:

    > 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

    --
    Real e-mail address is 'cHVAdm8ubHU=\n'.decode('base64')
    Visit my Homepage at http://www.homepages.lu/pu/
    Patrick Useldinger, Aug 18, 2003
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. F.G.Testa

    async_chat close socket notification

    F.G.Testa, Nov 12, 2003, in forum: Python
    Replies:
    0
    Views:
    310
    F.G.Testa
    Nov 12, 2003
  2. Jos
    Replies:
    3
    Views:
    827
  3. rix

    problem with async_chat

    rix, Nov 3, 2005, in forum: Python
    Replies:
    0
    Views:
    302
  4. Replies:
    1
    Views:
    378
    myork
    May 23, 2007
  5. Replies:
    1
    Views:
    369
    Victor Bazarov
    May 23, 2007
Loading...

Share This Page