[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Thanks, Scott, that helps a lot!

With regard to your changes, I can do a diff between the web version and
yours, and then incorporate those changes into mine.  Could do that now or
later.  That will be a manual effort, though, because there's radical
difference now between the version I have and the web version.

I look forward to the restart capability.

Dennis Lovelady
"Behind every successful man stands a surprised mother-in-law."
        -- Hubert Humphrey 
> -----Original Message-----
> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-
> bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
> Sent: Thursday, October 21, 2010 1:32 PM
> To: HTTPAPI and FTPAPI Projects
> Subject: Re: Sockets, Sessions, Session handles, and FD handles
> 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
> -----------------------------------------------------------------------

This is the FTPAPI mailing list.  To unsubscribe, please go to: