>TCP takes care of the reording of packets and error correction. >TeleFinder, on a TCP connection, will either get 100% perfect data from >TCP-IP, or nothiing. > >When there is a lot of noise, TCP-IP will need resends, and this will >sometimes result in duplicate packets. If its bad enough, it won't get >enough good data to reassemble valid IP packets, in order, and will just >hold on to the data until it does. This will cause TeleFinder to time >out, and request a resend at its level, but that wont show up in IP >Monitor, it shows up in TeleFinder's monitor, the Transfer Status >window. > >Make sense? > > >Rusty Tucker >Spider Island
However, Rusty, if the TF User does not get the request to resend or does not resend, or hangs or drops quits, the TF server is left hanging and even doing a hard node stop to that TCP node does not reset that node and if the user tries to connect again, he is told that he is already logged on.
Most of the time, it is necessary to do a force quit of TF server when that condition exists.
I suggest that you use a dialup connection to a dial-up ISP, connect to your TF server via TCP/IP through that ISP then during a transfer of data to your server, force your TF User program to quit (while the transfer is going on.) This usually causes the TF server TCP active node for that client to remain active and does not logg off the client. The only way to reset that TCP server node is to do a force quit of TF server.
I find that this happens most of the time I use a dial-up connection to an ISP and then use TCP/IP to connect to my TF server on a dedicated leased line.
