Subject: Non-networking MOO

From: Forrie Aldrich <[email-masked]>
Date: Mon, 3 Aug 1992 19:26:41 -0700

There was some brief speculation/talk earlier about hacking LambdaMOO to
compile and run on a non-networking machine.  The subject was quickly
dropped; however, I'm curious if anything resulted from this or if anyone
has accomplished this task.

I'm desperately trying to get LambdaMOO to compile (and RUN) on my
platform.  Undoubtedly, I will have difficulty considering my networking
library is older and was written (hacked is more appropriate) by the
Wollongong Group.  While the necessary routines are there, it is unlikely
that I will be able to RUN it (if it gets compiled) because I lack an
ethernet board.  You can't do a loopback if you don't have a device that
will loop back the packets...

Anyways, I would really appreciate some help with this... it's very
important to me, and I have been diligently trying for some time to find a
way to accomplish this.

Thanks in advance... any help/advice would be greatly appreciated.

-- 
	   -----------	      Forrest Aldrich	      -----------
	   -------     [email-masked]	  -------
	   ----						     ----
	   --	     VISION GRAPHICS --	Dover, NH - USA	       --
	   ------------------------------------------------------

---

From: [email-masked] (Jay A. Carlson)
Date: Tue, 4 Aug 1992 21:59:00 -0700

> will loop back the packets...

I can't remember if Wally does this for sure, but most TCP/IP
implementations I've seen have a loopback pseudodevice (interface)
that is always there.

What platform is this?  I'd guess SysVr3.[12], but it'll be hard to
help without more specifics.  I suspect the linux version (if there is
one right now) would be a good place to look for non-networking stuff
for Unix systems.

--Jonny

ObRant:  I suffered under the Wollongong Group's software on a 3b2.
To add insult to injury, the telnetd prints "WINS Telnet Service" when
you log in remotely.  If said machine comes under my administrative
control this fall, I'm going to take a binary editor and make it say
"LOSES"...

---

From: Pavel Curtis <[email-masked]>
Date: Fri, 7 Aug 1992 11:10:18 -0700

> Date:	Mon, 3 Aug 1992 19:26:41 -0700
> From:	Forrie Aldrich <[email-masked]>
> 

Well, I've finally gotten sufficiently tired of saying `no' to this question
(which I've heard many times from many people) and also gotten sufficiently
motivated to acquire a very good book covering all of the standard UNIX
networking and interprocess communication facilities (both BSD and SysV).  I
plan to include in an upcoming release (maybe the one in a week or so, but more
likely the one after that, at the end of August) support for several different
kinds of networking in the official MOO release.

Here are the networking kinds I am prepared to support:

1) For BSD-style systems that *have* access to a real TCP network, code
   like that currently in the server, using AF_INET sockets.

2) For BSD-style systems that *do not have* network access, code using
   AF_UNIX sockets.

3) For SysV-style systems that *have* access to a real TCP network, code using
   the TLI interface and assuming the existence of /dev/tcp.

4) For SysV-style systems that *do not have* network access, code using either
   FIFOs or message queues.

5) For most systems, including some non-UNIX platforms, a single-user set-up in
   which the user is `connected' on the standard input and output of the server
   program itself.

The code will be organized such that options 1-4 share a new, generic version
of bsd_network.c that makes calls on a small number of routines for which each
option will provide a different implementation.  Option 5 will replace
bsd_network.c entirely.

I have included among the options only those that I can test out myself locally
and that appear to have people who need them.  If you need some option that's
not listed above AND you're willing and able to provide me with detailed
documentation for that option AND you're willing to act as a *responsive*
testing site, please feel free to write me (not the MOO-Cows list).

For options 2 and 4, users will not be able to use `telnet' or any of the other
standard MUD client programs, since the servers will not be listening for TCP
connections.  I intend also to make available a version of tinytalk that can be
compiled in a compatible way to make connecting easy.

Finally, if you're a knowledgeable SysV user, I have some extra questions for
you:

-- Does every SysV box have both FIFOs and message queues?
-- Are there SysV boxes that provide both TLI and /dev/tcp but not BSD-style
   sockets?
-- Is there more than one set of conventions for using /dev/tcp?  I only know
   of the one described in the book `UNIX Network Programming'.

	Pavel/Haakon