Version: (using KDE KDE 3.1.3) Installed from: Compiled From Sources Using konqueror, I connect to ftp://ftp.uk.kernel.org/ While browsing the directory structure, I get various behaviour, such as everything working, entering a directory reports 'directory does not exist', and repeated attempts at the same thing working. I am guessing that konqueror is sometimes opening a new connection, and sometimes connecting to a different server where the directory does not exist. The DNS lookup for a given host name should be done at the beginning the session only.
That isn't a problem for each kio_ftp, but Konqueror can launch more than one to be able to show completions on the tab bar as well as download and let you keep on browsing the file structure.
We have this problem with http as well.. I think when an IO-slave does a successful DNS lookup it should pass the IP number back to the application (KIO::Scheduler) which should then pass that information on to other IO-slaves that need to connect to the same host. We can even go a step further and start doing DNS resolution in the application side if we have proper asynchronous DNS resolution (do we have that at the moment?) If we do that we should also make sure to take care of the case where we get multiple IP numbers and the first one fails to connect.
We do have proper async DNS working. The idea is interesting. Maybe we should extend it to all ioslaves? (If so, change the component in the bug ticket). I also believe there's a duplicate of this, as a wishlist. Let me see if I can find it.
It is no duplicate, but I've found the report I was thinking about: bug #68894. The idea is also to move the name-resolution from the ioslave to the iomaster so that all slaves get the same address. By doing this, we're effectively doing the "cache of negative responses" that I mentioned there: a second ioslave launched would not try again an address that we know not to work. Finally, I must mention that doing this will also require the timeout processing on the iomaster, instead of the slave. The data to be sent to the ioslave would ideally be a KSocketAddress along with the original hostname and port for SSL purposes and for HTTP's Host: header. If passing the binary data is not acceptable, a pair of strings will do (node and service from KSocketAddress).
*** Bug 88855 has been marked as a duplicate of this bug. ***
The problem with doing the lookup in the application is that not every slave uses DNS hostnames. And e.g. http does, but not if it uses a proxy. It may be easier to do the lookup in a kdedmodule, the io-slave should then also report back success or failure in connecting so that the kdedmodule can decide which ip-address to use for requests from other slaves.
That's true. However, the fact that an ioslave does the resolution could create a condition in which two slaves are doing the resolving at the same time and could come up with a different results (filename completion, for instance). Unless the DCOP call to the kdedmodule from the second ioslave blocked it until the first completes the name-resolution. I think this is getting too complex for such a simple task.
*** Bug 94271 has been marked as a duplicate of this bug. ***
Not a kio_ftp specific issue + such issues are better solved by using a local caching DNS server such as pdnsd so that the problem is solved for every application instead of just KDE based ones.
KDE 3 is no longer maintained.
*** Bug 307784 has been marked as a duplicate of this bug. ***