Restored from previous forum. Originally posted by fweil.
...,
Just for some more adds to this topic, I am using much networking functions and components in my design and found out that PB has not exactly direct calls to protocol level. It's so but it works calling MS functions as you can find at
http://msdn.microsoft.com/library/defau ... _entry.asp
Just it is uneasy to manage client / server exchange because of the requirement to open a tcp network connection with port attribute and the proposed PB functions do not exactly match with this.
One trick is maybe more simple to do for network design 'beginners' which I prefer to use for design clearance is to use an external ftp.exe program like the one you can find on any Windows installation (eg . in Winnt/system32). A regular ftp.exe accepts an batch file as an argument to be executed.
When you use such ftp.exe program you usually key in (after loading ftp.exe) :
open servername
username
password
[cd path]
get file ; or put file which reverse your data stream !
quit
If you enter all ftp commands in a temporary file then you can call :
ftp -s:tempfile
Note that you have to end your tempfile with quit to end it properly.
In a PB program you can build in easy to read and maintain code such :
;*******************************************************
; A regular ftp session should be like :
;
; File download from server to client File Upload from server to client
;
; ftp ServerName ftp ServerName
; username username
; password password
; [cd path] [cd path]
; [bin] [bin]
; get file put file
; quit quit
;
; It works everywhere. But just care about this : file may contain an access path in the get version, not in the put (think and you
; will understand the subtlety.
;
; This procedure and FTPRename should be replaced soon by an internal ftp procedure as soon as possible
;
Procedure FtpSession(Name.s, UserName.s, Password.s, Path.s, File.s, FunctionTag.s)
If UseConsole=1
Print(GetProcessTime$(StartTime)+" : ")
EndIf
If UseConsole=1
PrintN("Procedure FtpSession called")
EndIf
InitNetwork()
;
; If the network access to the server works
;
If OpenNetworkConnection(Name, 21)
;
; Create a temp file named ftps.tmp
; containing :
;
; open Name
; UserName
; Password
; [cd Path] if not empty
; bin
; get/put file
; quit
;
; (notice the EOL concatenation ...)
;
If CreateFile(0, "ftps.tmp")
WriteStringN("open "+Name+EOL+UserName+EOL+Password)
If Path ""
WriteStringN("cd "+Path)
EndIf
WriteStringN("bin"+EOL+FunctionTag+" "+File+EOL+"quit")
EndIf
CloseFile(0)
If UseConsole=1
PrintN(LoadTextFile$("ftps.tmp"))
EndIf
StatusMessage("Calling Ftp")
;
; And finally call the ftp client program file with the appropriate parameters
;
RunProgram(".\Ftp.exe", " -s:ftps.tmp", 1 | 2)
StatusMessage("Ftp closed")
status=1
Else
MessageRequester("Network error", "Server is not reachable", 0)
CloseNetworkConnection()
status=0
EndIf
If UseConsole=1
PrintN("Procedure FtpSession return")
EndIf
If UseConsole=1
Print(GetProcessTime$(StartTime)+" : ")
EndIf
ProcedureReturn status
EndProcedure
;*******************************************************
Maybe you will test this PB code, just cut and paste it but remind to declare EOL as chr(13)+chr(10) somewhere in your source code. I also put a timer for my needs which is not necessary. Here the temporary file is named ftps.tmp, which you will probably delete after use. And finally this example uses an ftp.exe copy in local directory that you can change for any pathaccess/ftp.exe.
So such a code is quite easier to maintain and to understand, and is rather short (if you cancel comments !).
For FTP clients process designers you have to know that if you want to really design ftp functions, you do have to know more about the commands to use.
As shown in Atomic FTP server, internal FTP commands are not like ie :
cd Path
get file
but :
CWD Path
STOR file
!!!
The difference is that when using a ftp client software component, you have a small command parser that translates user level commands in ftp regular commands.
To know more about you have to read the FTP protocol basic documents. It is also interesting just to use ftp.exe MS ftp client in debug mode (just key in debug) to get service messages with internal commands generated by user commands you give. Then you also have server responses. You will for example see that each session command has a 'literal' (internal level) equivalent, and each transfer command also, but for that last set of commands, each transfer starts with a PORT ftp command to tell the server what tcp port to use for next transfer. Which means that in a ftp session datagram you have to manage tcp ports dynamically to work fine.
Enjoy networking and tell me if more info needed.
Francois Weil
14, rue Douer
F64100 Bayonne
