[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
http://www.linkedin.com/in/dennislovelady
--
"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:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------