I'm currently using FTP to read some files onto the MOD5282. I'm following the same code structure in the FTPGetFile example in the NetBurner Runtime libraries document. If I do the FTPGetFile correctly, will I have a TCP connection that stays in the TIME_WAIT state (until the default OS timeout as set in the registry)? I've researched this state for a few hours and just wanted to confirm this.
After reading many files from the FTP server sequentially, there are ~45 active TCP connections in the TIME_WAIT state. If I restart the unit (assume the unit loads the files immediately when restarting) while the connections are STILL in the TIME_WAIT state, bad things will happen since the NB seems to be using the same socket. Is there anything I can do to avoid the TIME_WAIT state (besides lowering the TcpTimedWaitDelay value in the registry)? Or to avoid using the same TCP connection if I reboot the unit while there are existing TIME_WAIT states?
Thanks in advance.
TCP TIME_WAIT state
Re: TCP TIME_WAIT state
In the File get example there are two closes.
one closes the file from the ftp get and naother closes the ftp session.
close(fdr);
and FTP_CloseSession
are you sure your calling BOTH close functions?
one closes the file from the ftp get and naother closes the ftp session.
close(fdr);
and FTP_CloseSession
are you sure your calling BOTH close functions?
Re: TCP TIME_WAIT state
TIME_WAIT is a normal part of TCP.
If the system runs out of sockets it will steal them from time_wait.
From a previous post on this topic:
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
If the system runs out of sockets it will steal them from time_wait.
From a previous post on this topic:
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
Re: TCP TIME_WAIT state
Thanks for the response.
I have another very closely related question, if FTPGetList, FTPGetFileNames, FTPGetFile, or FTPSendFile fail; do you still need to call FTPGetCommandResult?
I have another very closely related question, if FTPGetList, FTPGetFileNames, FTPGetFile, or FTPSendFile fail; do you still need to call FTPGetCommandResult?
Re: TCP TIME_WAIT state
If something fails and you want to stop using that session.
then a close is sufficient, you don't need to do anything elxe.
then a close is sufficient, you don't need to do anything elxe.