Methods of ftplib never ends if the ip address changes

[Sworddragon]

BPO	13714
Nosy	@giampaolo

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/giampaolo'
closed_at = <Date 2012-01-05.10:50:36.931>
created_at = <Date 2012-01-05.04:36:09.358>
labels = ['type-bug', 'library']
title = 'Methods of ftplib never ends if the ip address changes'
updated_at = <Date 2012-01-05.10:50:36.930>
user = 'https://bugs.python.org/Sworddragon'

bugs.python.org fields:

activity = <Date 2012-01-05.10:50:36.930>
actor = 'giampaolo.rodola'
assignee = 'giampaolo.rodola'
closed = True
closed_date = <Date 2012-01-05.10:50:36.931>
closer = 'giampaolo.rodola'
components = ['Library (Lib)']
creation = <Date 2012-01-05.04:36:09.358>
creator = 'Sworddragon'
dependencies = []
files = []
hgrepos = []
issue_num = 13714
keywords = []
message_count = 8.0
messages = ['150654', '150657', '150658', '150660', '150661', '150663', '150664', '150666']
nosy_count = 2.0
nosy_names = ['giampaolo.rodola', 'Sworddragon']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue13714'
versions = ['Python 3.2']

[Sworddragon]

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.

[giampaolo]

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?

[Sworddragon]

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.

[giampaolo]

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.

[Sworddragon]

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.

[giampaolo]

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.

[Sworddragon]

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.

[giampaolo]

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.