MOO-cows Mailing List Archive
Re: bf_connect_player(CONN, PLAYER) --> *FTP!!*
On Fri, 2 Aug 1996, Gustavo Glusman wrote:
> Colin wrote:
> >> and then read the next "pass YYYY" line *before* deciding on whether or
> >> not to log in the connection. This is not currently possible (except with
> >> non-blocking I/O in a polling loop, very laggy as previously discussed)
> This is actually wrong.
> An ftp client connects to your MOO. You have to do some ftp handshaking,
> otherwise it will stay silent. Eventually, it sends the USER foobar line,
> and you keep this information stored in whatever way you wish. Later on, it
> sends the PASS fribble line. You check whether fribble is foobar's valid
> password, and if yes, you return a valid object number. Voila, the ftp
> connection is logged in. No need to loop reading or something like that.
Sorry, I don't think I was being clear. It's that "later on" bit that is
the problem. If you _do_ want to log in an FTP connection (and to be
honest, I am now not so sure it's a good idea) then :do_login_command()
must perform one or more read()s to get the user's reply to the PASS line.
But unless :do_login_command() returns *without* suspending (which means
without calling read()) then the C function "do_login_task()" ignores the
result and does *not* log in the connection.
Go ahead and try this -- set up a listening object on some port, give it
the following :do_login_command() verb:
count = 0;
while (read(player, 0) != "LOG ME IN")
count = count + 1;
notify(player, tostr("You typed ", count, " lines before logging in."));
where #XX is some valid player. Connect to the port, type a few lines
and then "LOG ME IN". You won't be logged in.
If you change the read(player) to read(player, 1) (the "non-blocking"
option of read(), NOT the default) then you will be logged in. However,
*nothing* else will happen on the MOO until that while loop exits (or runs
out of ticks.) So if someone takes a long time to type in "LOG ME IN" (or
their password, for instance) the MOO lags like Eeyore on valium.
... and this is why I want a "connect_player()" builtin -- so that I can
do a while(read(player, 0)) loop, get all the lines I need, return garbage
to the server, and call "connect_player()" to log in this connection.
I hope that makes more sense now! :) As I said, logging in FTP
connections may not be such a hot idea, but logging in HTTP connections,
that's more desirable. Plus "connect_player()" would be very useful for
linked MOOs and multiprocessor MOOs, as I mentioned before.
Subject Index |