ftp 的socket问题

homegirl

我在linux下用socket实现ftp客户端，对于list这个命令，我代码实现如下
int uc_FtpClient::ListDir()
{
    bool bRet = ftpListen();//实现数据链路的监听
   strCommand = "LIST\r\n";
     bRet = SendCommand( strCommand);
     bRet = RecvCommandEcho(strMsg); //问题出现在这，
   //strMsg是：“150 here comes the directory listing.\r\n226 Directory send ok\r\n"
     std::cout << strMsg << std::endl; //但前两三次，
   //这里显示：150 here comes the directory listing.\r\n.  
     //226 Directory send ok\r\n 没有显示,两三次后，这句也出现
   bRet = ftpCreateDataChannel();//创建数据传输通道
   long recv_size = RecvData( cBuf, MAX_FILE_LEN );//接收传回来的数据
     std::cout << cBuf << std::endl; //显示接收到的目录信息
   ftpCloseDataListen(); //数据传送通道关闭
   RecvCommandEcho( strMsg ); //再次接收一次命令返回码
   //前两三次，因为，上面的RecvCommandEcho( strMsg );只接收到一句，这句运行良好
}

safedead

1.不要用C++搞FTP

2.以vsftp为例:
第一次LIST, 流程如下:
C->S: PASV
S->C: 227 .Enter passive mode （a,b,c,d,e,f）
C->S: LIST
S->C: 150 here
S->C: (data)
S->C: 226

如果对同一目录第二次LIST，则:
C->S: PASV
S->C: 227 .Enter passive mode （a,b,c,d,e,f）
C->S: LIST
S->C: 150 here
S->C: 226
S->C: (data)

而windows的IIS不这样，总是第一种
150和226同时发送是FTP流水线响应扩展，
客户端程序应该考虑到

langue

应该还有 extended passive mode

另外，看看各种系统上自带的 ftp 程序的代码，尽量不要用别人提供的所谓函数库。能自己实现，达到目的的，就避免用别人的库。

BTW，楼主的注释写成这样，没几个人能看明白。

醉卧水云间

原帖由 safedead 于 2006-10-12 20:36 发表
1.不要用C++搞FTP

2.以vsftp为例:
第一次LIST, 流程如下:
C->S: PASV
S->C: 227 .Enter passive mode （a,b,c,d,e,f）
C->S: LIST
S->C: 150 here
S->C: (data)
S->C: 226

如果对 ...

C++不能做FTP的东西？不会吧。

homegirl

原帖由 safedead 于 2006-10-12 20:36 发表
1.不要用C++搞FTP

2.以vsftp为例:
第一次LIST, 流程如下:
C->S: PASV
S->C: 227 .Enter passive mode （a,b,c,d,e,f）
C->S: LIST
S->C: 150 here
S->C: (data)
S->C: 226

如果对 ...

我如何分析这种流程差别。我使用判断是否有“226...."但也不行，每次都判断到，而导致有返回码没读到，如果不判断，几次后，最后一个RecvCommandEcho（）却在死等而读不到数据。如何办？

homegirl

我在gdb下，每次都得到“150 here comes the directory listing.\r\n226 Directory send ok\r\n”，都能打印这句，但是在普通方式下，却有时候只打印前一句，有时候打印两句。不知有谁知道？

homegirl

也就是说：对于socket的receive数据，每次都能读到“150 here comes the directory listing.\r\n226 Directory send ok\r\n”，但是用cout<< msg <<endl打印的时候有时却只能打印“150 here comes the directory listing.\r\n”，有时能全部打印，但每次查找“226”这个字符串（msg.find("226") >0 )的时候都能是真。

safedead

其实不光是150和226响应可能会在一次recv()中收到
一般公网上的FTP大站在USER/PASS成功之后会发送
带有很多行类似2xx-abcd\r\n的响应，需要收齐之后才能发命令
否则是乱的，需要按照类似HTTP的方式接受多行响应（这不是RFC959的内容）

如果是IPv6的FTP
则需要用EPSV取代PASV
227响应的格式变成:
227 (||||port)\r\n

不过，服务器发送150和226确实不是一次发出的，但TCP的NAGLE算法捣鬼
会把相隔很近的两次send()合并成一个TCP报文，结果你有时recv()一次就收到了，
但有时226却是在断开数据连接之后收到

FTP协议看似简单，但编写FTP代理服务器就特别麻烦
比编客户端还要麻烦
比如某些情况下recv()收到的只是半行响应（缺\r\n），这些都要判断，
否则客户端连接FTP代理会卡住（IE和FireFOX都等待完整的FTP响应行）
而FlashGET之类则会容忍轻微的格式错误（“错误”指没有严格符合RFC959）