Re: Sockets, Sessions, Session handles, and FD handles

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

hi Dennis,

Originally, FTPAPI supported only one simultaneous FTP session.  You'd 
call FTP_Conn(), and it'd connect to the FTP server and return a socket 
descriptor.  You'd pass the descriptor back to FTP_put(), FTP_get(), and 
friends to tell it to do things.  Those procedures would build the 
appropriate FTP protocol commands and send them, and check for 
success/failure.

Lots of settings were stored as global variables inside FTPAPI, this 
included whether the session was in binary/ascii mode, what CCSIDs you'd 
requested, send/receive buffers, various other state information.  They 
were stored globally inside FTPAPIR4, so if you tried to call FTP_conn() 
a second time to connect to a second server, it would all go haywire.

Thomas Raddatz decided to help out by saving all of the "per session" 
information separately for each session by putting it into MODS, etc. 
This way, you could have multiple sessions without them stepping on each 
other's state information.

I insisted upon backward compatibility. I felt that existing programs 
should continue to work without changes.

Thomas therefore decided to keep returning the socket descriptor from 
the FTP_conn(), and keep receiving it to the other routines.  he used it 
as the session index.  His thinking, I guess, is that the caller may 
decide to manipulate the socket directly -- so to keep backward 
compatibility, he had to keep using the socket descriptor as the 
"session handle" as well as the actual FD for the socket.

I personally wasn't worried that the caller would try to access the 
socket directly. I figured it was just an opaque session number, and 
it's not really necessary to use the socket FD as the session index. 
Especially since it seems to complicate things tremendously...

Even worse, many of the variable names that were originally used for the 
socket descriptor are now actually holding the session index because the 
paradigm has changed, but the variable names & comments haven't.

Anyway... I hope that dispels some of the confusion.

Also -- just FWIW -- I may have made changes to the copy of FTPAPI that 
I have vs. the one that's on the web site.  (For example, I know I added 
the ability to restart an FTP transfer in the middle at some point, and 
I don't remember if I ever released that by putting it on the web page.) 
   This means that at some point in time, we'll need to incorporate 
these changes into your updated version.



On 10/21/2010 11:49 AM, Dennis Lovelady wrote:
>
>     Working with FTPAPI (and in particular the session management piece)
>     I'm finding myself confused by the interchangeable use of _words_ like
>     session and socket when the two _meanings_ don't seem to be
>     interchangeable.
>
>     For example, FTP_delete is called with first parameter peSession.  It
>     calls the selectSession(peSession) function, which loops through its
>     occurrences,  looking for a "session" where "wkSocket" is equal to
>     peSession.  It then uses the ordinal position of the located match as
>     a parameter to cmd_occurrsession, which will in turn make that
>     "located" session the "current" one.  OK so far (if we must; it's all
>     changing anyway).    So now, if I've done my math correctly, peSession
>     is equal to wkSocket.
>
>     Then back at FTP_delete, we SendLine() to the wkSocket from the
>     current occurrence... and if successful, we try to  get a reply from
>     our first parameter (peSession).  This (send to wkSocket; receive from
>     peSession) is done consistently throughout the FTP_* procedures.  Then
>     in tsend it is no longer session or socket... instead, it is wwFD!
>     Now correct me if I'm wrong, but wouldn't wkSocket and peSession
>     contain the same value?  I think so, so why all this confusion?!?!
>     There must be an interesting history here that I'm missing, but I just
>     want to make sure I  get this right before I hand it back for you
>     folks to bless.
>
>     To make matters worse, there are procedures that take peSession as a
>     parameter where peSession is intended to be an ordinal index, and
>     other procedures where peSession is a socket handle.  And the final
>     clincher is that both session index and socket handle are 4-byte
>     integers.  All of this seems to invite mistakes.
>
>     So... is it just me or is there a serious need for nomenclature
>     changes in this area?  I truly don't want to step on any toes here (I
>     do that enough elsewhere), so please take my questions and comments in
>     the light of one who wants to improve a process.
>
>     I am actually moving fairly quickly on the changes - it's going even
>     better than I'd hoped, and now it's time to examine the use of that
>     wkSession field, and that's the reason I'm focusing on this now.
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------