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 --