Error: Timeout (control socket)

Describe the bug When i upload large file, i have problem with timeout, file upload full, but not resolving and i’m gettings an error Socket Timeout…

Example code await client.uploadFromDir("videos/" + dirName, "videos/" + dirName).then(() => { console.log('Resolved') resolve() }).catch((err) => { console.log('Rejected') client.close() reject(err) })

Console output Error: Timeout (control socket) at TLSSocket.<anonymous> (C:\croper\node_modules\basic-ftp\dist\FtpContext.js:310:58) at Object.onceWrapper (events.js:308:28) at TLSSocket.emit (events.js:219:5) at TLSSocket.Socket._onTimeout (net.js:476:8) at listOnTimeout (internal/timers.js:536:17) at processTimers (internal/timers.js:480:7)

Which version of Node.js are you using? 12.13.0

[patrickjuchli]

Could you post the whole log output, not just the exception?

My guess is that this is probably a typical problem of FTP. I will use this issue to describe the problem and document the current policy of this library also for future reference.

An FTP client uses two connections, one to send commands and receive answers (control), and another one for file transfer (data). For file transfer it is actually a completely new connection for each file but this is not relevant here. During a long file transfer over the data connection, the control connection sits idle. It is possible that during this time, a router somewhere between client and server disconnects the control connection because it seems inactive. This is not standard behaviour at all but it can happen. Routers either usually don’t do this or then do indeed treat FTP differently by inspecting traffic (!) and know to keep the control connection open. With TLS encryption when using FTPS though, the router can’t inspect traffic and doesn’t know that control and data connection actually belong to an FTP client session. From the outside, these two connections are unrelated and the idle one may be closed.

My guess is that this is what’s happening in your case. Now, what can you do about it?

Some FTP clients send some stuff during file transfer at regular intervals over the idle control connection (NOOP command or something else like PWD). This library opted to not do that because it is not standard behaviour at all and doesn’t work with some servers. The technique has other sideeffects. The current policy is: If you transfer large files that take a long time, you have to take into account that there might be a connection problem anyway just because it’s the internet. You will have to handle this in your code and resume transfer. By doing that you’ll automatically handle the described problem here as well.

Why are automatic retries not built-in? When developing a library like this one, it’s important to define how far you want to go. Is this the model layer for a full-fledged FTP client and all you’d have to do is add a user interface? Or is it one level lower – it covers just the basics of FTP but everything else has to be provided by the programmer. This library took the second approach. The target audience is other programmers. Automatic retries of long-running tasks is not an FTP problem.

Now. Looking at how this library has been used over the last years I can see that a lot of developers have a different understanding, especially beginners. They just don’t know about these problems and do expect the library to handle everything.

I’ll reconsider the decision around this topic. I see that it might be helpful. But it doesn’t have a high priority right now.

[psr1410]

Hi Patrick, We also facing the same issue while downloading larger files(2GB to 6 GB we tested). The control_socket timed out issue. All the file stream was downloaded without any problems(It took around 1hr to download 6GB file). But the real problem occurs here while I’m uploading the downloaded stream to Azure storage it is throwing that control_socket TIMEDOUT issue.

I did what you suggested, Checking the client connection closed or not after each stream chunk downloaded. Interestingly the client connection was active, till the total file downloaded.

How can I check and make control_socket connection active? Can you help me out on this issue?