FTP上传结束时不一定总能获得226 Transfer OK [英] Don't always get a 226 Transfer OK at the end of an FTP upload

问题描述

我使用FTP客户端编写的文件，有时上传完成后有时会从FileZilla服务器收到226 Transfer OK消息，有时我什么也收不到.并不是在收到226 Transfer OK之前客户端已断开连接，因为我可以在服务器上看到FileZilla从未发送过它.

With an FTP client I've written I will sometimes receive a 226 Transfer OK message from the FileZilla server after an upload completes, and sometimes I won't ever receive anything. And it's not that the client disconnected before the 226 Transfer OK was received, because I can see on the server that FileZilla never sent it.

我需要知道服务器何时收到完整的上载，因为在关闭连接之前，我不知道整个文件是否都到达了网络.

I need to know when the server has received the complete upload, because I otherwise do not know if the whole file made it to the network before I close the connection.

有什么想法可能导致226 Transfer OK消息的不可靠性?究竟是什么触发了它的发送?

Any ideas what might cause the unreliability of the 226 Transfer OK message? What actually triggers it to be sent?

推荐答案

我自己弄清楚了！我发现是客户端在数据套接字端口上发送的FIN/ACK消息提示FileZilla服务器在控制套接字端口上发送226 Transfer OK消息(在数据套接字端口上发送自己的FIN/ACK作为响应之后).

I figured it out myself! I found that it's the FIN/ACK message sent by the client on the data socket port that prompts the FileZilla server to send the 226 Transfer OK message on the control socket port (after sending its own FIN/ACK in response on the data socket port).

在WinRT中，是数据套接字的关闭导致客户端发送FIN/ACK消息.

In WinRT, it's the closing of the data socket that causes the FIN/ACK message to be sent by the client.

因此，关闭FTP连接的正确顺序是(发送完最后一个数据包之后)关闭数据套接字，等待控件套接字上的226 Transfer OK消息，在控件上发送QUIT消息插座，然后关闭控制插座.

So, the proper order for closing an FTP connection is (after the last data packet is sent) to close the data socket, wait for the 226 Transfer OK message on the control socket, send the QUIT message on the control socket, then close the control socket.

这篇关于FTP上传结束时不一定总能获得226 Transfer OK的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！