Frozen socket.

David Bolen db3l at fitlinxx.com
Fri Jun 16 20:01:53 EDT 2000


"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     \
\-----------------------------------------------------------------------/



More information about the Python-list mailing list