Re: bf_connect_player(CONN, PLAYER) --> *FTP!!*

• Date: Mon, 5 Aug 1996 01:48:00 PDT
• From:
  Gustavo Glusman <bmgustav@bioinformatics.weizmann.ac.il>
• Content-Type: text/plain; charset="us-ascii"
• In-Reply-to: <Pine.LNX.3.91.960804153128.4270A-100000@tripod.tripod.com>
• References: <Pine.SOL.3.91.960804015449.12764A-100000@pluto>

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

• bf_connect_player()
• From: Colin McCormick <colin@tripod.tripod.com>
• Re: bf_connect_player(CONN, PLAYER) --> *FTP!!*
• From: Michael Moore <mike@mail.datasys.net>

• Re: bf_connect_player(CONN, PLAYER) --> *FTP!!*
• From: Richard Connamacher <phantom@sfsu.edu>
• Re: bf_connect_player(CONN, PLAYER) --> *FTP!!*
• From: Colin McCormick <colin@tripod.tripod.com>

• Prev: Re: bf_connect_player(CONN, PLAYER) --> *FTP!!*
• Next: Re: bf_connect_player(CONN, PLAYER) --> *FTP!!*
• Index: MOO-cows
• Thread: MOO-cows