Hi, 

> It seemed that the address accepted by the socket might be 
> None sometimes. And this crashed the whole server.

What pyftpdlib version are you using?
That "None" problem should have already been fixed in 0.5.1 version (see issue 91 ).

> Traceback (most recent call last):
>   File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5
> /asynchat.py", 
> line 219, in initiate_send
>     num_sent = self.send (self.ac_out_buffer[:obs])
>   File 
> "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5
> /asyncore.py", line 
> 331, in send
>     result = self.socket.send(data)
> error: (32, 'Broken pipe')

This is strange. I've never seen EPIPE error thrown this way.

> warning: unhandled connect event
> warning: unhandled write event

Those warning messages should have all been suppressed in 0.5.1 version.
I suspect you're using an old version of pyftpdlib.
What worries me more is the EPIPE error. 
Could you please update to the latest version and tell me if EPIPE is still thrown?

No, it's different from issue 91 . The place where the exception was thrown is a few
lines after that in issue 91 . I'm just using version 0.5.1.
According to my experience, the EPIPE error might be caused by the client 
closing the
socket channel improperly. It may be related to the server under heavy load. However,
a well-implemented client will redo the action when this error happens. So I don't
think it's that critical.

Ok, I identified the problem.
It seems that for some strange reason socket.accept() sometimes return:

(sockobj, None)

...instead of:

(sockobj, (ip, port))

This can be reproduced, at least on OS X, by hammering the server with nmap, like this:

> COUNT=0; while [ $COUNT -lt 1000 ]; do nmap -sT -p 21 localhost;
COUNT=$(($COUNT+1)); done

Apparently it seems to be a problem related to OS X only, since I didn't manage to
reproduce this on Linux by using the same cmd line.
Plus, I've found this: https://bugs.launchpad.net/zodb/+bug/135108 Anyway, this 
is now fixed as r556 , so I would recommend you to use that version of
ftpserver.py as long as a new version will be released.


As for the EPIPE problem it would be cool if you could verify whether the problem
persists also after my last commit (I guess it should).

Almost forgot. The warning messages printed on the screen should be suppressed if you
use the latest revision.

The EPIPE issue should be now fixed as r557 .
Since the problem is asyncore related I've also opened a report on the Python bug
tracker: http://bugs.python.org/issue5661

This is now fixed and included as part of 0.5.2 version.

Added a test case which covers this but in r749 .