weird behavior with ftp.connect on Windoze
johncwhi at mindspring.com
Fri Aug 17 04:31:33 CEST 2001
It's been a while since I've done much Python programming, so my question
may be due to language rustiness, but I think something weird is actually
happening. At my work we had some summer interns whom we used to write some
of the tools that the rest of us didn't have time to write. I convinced my
intern to write a tool in Python which checked the availability of a
hardware test platform which we use to test and debug some of our target
code. It's a Motorola Sandpoint platform, if you're interested.
Our proprietary target OS running on the Sandpoint implements a TCP/IP stack
and supports ftp and telnet. These are the primary means of communicating
with it from other computers. His tool was supposed to check whether any
other users had "grabbed" the Sandpoint for testing/debugging by trying to
initiate an ftp transfer to it and querying for some specific information.
The fatal problem in this approach, as we have found out, is that when
another user has indeed "grabbed" the Sandpoint for testing/debugging, that
user will have an ftp session in progress.
When we use Python's ftplib to try to establish an ftp session when another
user has an ftp session already in progress, Python hangs. I don't think
this is Python's fault, however. If we simply run Windoze ftp, and try to
do the same thing, it also hangs. I'm not really sure what is the root
cause of the problem, but I wonder if our proprietary OS simply can't handle
multiple ftp sessions at once. I've tried to do some basic debugging from
the PythonWin debugger, and it appears that things hang at the point where
Python tries to do a socket.connect. If my reading of the Python code is
correct, the socket.connect uses the facilities of Windows sockets
(?Winsock2?). If that's where it hangs, it probably also explains why the
Windoze ftp program hangs.
So, is there any way around this problem? I first thought I could put the
ftp connect code into its own thread, and give the thread 10-20 seconds to
connect, otherwise kill the thread. The Python threads module doesn't seem
to allow for killing off a thread, though. Would MFC threads provided by
PythonWin be an alternative? Or is there perhaps some souped up version of
the Winsock dll that provides timeouts?
We're using Python 2.1 (ActiveState Python) running under Windows NT 4.0.
Any ideas would be welcome.
BTW, I can't keep up with this newsgroup anymore. It's just too big.
More information about the Python-list