FAQ

Patrick Useldinger wrote:

Has anybody got such an example? My server works fine, but my client
does not :-(
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.

Furthermore, the error code that you got appeared to be
Windows-specific, so if that's where your problem lies, I can't help
you.

--
Erik Max Francis && max at alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ Sometimes a cigar is just a cigar.
\__/ Sigmund Freud

Search Discussions

  • Erik Max Francis at Aug 17, 2003 at 10:48 pm

    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 && max at alcyone.com && 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
  • Patrick Useldinger at Aug 18, 2003 at 8:35 pm

    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/
  • Heiko Wundram at Aug 17, 2003 at 11:26 pm

    On Mon, 2003-08-18 at 00:30, Patrick Useldinger wrote:
    socket.error: (10035, 'The socket operation could not complete without
    blocking')
    From what I read, this is obvious: Windows is telling you, that the
    (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.
  • Patrick Useldinger at Aug 18, 2003 at 8:34 pm

    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/
  • Dieter Maurer at Aug 19, 2003 at 8:41 pm

    Patrick Useldinger <pu> writes on Mon, 18 Aug 2003 00:20:18 +0200:
    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 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.
    This is exactly what seems to happen with the async_chat class, as in
    dispatcher.create_socket the same setblocking(0) is done.
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedAug 17, '03 at 9:23p
activeAug 19, '03 at 8:41p
posts6
users4
websitepython.org

People

Translate

site design / logo © 2022 Grokbase