How FTP works
FTP session state and roles
Follow the user and server protocol interpreters, transfer processes, login state, and working directories.
8 minute lesson
RFC 959 names a user protocol interpreter, server protocol interpreter, and data transfer processes. In practical terms, the client sends commands while both sides coordinate the data connection.
The server keeps session state: authenticated user, current directory, transfer type, and selected active or passive data endpoint.
A command can therefore depend on earlier commands. FTP is not a series of independent requests like a simple stateless HTTP download.
The dependency is visible in a short session:
C: TYPE I
S: 200 Type set to I
C: CWD releases
S: 250 Directory changed
C: EPSV
S: 229 Entering Extended Passive Mode (|||50022|)
C: RETR app.tar.gzRETR now means “retrieve releases/app.tar.gz as image bytes through the selected passive endpoint.” A reconnect loses that context. The client must authenticate and establish it again.
Some commands create a smaller state machine. RNFR old.txt selects a rename source; only a following RNTO new.txt completes the operation. A different command or failure can invalidate that sequence.
Concurrent automation should use separate FTP sessions. Sharing one control connection lets one task change the working directory, transfer type, or data endpoint underneath another.
Write down the session state after each line above. Then reconnect and list which commands must be repeated before the same retrieval is valid.
Lesson completed