socket.makefile() buggy?

ahlongxp ahlongxp at
Mon Jul 9 10:42:11 CEST 2007

On Jul 8, 9:54 pm, Steve Holden <s... at> wrote:
> That's a pretty pejorative subject line for someone who's been
> programming Python [guessing by the date of your first post] for about a
> month.
I have to admit it that I'm quite  a newbie programmer.
> Perhaps "Incomprehensible behavior from socket.makefile()", or "I have
> written a buggy network application"? That would at least show that you
> are considering the possibility you yourself are the cause of the
> problem ;-)
Thanks. I'll be more careful about my words.
but I did show some possibility myself is the cause of the problem.
Is there any chance you missed the "?" and "guess" at the same time.

> Python has been around for a long time, so you should ask yourself how
> likely it is that you would be the first to discover such a fundamental
> flaw?
very low but not zero.
Miracle happens.

>I'd be very surprised if someone doesn't point you at an article
> on "how to ask smart questions", but I will content myself with that
> oblique reference.
The big problem is that, I didn't know such a person like you before.
It's my misfortune.

> The big problem here seems to be that your server is closing the socket
> after reading 99 bytes, but the client is actually sending 120. If you
> change the "99" in the server to "120" you will see that the client
> works when it uses the makefile().read(). I can't be bothered to debug
> the exact reason why the 21 bytes of buffered data doesn't cause a
> problem with the recv() version, but I wouldn't regard the error you are
> getting as a bug in Python, rather as a bug in your application.
I don't know the underlying details of networking.
But with recv()  version I can get things done as expected while
version can't.
I guess it's not that unreasonable to make a guess like I did.
> The underlying cause of all this appears to be your failure to
> understand that network protocols should ideally allow the endpoints to
> determine when a complete message has been transmitted, and to consume
> all transmitted data.
> You can't just ignore some or all of a client request and expect it not
> to cause problems.
Back to the problem, I make it working  by adding a sleep(0.5) just
before the
server closes the connection.
Actually this is Hendrik van Rooyen's idea.
And luckily I got a another lesson

>If you look at some of the better-known TCP-based
> application protocols you will see they take pains to ensure that
> clients and servers can deterministically parse each others' messages.
I found something useful in RFC2616--Hypertext Transfer Protocol --
      - If an origin server receives a request that does not include
        Expect request-header field with the "100-continue"
        the request includes a request body, and the server responds
        with a final status code before reading the entire request
        from the transport connection, then the server SHOULD NOT
        the transport connection until it has read the entire request,
        or until the client closes the connection. Otherwise, the
        might not reliably receive the response message. However, this
        requirement is not be construed as preventing a server from
        defending itself against denial-of-service attacks, or from
        badly broken client implementations.

"Otherwise, the client might not reliably receive the response

My problem seems fixed.  But it's not "relialbe" though it's working
good under windows 2k, windowsxp, and linux.
I may reconsider my design and willprobably try dividing request with
body into two steps like HTTP does.
> In summary, a better protocol design will cause you rather less grief
> and a little more humility will result in less acidity from crabby old
> geeks like me.
I do appreciate your response.
I mean it.
> regards
>  Steve
> --
> Steve Holden        +1 571 484 6266   +1 800 494 3119
> Holden Web LLC/Ltd
> Skype: holdenweb
> --------------- Asciimercial ------------------
> Get on the web: Blog, lens and tag the Internet
> Many services currently offer free registration
> ----------- Thank You for Reading -------------

And last but not least,  I' here to be helped and help as long as I
But as you noticed I'm not very good at expressing myself in English.
I didn't mean to offense anyone but I might seem to be rude or
I hope you can understand.


Software College,Northeastern University,China
ahlongxp at

More information about the Python-list mailing list