# bf_connect_player(CONN, PLAYER) --> *FTP!!*

Gustavo Glusman (bmgustav@bioinformatics.weizmann.ac.il)
Mon, 5 Aug 1996 01:48:00 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    Colin wrote:
    >Yes, some confusion, though I think my point is still valid.

    It's not - see below.

    >I'm not sure
    >what you mean by "after the PASS command gets executed."  As it is now,
    >each *line* of input from an unlogged-in connection gets passed to
    >:do_login_command().

    This is correct.

    >So in theory, if you _do_ want to log in FTP
    >connections (and again, I am having second thoughts about this) you would
    >have :do_login_command() receive the first *line* of an FTP request, hold
    >input on that connection, read() the rest of the lines (or at least up to
    >the line beginning with PASS) unhold input and return either a player
    >object number or zero.

    No no no no no.
    This is exactly the misconception I *thought* my previous posting on this
    thread had dispelled, and that further posts by others exemplified with
    code...
    What you describe would be correct, *if* only the server logged in
    connections that return valid object numbers with a player bit, *only*
    after the first line is accepted. But this is not the case!

     --> ANY :do_login_command call that returns a valid object number <--
     --> that is_player(), will result in a connection (assuming the   <--
     --> resources are available etc).                                 <--

    This means that upon your ftp connection, when the USER line arrives, you
    make your dbase remember that info, in whatever way you choose. You *don't*
    need to hold the input, read() and such over-complications. When the PASS
    line arrives, the database just needs to check 'do we know this guy
    already'? Is the password acceptable? If yes, just return the relevant
    object number. No read() loop, no lag, no trouble.

    >As we've discussed before, if that read() is
    >blocking, the return value of :do_login_command() is ignored by the
    >server: no login is possible.  If it is a non-blocking read inside a loop,
    >it lags the entire MOO. So this is why I don't understand the "after the
    >PASS command gets executed" part.

    I hope now it's more clear... Feel free to drop by in BioMOO, if you want
    to discuss it further.

    BTW, I wrote above that you should program the database to keep such info
    as USER name (before the PASS arrives), and some examples were provided
    where this was implemented as an associated list. Of course, you can keep
    the info in properties of objects, but the negative object numbers that
    represent incoming connections don't have 'properties' you can set.

    Or do they? ;)

    Actually, there's no need to store the USER info in the database, nor on
    temporary variables of some waiting task. Let me leave that as an exercise
    to the reader. :)

    <FONT SIZE="TINY" ORIENTATION="UPSIDE DOWN">The answer can be found in
    $login:do_login_command in BioMOO.</FONT>

    -------------------------------------------------------------
    Gustavo Glusman               Founder/administrator of BioMOO
    -- Gustavo@bioinformatics.weizmann.ac.il
    -- http://bioinformatics.weizmann.ac.il/Gustavo
    -- BioMOO: telnet bioinformatics.weizmann.ac.il 8888
               WWW:   http://bioinfo.weizmann.ac.il/BioMOO