ojeeves at gmail.com
Wed Nov 21 17:10:05 CET 2007
On Nov 20, 8:32 pm, Vinay Sajip <vinay_sa... at yahoo.co.uk> wrote:
> On Nov 20, 1:47 pm, oj <ojee... at gmail.com> wrote:
> > On Nov 20, 12:26 pm, Vinay Sajip <vinay_sa... at yahoo.co.uk> wrote:
> > > Can you confirm that if you add the while loop back in, all messages
> > > are seen by the server? It worked for me.
> > Yes, it works in that case. This was meant to be implied by my earlier
> > messages, but on reflection, isn't obvious.
> > As I said previously, the point is sorta moot, but if you do have an
> > explanation as to why it behaves that way, or how I'm causing it, I
> > would be interested.
> > -Oliver
> How can you be sure that buffering is not happening at the server end?
Because the server closes the connection after receiving the first
message, which is before the client has even sent the second message.
Although a packet capture is revealing something more interesting.
After receiving the first message, the server sends a FIN/ACK back to
the client, and the client responds with an ACK. However, the client
doesn't send a FIN/ACK back, it tries to maintain the connection and
at the next message sends a packet on the same connection (with PSH/
ACK flags set), to which the server responds RST, which is reasonable,
since as far as it's concerned, it's closed that connection.
So the client has tried, and failed to send the second message.
The client makes no attempt to send the third message.
So basically, the client, the SocketHandler, isn't closing the
connection when the server closes the connection, which isn't
necessarily a problem, but there is still at least one message that
the client logs that generates no network traffic at all.
These tests were done with the time between messages set at 2 seconds.
More information about the Python-list