어떤 FTP 전송 모드가 널리 사용됩니까?

Question

FTP RFC (RFC959)를 읽고, 내가 본 적이없는 몇 가지 모드를 발견했으며 실제로 인기있는 FTP 소프트웨어 (예 : vsftpd)에서 구현되지 않은 것 같습니다. 특히 stru 명령의 경우 파일 모드 "stru f"만 일반적으로 사용되며 모드 명령의 경우 스트림 모드 "모드 S"만 일반적으로 사용됩니다.

따라서 문제는 상호 운용 가능한 FTP 클라이언트 및 서버 소프트웨어를 개발하기위한 모범 사례를 따를 때 다음과 같습니다.

• 다른 STRU 옵션 (레코드 및 페이지)을 지원하는 것이 유용합니까? 이것들은 아주 구식처럼 보입니다.
• 다른 모드 옵션 (블록 및 압축)을 지원하는 것이 유용합니까? 압축의 요점을 볼 수 있지만 특히 클라이언트/서버가 블록이있을 것으로 예상되는지 궁금합니다.
• 기존 FTP 구현이 어떤 옵션을 지원하는지에 대한 설문 조사가 있습니까?

(모드 1에서는 압축 된 이유를 알 수 있습니다. 클라이언트/서버가 블록 모드가 있을지 여부에 대해 더 궁금합니다).

Answer 1

사용자 정의 FTP 서버를 유지하고 정기적으로 http://cr.yp.to/ftp.html 이런 종류의 질문을 위해. 구체적으로, 나는 유형/모드/stru에 대한 제안을 따랐다. http://cr.yp.to/ftp/type.html 그리고 지금까지는 아무런 문제가 없었습니다.

Connect를 본 클라이언트는 "stru f"외에 stru 요청을 보냈습니다. 마찬가지로, 나는 "모드 S"만 본 적이 있습니다.

Answer 2

오픈 소스 FTP 클라이언트 및 서버 (특히 적극적으로 업데이트되는 서버)를 검색하고 이러한 "쓸모없는"전송 모드를 구현하는 수를 살펴 보는 것이 좋습니다.

나는 FTP 클라이언트를 한 번 (약 7 년 전) 만들었고 가장 기본적인 전송 모드 (ASCII 및 이진을 올바르게 기억한다면)를 구현했습니다. 서버를 사용할 때 어떤 서버도 문제가 없었습니다.

Answer 3

상호 운용성에 주로 관심이있는 것 같습니다. 대답은 클라이언트와 서버간에 약간 다릅니다.

서버의 경우 클라이언트가 사용하는 기본 모드를 구현하려고합니다. 모든 클라이언트의 경우 최소 하나의 구성을 지원해야하므로 조합 수가 비교적 낮아야합니다. 최소값을 넘어서서, 활성 및 수동 모드를 지원하는 최소화는 아마도 주요 추가 일 것입니다 (Mozilla Community는 오랫동안 수동적 지원을 원했습니다. 아마도 결코 일어나지 않을 것입니다).

고객이라면 우수한 URL 지원 및 날짜/시간 처리를 제공하는 것이 가장 큰 장벽 일 것입니다.