On Wed, Jun 15, 2011 at 12:41 AM, Allen Firstenberg <[email protected]> wrote: > The client in question connects to the server, downloads a file, closes the > connection, then immediately reconnects and downloads another file. (The > first file contains metadata, including the name of the second file to > download.) What we are seeing is that many times, tho not every time, it > enters passive mode, gets the reply... and never seems to issue the RETR > command. And 30 seconds or so later it quits and closes the session.
I can see where our algorithm would lead to this. > What seems simplest and most efficient to me would be to maintain two > ordered lists of Integers, "freePorts" and "usedPorts". > > The constructor would take the array of passivePorts (as it does now) and > add them all to freePorts. > > reserveNextPort() would immediately return -1 if freePorts.size() == 0, and > would otherwise remove a random element of freePorts, verify it with > checkPortUnbound(), add it to usedPorts, and return it. This should also > address the issues in FTPSERVER-264 in a typical case. > > releasePort() would verify the port is in usedPorts, remove it from there, > and add it to freePorts. > > These two methods would synchronize on the object (see below) to avoid race > conditions against the lists. There are some error conditions that need to > be addressed (what if the port to release isn't in usedPorts, for example), > but most of these conditions should raise warnings than cause any major > problems. > > If desired, I can do an implementation of this. Please do. Though, keeping a list of free ports might not be optimal if the list is long (i.e. a big span of allowed ports). /niklas
