Frozen socket. (fwd)

C. Porter Bassett porter at et.byu.edu
Thu Jun 22 11:59:26 EDT 2000


OK, I have been able to duplicate the problem that I was having, but I
still don't know what to do about it.  First things first, I suppose.

I made two small programs, a server and a client, and I got the client to
"freeze" in the exact same way.  My test server accepts three messages,
but after that, it freezes.  For some reason that I don't understand, the
client keeps sending messages (about 1000 of them, just like before), even
though the server is not receiving any.  After about 1000 messages, it
freezes, just like the program I am debugging.

Why is the client able to keep sending messages if the server is not
receiving them?  

In short, what is really happening, and how do I safeguard against it?

Here is the source for the two test programs I am talking about.
sample client:
from socket import *
import time 
sock = socket(AF_INET, SOCK_STREAM)
sock.connect("127.0.0.1",2778)
for i in range(5000):
   sock.send("This is a string of approximately the correct
length.          "
   time.sleep(0.001)
   print i

sample server:
from socket import *
s = socket(AF_INET, SOCK_STREAM)
s.bind(""<2778)
s.listen(5)
conn, addr = s.accept()
counter = 0
while 1:
   counter = counter + 1
   data = conn.recv(1024)
   if couter > 3:
      while 1:
         pass
   if data:
      print data

--------------------------------------------------------------------------
C. Porter Bassett     porter at et.byu.edu   http://www.et.byu.edu/~porter
--------------------------------------------------------------------------
"Pretend like this is a really witty saying." - Anonymous
--------------------------------------------------------------------------

On 16 Jun 2000, David Bolen wrote:

> "C. Porter Bassett" <porter at et.byu.edu> writes:
> 
> > I have looked around, but I haven't been able to figure out why a program
> > would choke on a send() command.  I don't even know if it is because of
> > something I am doing on my end or something happening on the server
> > end.  If it is my fault, how do I fix it?  If it is because of something
> > happening on the server side, how do I compensate?
> 
> Under default conditions, send() may block if there is no room to
> locally buffer the information you want to send.  It's not that it has
> "choked" - just that it's waiting for room to become available.  You
> can set a socket to non-blocking mode, but then you have to handle a
> failure to send() all of your data and keep retrying until it is
> accepted.
> 
> In most cases, this occurs because you have gotten far ahead of the
> receiver - enough so to back up the TCP window size across the network
> and your internal socket buffers.  As long as the systems are still
> actually sending data, it will eventually catch up and you can keep
> sending.
> 
> However, the fact that you say it happens regardless of how quickly
> you send out the strings makes me wonder if the other side is really
> receiving them at all.  Are you absolutely positive that you are
> performing the initial communication properly so that the receiving
> side is really receiving your data?  It may be just that it takes you
> about that many strings to fill up your internal queues while the
> remote system does not receive any data.
> 
> I suppose another possibility is something in the data is causing a
> problem for the remote system such that after receiving that initial
> amount it becomes busy and fails to continue receiving.
> 
> Do you have any other applications that perform this function that you
> might be able to compare/contrast with - having some sort of control
> or pre-existing behavior to compare against might give you some hint
> as to what is going on.  But send() blocking is normally just a
> symptom of something larger happening, and less likely to be a problem
> in the actual send() call itself.
> 
> --
> -- David
> -- 
> /-----------------------------------------------------------------------\
>  \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
>   |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
>  /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
> \-----------------------------------------------------------------------/
> -- 
> http://www.python.org/mailman/listinfo/python-list
> 









More information about the Python-list mailing list