rsmills36 / pyftpdlib

Automatically exported from code.google.com/p/pyftpdlib
Other
0 stars 0 forks source link

Event on_disconnect doesn't work on network fail #237

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
If any network fail happens while user is connected to FTP server disconnect 
will never happen.

What steps will reproduce the problem?
1. Start basic_ftpd.py from demos
2. Connect to ftp server for example from another PC
3. Make a network problem (turn off network, for example or switch down wi-fi)

In log you will see
[I 13-03-01 01:12:35] >>> starting FTP server on 0.0.0.0:2121 <<<
[I 13-03-01 01:12:35] poller: <class 'pyftpdlib.ioloop.Epoll'>
[I 13-03-01 01:12:35] masquerade (NAT) address: None
[I 13-03-01 01:12:35] passive ports: None
[I 13-03-01 01:12:35] use sendfile(2): False
[I 13-03-01 01:12:53] 192.168.1.3:2912-[] FTP session opened (connect)
[I 13-03-01 01:12:53] 192.168.1.3:2912-[user] USER 'user' logged in.

<Here you are making network problem. Disconnect will never happen.>

I'm expecting a "FTP session closed (disconnect)." after some timeout. Should 
it work this way?

Original issue reported on code.google.com by Fero...@gmail.com on 28 Feb 2013 at 7:36

GoogleCodeExporter commented 9 years ago
Mmm... I'm not sure what should happen in case the network (cable / wifi) gets 
abruptly disconnected. I don't recall ever bumping into such a scenario.
My wild guess is:

- if the client is idle the connection will remain open until it gets 
disconnected because of the timeout (5 mins)

- if not, send() or recv() will immediately fail with ECONNRESET or ESHUTDOWN 

In both cases on_disconnect() is supposed to be called.
However, this looks like something you can't control at user-level code: it 
depends from the underlying socket implementation.

If you want to investigate further you can try to see what happens when the 
client is idle and when it's not. Anyway, I don't expect any particularly 
"weird" behavior resulting from this experiment.

Original comment by g.rodola on 28 Feb 2013 at 8:09