FTP Client Application

Download Report

Transcript FTP Client Application

FTP Client Application
CSC 8560
Brian Jorgage
4/27/2004
Basic Approach
• Install FTP Server locally
• Observe interaction between commandline FTP and FTP server
• Read RFC 959
• Iterative Development – “Build a little, test
a little”
Major Design Issues
• Application built in Visual Basic 6.0
• Winsock control used for socket
connections
• Synchronization between client and server
processes is critical
• Need to understand state machine for
Winsock control – based on TCP
Login
• Login accomplished via USER and PASS
commands sent over control connection
• Beginning of synchronization issues
• USER <userid> sent over control line generates
331 response code from server
• On receipt of 331 client sends PASS <pw>
• Initially these were implemented as distinct
command buttons but later the synch logic was
built in
• Present operation has Winsock.connect kick off
whole process
FTP Sockets
•
•
•
•
•
•
•
•
•
•
•
•
RFC specifies one control connection and one data connection for FTP – this
requires 2 instances of Winsock control
Commands sent over control connection (e.g. login, dir, get, put)
Data sent over data connection (actual bits and bytes during file transfer)
RFC specifies that PORT command sent from client will send connect information to
server then Server will initiate the connection
PORT command sends parameters h1, h2, h3, h4, p1, p2
H1 thru H4 are just IP address of client
P1 and P2 are data connection port # converted to mod 256 (e.g. port 4440 = 17 *
256 + 88) – thus P1=17, P2=88
Unable to get this working – TCP state is “listening” but connect request never arrives
from server
Alternate method is to send PASV command to server and wait for response
Server sends an available port number and then client initiates the connection
Second major synchronization issue – return code from server is 227
On receipt of 227 the data connection is established
Get and Put
•
•
•
•
•
•
•
•
•
FTP Get command implemented as RETR command
File transfer is not complete until server sends 226 code
FTP Put command implemented as STOR
3rd synch issue – handshake sequence occurs as
follows:
PASV sent and operation code is set on client (1=LIST,
2=RETR, 3=STOR)
Server responds w/227
Client initiates data connection then branches on
operation code to send LIST, RETR or STOR
Server responds w/150
If operation is Put then parse file and send over data
connection
Text mode vs Binary mode
• Text files and binary files handled
differently in FTP
• Text files require “TYPE A” command
• Default mode in FTP is text mode
• Images and executables need to be sent
in binary mode
• Binary files require “TYPE I” command
Navigation
• Server-side navigation accomplished via CWD command
• Client process responds to double-click event and
parses out directory name then sends “CWD <dirname>”
• Move up to parent directory accomplished via CDUP
command
• Client-side navigation accomplished via CommonDialog
control accessed by “Browse” button
• DIR sent as “LIST” command
• Server response on data connection is displayed on
ListBox control
Managing Connections
• Managing the state of the data and control lines turned out to be an
issue
• Client needs to close the data connection after file is sent
• This is detected by the SendComplete event on Winsock for the
data connection
• On SendComplete the data connection is closed by client process
• Data connection also needs to be closed on completion of LIST
• If Client process exits before both sockets are closed the application
will hang
• Needed to implement logic to avoid this
• FTP command to disconnect is QUIT
• Client process checks state of both lines before exiting
• If either line is still open client sends a warning message
Raw FTP commands
• Raw FTP commands collected together under a menu selection
• This allows Get to be implemented as PASV + RETR menu
selections
• Put can be called as PASV + STOR menu selections
• Also Dir can be called as PASV + LIST
• Text mode is “TYPE A” menu
• Binary mode is “TYPE I” menu
• PORT command is PORT menu – as stated before this connection
method does not work
• Additional commands SYST, STAT, NOOP, HELP added to menu
• STOU (store unique) is a variation on STOR (i.e. PUT) that
guarantees unique filenames on host – menu option is there but
does not work
Remaining Issues
• Cerberus FTP server sends files in 8K chunks
• Each chunk generates a message box
• Message box was used during development but when it
was taken out file transfer was incomplete
• It seems that the server is closing the connection before
the last chunk of data is received
• When msg box is left in it forces the correct sequence to
occur
• Other features to add are Abort, Delete, Mkdir, Rename
• Determine how to implement connection as PORT
command and then retire the use of PASV – default
behavior should use PORT