Path: utzoo!utgpu!watmath!clyde!bellcore!rutgers!mailrus!ncar!noao!arizona!naucse!pab
From: pab@naucse.UUCP (Paul Balyoz)
Newsgroups: comp.misc
Subject: Re: New Ideas in BBSes (No BS!)
Message-ID: <1051@naucse.UUCP>
Date: 9 Dec 88 04:00:26 GMT
References: <8140@dasys1.UUCP>
Distribution: na
Organization: Northern Arizona University, Flagstaff, AZ
Lines: 139

From article <8140@dasys1.UUCP>, by tneff@dasys1.UUCP (Tom Neff):
> In article <87@stanton.TCC.COM> donegan (Steven P. Donegan) writes:
>>                                                               By the way,
>>server -> client is the proper structure, not client -> server. After all,
>>lots of Clients without a Server doesn't accomplish diddly( and a Server
>>without Clients can exist quite happily thank-you).
> 
> Actually (many servers) <-> (1 or more clients) is the right
> structure.  The original posting characterized the BBS program as a
> "server" and the users who dialed into it as "clients."  This can't be
> right in the modern "X" understanding of those terms.  Each user's
> smart terminal software would comprise a display server, while the
> central BBS program would be a client (perhaps one of several) which
> would communicate with each users's display server via the appropriate
> network services (async, LAN or whatever).
> -- 
> Tom Neff			UUCP: ...!cmcl2!phri!dasys1!tneff

The client/server idea really is the way to go.  But the question is
how far do you want to go when implementing it?  Let's look at what
could be done, given unlimited time and resources.

There exists a server process on a computer, which is being the "host"
of the BBS, to which it's users dial in and connect to.  We are
assuming multitasking, multi user ability, multiple modems and phone
lines, because a single process host with a single modem and phone line
is a subset of this more complex system.  Design this bigger version,
and the same ideas will work for the smaller hosts, such as personal
computers.

The Server centralizes all BBS concepts, such as real-time
conversations between users ("chat" or "CB radio") and system messages
(Sysop broadcasts a message to all users), as well as stores and
maintains all data-bases for the message-base, electronic mail,
downloading, news, etc.

The Client is a "front-end" to the server, converting the information
from a cryptic but compact, well-documented BBS protocol (which goes
across the modem connection) into a more user-friendly display
(possibly including graphics, if the client knows what to draw when).
Thus the transferred codes may look remotely like:    T74     causing
the client to interpret this as it knows how, displaying the message:

	"There are 7 letters in your mail box, 4 of which are unread.
	 Someone paged you earlier, but you weren't around."

(Maybe the "T" stands for True: someone paged you earlier.)

Now, because the transmission consisted of three ascii characters
instead of the two-line text stream in English, we've achieved an
*impressive* transmission speed far beyond that of generic BBSes of
today.  The assumption of course, is that all users have a version of
this client software running on their particular system.

But what can we do for people dialing in with dumb terminals?  Or with
small micros which best emulate a dumb terminal?  There should be
client software available in runnable form on the host machine, not
just the server.  Then the scenario would be like this:

    Dumb Terminal  <==modem==>  client process  <-->  server process

    \____  _____/		\________________  ________________/
	 \/					 \/

   user's terminal			    host computer

Now our host is doing a little more work for this user than a
present-day BBS, but it is acting just like one.  The English text
strings now have to be sent over the modem resulting in the same
slow-down as other BBSes, but we have the distinct advantage of being
ABLE to serve those with the special client software.  In other words,
the user is given yet another incentive to upgrade from his dumb
terminal to something better:  a pronounced improvement in his
telecommunicating.  And if an average host running this server and
client system has, say, half of its users using our BBS's client
software and half not, then we have already achieved a definite
improvement in speed over the old-style BB systems.

How do we get the client software out to the population?  Easy.  One
of the downloading sections of our BBS just happens to contain the
client executable code for various computers that users might have.
The host notes when this user isn't using any client software yet, and
asks him about his system.  Is it a dumb-terminal?  If so, then it
bears with them, letting them use the BBS from that perspective.  If
they really have a computer running some kind of terminal-emulation
software, then are they interested in a vast improvement with a
refined, user-friendly interface?  If so, allow them to download the
client software appropriate for them.  Next time they call back, they
will probably be using that client program!  As additional
encouragement to use the client software, they can be told about areas
that are only accessable via client software interface:  graphic games,
artwork, background downloads, etc., which are not implemented in
text-only form.  And the latest client software will always be
available from the host, because it came with the server software to
begin with!

The interface for the server <-> client interface must be well-defined,
clear, and well documented.  More importantly, it should be public domain!
(What would things be like if _readnews_ was our only news reader?!?)

Security issues are simple.  Don't leave choices up to the client
software - the ultimate yes/no control over the BBS is left to the
server's decision.  This way, when people implement their own clients,
they can't say "broadcast to everyone on the system," "read that other
users mail," or anything else -- unless the server allows them to.
This way nobody can write a client which can disrupt the BBS.

Some of the more advanced implementations can include multiple hosts
connected via a LAN, each one having a server, for a HUGE BB system,
should the owner of such a system wish to bring one up!  This high-end
version would still fit in with the above description, as there would
only be one "virtual server," because each physical server would trade
any and all info with all other physical servers.  "Gee, download THAT
file?  Lets see, it's not on my hard disks; oh yea, server #7 over there
has it.  Hey server #7, can you send this file to me over the LAN?
Thanks..."  And the download begins.

				--------

I sincerely apologize for the length of this document!  I've been
thinking about these ideas for a long time, ever since I implemented a
bulletin board system of my own design on a local Honeywell mainframe a
few years ago.  (8000 lines of Fortran, and not too interesting; but
gave me many ideas!)

What do you guys think?  Is it do-able in under 100,000 lines of C?
What would be the minimum size host that you'd need to support a system
as large as this?  (Hopefully a honed-down version would even function
on Apple II/TRS-80/IBM-PC type machines).  I will take all flames with
reasonable humor, as all this is still only in the design stage....

			"when can we start?"-edly yours,     -- paul

--
-- 
Paul Balyoz           uucp: {ucbvax!allegra,ihnp4}!arizona!naucse!pab
P.O. Box 1972
Flagstaff, AZ 86002
--