classification
Title: Methods of ftplib never ends if the ip address changes
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.2
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: giampaolo.rodola Nosy List: Sworddragon, giampaolo.rodola
Priority: normal Keywords:

Created on 2012-01-05 04:36 by Sworddragon, last changed 2012-01-05 10:50 by giampaolo.rodola. This issue is now closed.

Messages (8)
msg150654 - (view) Author: (Sworddragon) Date: 2012-01-05 04:36
If a client gets a reconnect and a new ip from the provider the methods of ftplib can't handle this and are hanging in an infinite loop. For example if a file is transfered with storbinary() and the client gets a new ip address the script will never end. I'm using the Linux Kernel 3.2 on a 64 bit system and Python 2.7 is affected too.
msg150657 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2012-01-05 09:18
It seems expected behavior to me, and the same issue should apply to all other network libs as well. What would you expect ftplib to do in such case?
msg150658 - (view) Author: (Sworddragon) Date: 2012-01-05 09:39
If the connection gets lost and reconnected again but the ip address doesn't change storbinary() continues the data transfer. But if the ip address was changed due to the reconnect storbinary() hangs in a loop.

I expect either that storbinary() detects the change of the ip address and continues the data transfer like it does if the ip address has never changed or it should throw an exception.
msg150660 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2012-01-05 10:00
What storbinary does is just using a socket to send data.
There's no way for storbinary to ask the socket whether an unpredicted event such as an IP change occurred and neither it should.

As a user, you just shouldn't change the IP address while a network app is running on that network interface and expect it to keep working or raise an exception.  
The consequences are unpredictable and are probably subject to change depending on what platform you're on.

In summary, this is not a problem which should be dealt with by base ftplib or any other network lib in the stdlib.
msg150661 - (view) Author: (Sworddragon) Date: 2012-01-05 10:09
The problem is that it is for example here in germany very common that the provider disconnects the client every 24 hours and gives him a new ip address if his router reconnects. This makes it very difficult to send big files with ftplib.

For example for daily backups I have written an automatic backup script which uses ftplib. The transfer needs some hours and very often it fails (it silently never ends) because I got a new ip address.
msg150663 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2012-01-05 10:28
Since you say the connection hangs I think you can set a timeout:

>>> ftp = ftplib.FTP(..., timeout=30)

That is applied to both control and data connection (and hence storbinary). This way you should get a socket.timeout exception after 30 seconds.
msg150664 - (view) Author: (Sworddragon) Date: 2012-01-05 10:40
If i set the timeout argument an exception s thrown if the ip address is changed. At least it's a workaround but we should think about if Python shouldn't try to detect changes of the ip address.

It would be nicer to continue the file transfer like it does if the connection gets lost without a change of the ip address instead of sending the complete data again.
msg150666 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2012-01-05 10:50
Python can't do that. It's a socket implementation detail. Python just exposes the underlying socket implementation as-is.
I'm closing this out as rejected.
History
Date User Action Args
2012-01-05 10:50:36giampaolo.rodolasetstatus: open -> closed
assignee: giampaolo.rodola
resolution: rejected
messages: + msg150666
2012-01-05 10:40:59Sworddragonsetmessages: + msg150664
2012-01-05 10:28:13giampaolo.rodolasetmessages: + msg150663
2012-01-05 10:09:40Sworddragonsetmessages: + msg150661
2012-01-05 10:00:30giampaolo.rodolasetmessages: + msg150660
2012-01-05 09:39:20Sworddragonsetmessages: + msg150658
2012-01-05 09:18:05giampaolo.rodolasetnosy: + giampaolo.rodola
messages: + msg150657
2012-01-05 04:36:09Sworddragoncreate