- #Filezilla failed to create listen socket zip file
- #Filezilla failed to create listen socket windows
Yet somehow there seems to be a gap between a socket calling Listen() and that port actually being unavailable for another socket to listen on, at least, that is the only way I can imagine two separate FTP client instances will give the same port to the server to make the data connection on. If I debug this I can see clearly that every time one of the clients tries to decide what port to use (at the moment PORT command should be sent), it will try to start listening on the first port in the range, if it fails (since already in use) it will try the next. I don't think that will really solve the issue since (at least for me) it's not clear yet how this is happening in the first place. This scenario really requires a common port pool between clients, but nobody has reported this problem before. One simply solution is for each FTP client to use a separate range of 10 ports, 21001 to 21010, 21011 to 21020, etc. This scenario really requires a common port pool between clients, but nobody has reported this problem before.īut I'm not looking at this further until I understand what problem we are trying to fix.
#Filezilla failed to create listen socket windows
If it was a single client, the ports would simply increment each time, ditto if Windows was allowed to assign the port. I've still not had a proper response to how this application is designed, but it sounds like there are multiple instances of the FTP client running in the same thread, sharing a small pool of 10 ports, and each client starts from the beginning of that pool for each transfer getting errors if the port is in-use, then trying the next port. FTP client is really half client half, server in active mode. ICS does have a property ExclusiveAddr which sets SO_EXCLUSIVEADDRUSE, but it's not used by the FTP client, mostly by servers. Thanks in advance, I'm really curious what comes out of this ?
#Filezilla failed to create listen socket zip file
I've added a zip file with logging from both the server and clients from my test, in it there is logging from filezilla server, a wireshark capture from the server's perspective, application log from the three clients (things like OnDisplayMessage from the TFtpClient), ICS log from all three clients (ICSLogger) and a wireshark capture from the client machine.īesides I'm really curious what I'm missing here I wonder if this is a bug in ICS code (how is it possible it's able to start two listening sockets on the same port) and if it's something I should be worried about. How is it possible that (besides there are two sockets listening on the same port) it's actually possible to get data to the two different listening sockets while they're listening on the same port, how does the tcp stack in Windows know for which of the two sockets the data should be sent to? The code in PortAsync() tries to setup a listening socket for each connection, apparently it's sometimes able to setup 2 different listening sockets on the same port, how is this possible? I'm quite at a loss how this can happen, for two reasons:
Obviously it shouldn't matter that much, since the port used for the data connection is chosen by the client, not the server. Something needed for this to happen seems timing related, I've not been able to reproduce this with an FTP server from ICS, but I did with Filezilla server. It's a bit hard to replicate in a consistent way, but the smallest I've been able to make it is by making an application which creates three TFtpClient objects, let them all connection to the same server, set to active FTP with a port range (7000-7010) to upload a small file. If a port range is given, the TCustomFtpCli.PortAsync() method in OverbyteIcsFtpCli will see which of the ports is available from given range, simply by trying to start a listening socket on the first port, go to the next if that excepts, etc.ĭuring tests we have seen the strange behavior that when we start multiple FTP connections in rapid succession, it sometimes happens that multiple clients pick the same port for the data connection (so for example client b picks the same port as client a, while client a is still using that port). I'm currently in the situation where I'm using an active FTP client while setting a port range for the data connection.