I'm looking at running an FTP Client on our MOD5282 system to get some config data off a nearby server. We've started out by running the FTP_Client example code, but it seems to have a problem.
To start with it runs perfectly OK. If we quickly do a reset, to make it run the code again, it fails to get open FTP connection, or fails one of the other operations. If we leave it ten seconds or more before resetting, it seems to work OK.
We've altered the code to loop around automatically on a timer: ten seconds or more is OK, any less and we get failures.
It looks a bit like some connection or stream is being left open somewhere, and it's OK if this times out.
We've tried it with two different FTP servers, no change.
Any idea what's going on?
FTP Client problem
Re: FTP Client problem
Sounds like the socket on the FTP server is being left open. I'm not sure what you mean by "reset", but you should close a tcp connection to free it up on the server. You could test this by making sure you close the ftp client session, then resetting, and see if there is still a delay.
Re: FTP Client problem
FTP runs on TCP.
Background:
A TCP connection is identified with 4 parts, source IP , Destination IP, source port and destination port.
Starting up as an FTP client, three of these parts are fixed, only the source port varies from connection to connection.
When a netburner starts up the first time it tries to select a random source port for an outgoing TCP connection it
uses the timer to try and grab a random value. subsequent connections then increment this value.
On an IP network packets can be lost, duplicated, reordered and otherwise delayed.
TCP takes care of this. Part of this robustness is ignoring packets destined for a recently closed connection.
The FTP server throws out all packets it sees that match recently closed TCP connections for some period of time.
(Called 2MSL wait or TIME_WAIT, it can be as long as 10min depending on server configuration)
So if the very first thing the netburner does is make an outgoing TCP connection then it keeps selecting the same random value.
(We don't have a random number generator) And the server then ignores the request thinking that its getting duplicate packets
left over from the previous connection.
If you are using DHCP the response time of the DHCP server is usually random enough to make the initial port selection random.
If you have static addresses you will see this problem in development where you reset and start over a lot.
In a real deployed application as long as you don't reset more often than the servers every 2MSL time it won't be an issue.
The 2MSL wait time is usually about 2 min.
Paul
Background:
A TCP connection is identified with 4 parts, source IP , Destination IP, source port and destination port.
Starting up as an FTP client, three of these parts are fixed, only the source port varies from connection to connection.
When a netburner starts up the first time it tries to select a random source port for an outgoing TCP connection it
uses the timer to try and grab a random value. subsequent connections then increment this value.
On an IP network packets can be lost, duplicated, reordered and otherwise delayed.
TCP takes care of this. Part of this robustness is ignoring packets destined for a recently closed connection.
The FTP server throws out all packets it sees that match recently closed TCP connections for some period of time.
(Called 2MSL wait or TIME_WAIT, it can be as long as 10min depending on server configuration)
So if the very first thing the netburner does is make an outgoing TCP connection then it keeps selecting the same random value.
(We don't have a random number generator) And the server then ignores the request thinking that its getting duplicate packets
left over from the previous connection.
If you are using DHCP the response time of the DHCP server is usually random enough to make the initial port selection random.
If you have static addresses you will see this problem in development where you reset and start over a lot.
In a real deployed application as long as you don't reset more often than the servers every 2MSL time it won't be an issue.
The 2MSL wait time is usually about 2 min.
Paul
-
PaulSteane
- Posts: 7
- Joined: Fri Apr 16, 2010 3:49 am
Re: FTP Client problem
Thanks, Paul, I think that might be the problem. We have a fixed IP address on the Netburner and so the test code will execute in the same time each time it runs from a hardware reset.
As you say it probably won't be a problem on a real system. We'll see how it goes.
As you say it probably won't be a problem on a real system. We'll see how it goes.