Let's explore the uploading process and examine any
new SFTP messages that are used.
Uploads in SFTP are very similar to downloads,
as they contain a five-step process with a few different messages.
Let's begin by checking out the LFTP script.
I won't rehash all the SFTP general parameters because I
covered most of it in the previous demo.
The main difference here is the last line,
which uses the put command instead of the get command.
We can execute this script to perform the upload now.
Like the SFTP download,
the exchange begins with the client sending a type 1 INIT message
along with its SFTP version number to the server.
The debugs don't show the client's version,
but when the server replies with a type 2 version message,
we see it is running version 3.
Again, I won't detail every minor exchange that follows.
As seen in the script,
the client needs to change directories and get a list of files first.
Feel free to explore these supplementary exchanges after the course,
once you've mastered the core SFTP operations.
Skipping down to request ID number 9 again,
we see the client issue an open message,
targeting R3.cfg.
The server responds with a pointer using the HANDLE message.
The HANDLE is eight 0s again,
presumably because there are no other concurrent SFTP operations,
so the server just counts up from 0.
The client issues the WRITE message carrying type 6.
This starts request ID number 10.
The WRITE message includes both the handle
identifier and the actual data to store.
The STATUS message, which is type 101,
is used for many different SFTP acknowledgements.
In the context of uploads,
the STATUS message indicates success or failure of an upload operation,
which makes it central to the upload process.
Using request ID 10 identifies it as the response to the WRITE message.
Finally,
the client terminates the file transfer operation
using the type 4 CLOSE message, just as it did with the download.
The server acknowledges this with a STATUS message, indicating a successful release of the file handle as well.