Subject: open_network_connection()

From: [email-masked] (H. Peter Anvin N9ITP)
Date: Fri, 21 Aug 1992 08:14:49 -0700

I am sorry, first of all, to add this to the universal wish list for the
MOO server when I know how much work it takes to do the server... I am just
worried that if I make a patch it will be obsolete by the time I finish it!

Anyway, would it be possible to add a flag to the MOO side of the
networking interface so that input received from connections created by
open_network_connection() would be queued rather than fed to the builtin
parser if no read() was pending?  I run into the problem while trying to
make a MOO implementation of SMTP that the first line of input (221 service
ready) comes so quickly after the network connection has been opened that
no matter how I do it, I cannot get the MOO to be in read() mode by the
time the line arrives.

Furthermore, such queuing would eliminate (or at least reduce) the problem
about phase errors in action/reply protocols such as SMTP.  It would be
possible to let one task take care of both input and output.

Comments?

	/hpa * Xorbon * Zytor

-- 
INTERNET:  [email-masked]   TALK:      [email-masked]
BITNET:    HPA@NUACC     IBMNET:    16334@IBMX400
HAM RADIO: N9ITP         NeXTMAIL:  [email-masked]
"That dreemless sleep that cures all aches."

---

From: Pavel Curtis <[email-masked]>
Date: Fri, 21 Aug 1992 10:30:27 -0700

> Date:	Fri, 21 Aug 1992 08:14:49 -0700
> From:	[email-masked] (H. Peter Anvin N9ITP)

> ...

> possible to let one task take care of both input and output.

First, let me be the first to admit that the current system of treating
outbound network connections as if they were inbound ones was clearly a crock;
I did it in an evening because someone really wanted some way of making
outbound network connections and this way was easy and cute (in a fairly
grotesque sort of way... :-).

Anyhow, the only way to avoid losing in the current system is that the *very
same task* that calls open_network_connection() *must* be the one that calls
read() and that task *must always* be the one that calls read() and that task
*must not* ever suspend except by calling read() on that connection, all until
the connection is finally closed by someone calling boot_player().

If you follow this rule, then the atomicity of MOO tasks guarantees that there
will never be an opportunity for the server to misinterpret input on the
connection as a command.

Now, I have already been thinking recently about how to rearrange the
modularity of the server to make it relatively `clean' to have the task queues
for outbound connections get marked as, if you will, `read()-only'; this would
eliminate current crockery of it all, including the nasty bit about how the
connection can `time out' and be closed by the server if it remains idle for
more than five minutes... :-(

I may well do something about all this for the next release, along with all of
the other networking changes.

	Pavel/Haakon