Re: FTPAPI question

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

Sender: Scott Klement <sk@xxxxxxxxxxxxxxxx>


> Why is there support for multiple sessions in FTPAPI? It uses 
> non-blocking sockets and it is not threaded, thus everything is 
> sequential anyway.

That's true, but it's often useful to be connected to more than one FTP 
server at a time, or to have two simultaneous sessions open.

For example, when processing a directory tree recursively through FTP, 
it's useful to be able to call FTP_listraw() and each time a new directory 
entry is received, do a PUT or GET in the callback from FTP_listraw(). It 
wouldn't be possible to do a PUT or GET in this manner if you didn't use a 
separate session.

Another situation is where people will "poll" for files on FTP servers. 
They'll have an RPG program that's using FTPAPI to connect to FTP servers 
on each of their branch offices. The RPG program then cycles through the 
different connections, doing an FTP_list() on each connection to see if 
there's any files to download.  Since it calls FTP_list() every second or 
so for each office, timeouts aren't usually a problem.

> This is actually a problem cause most FTP servers I am aware of have the 
> habit of timing out a connection rather quickly. Hence the "keep alive" 
> stuff in many generic FTP clients (which is not handled by FTPAPI in any 
> way).

All of the FTP clients that I've seen that have any sort of "timeout" 
controls merely send a SITE command to the server with the new timeout 
value.  Is this what you're referring to?  If so, it can be easily done 
with FTPAPI using FTP_quote().


> I'd like to hear rationales and use cases for multiple sessions (so far,  I 
> have only heard about people having too few sessions; the very same who never 
> close a session). I do not want to hear any evangelism. Fear not, I do not 
> plan to remove support for multiple sessions (actually, I am more concerned 
> about making them thread safe, if they aren't already), unless there is an 
> unanimous vote for that. Just want to understand the need better.

There's no need for making them threadsafe.  RPG is not a threadsafe 
language.  The compiler generates code (that the programmer has no control 
over) that's not threadsafe. The only way RPG it can safely be used in a 
multi-threaded environment is to have THREAD(*SERIALIZE) on the H-spec, 
and since this causes it to be serialized, you'll never have multiple 
threads running at once in an RPG program.
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------