A Vision of Networking Systems of the Future
by Mike Blaszczak

Modern computers are incredibly fast machines. Over the last six years, the IBM PC-line of computers has developed systems with over sixteen times the speed as original models. Amiga computers and popular workstation-based systems, such as Suns, also exhibit phenominal speed.

Many desktop computers have also come to bear the multitasking features found only in larger systems. The 68000 series from Motorola was one of the first lines of processors to develop its own memory management units.

Even after losing all the marketing mistakes and hype, operating systems are developing with comparitive sluggishness. OS/2 provides for a kludgy page swapper, allthough its multitasking abilities are a panacea for bored MS-DOS users. Unix derivatives, such as Apple's A/UX system, provide the desktop user with a comfortable amount of control over multiple processes.

But precious few other software packages provide for multitasking. Sure, you can set up a print spooler to run your printer in the background, and you can have PageMaker reformat one page while you're adding text to another, but this isn't developing the capability that is inherent in the newer processors like the 80386 and the 68040.

Even sadder, we have long known that the VAX, PDP, and Prime mainframe and minicomputer systems that run our telecommunications services are capable of having more than one user. Even some larger BBS systems make use of systems that have many serial ports and modems tied to an array of phone lines; only to connect to one CPU.

But why can't we make the systems we each use help us with their power? Wouldn't it be great to have a system that you could log in to, compile your conferencing notes, download a file from a users' group, and chat interactively with other users, all simultaneously?

The dedicated architecture (one user, one process) of telecommunications system design must quickly become a thing of the past. Our throughput can improve by several fold, and our communications range can be extended sharply.

What am I thinking of? Well, let me be a little more specific, and perhaps a little more technical.

When a user accesses a computer-based communications system, let's say NJNET, for example, their connection is a one-on-one interaction with their system and the computer. If they're using an old Apple II or if they're using a new IBM PS/2 Model Eighty, all of their system's abilities are being spent on sending data out the port and waiting for it to come back.

Software that has a lot of cushy creature-comforts allows for neat things; you can print information as it falls in your port, and maybe you can even capture it at the same time.

Each of these tasks, even for the most complicated of protocols, such as Kermit or ZMODEM, requries very little CPU time. Even if CPU time were upped by software data compression or run-length encodning as implemented in many high-level communications protocols, more powerful systems like those based on 80286, 80386, or 68020 CPU's could easily handle the load using their multitasking features. The bottleneck of the system is the slow throughput achieved by modems.

Some software, such as Crosstalk Mark Four, allows you to maintain multiple sessions if you have the hardware to support it. While this feature is a great asset for those who have two or three modems and two or three phone lines, it doesn't serve the average user with one line and a single modem.

What I would like to see is a windowed interface for the typical communications system. When you log in to a system like this, you're still at a one-on-one session, but not for long. While you maintain one single connection to one single process, you can request that other processes be set up to run quietly in the background, or that other processes be initiated and given some window space.

When a process is initiated, it can notify the user's terminal that the terminal's client area should be split. So, perhaps instead of having a 80 by 25 screen, I might suddenly have two 80 by 12 screens.

This "smart terminal" approach could use a common protocol, easily implementable on a variety of systems. The protocol could even provide for the host interrogating the client to see if they supported the windowed protocol. Perhaps if they didn't, the system could fall back on a stock TTY-based interface. If the caller did have the windowed software, the software might report the maximum capabilities of the user's system; not only in CPU abilities, but perhaps in screen size, modem speed, and maybe even free disk space. A "termcap" standard might perhaps evolve, such like the one found in Unix systems.

That protocol might initiate each packet with a unique packet header:

<Header>

That header might contain a "stamp" or sequence number to indicate that the user had not missed any packets, and it should certainly begin with a group of rare or "screened" characters so that the receiver could be guaranteed that it just found the beginning of a packet. This would aid in restoring communications, should they become confused by line noise.

The packet then might contain a command:

<Header> <CommandCode>

Obviously, the host would issue a different set of command codes than the client would. For example, the host might send "open window from point x1 and y1 to point x2 and y2", but the client would never need request that the host do that. There might not even be a real "action" or "command" associated with a packet; perhaps a packet might be stamped as the next block of a binary transfer.

The packet would then include the data necessary. Some packets won't need any data. (For example, if the CommandCode were just an acknowledgement, the user wouldn't have to send any data with it.) To make it easy to decode, let's also include a length for the data field.

<Header> <CommandCode> <Dlen> [<Data>]

Since there might not be any data, we could just make the Dlen zero if that were the case. We could follow it up with any one of several checks for integrity; a CRC word or a checksum, and maybe an ending marker.

<Header> <CommandCode> <Dlen> [<Data>] <Check> <Trailer>

When I iniate the connections, all the <CommandCode> fields would just be "place text". The <Data> would contain a mention of what text to place. Perhaps, even ANSI or VT-series terminal escape sequences could be imbedded there to provide for screen control.

If I initiated a new session, as I mentioned above, we might split the screen in two and run the MAIL system in one area and the CHAT program in the other. Since data now has two places to go, perhaps we should add a tag field to each packet that says which window should pay attention to the data:

<Header> <Tag> <CommandCode> <Dlen> [<Data>] <Check>
<Trailer>

Using the object-oriented programming techniques that are becoming so popular, one might find it interesting to implement the protocol to take advantage of the OOP philosophy. Each window would be "notified" that it had data waiting for it, and would reply at will. This would also help get the protocol started on distributed processing systems, such as are found in most multiprocessing environments.

So, in one 80 by 12 window, I might be drafting a letter to a friend. In the other 80 by 12 window, I might be engaged in an online exchange with a representative from XYZ Software, enjoying the online togetherness of the CBIX CB Simulator. When I request the second session, I might get a packet with a <CommandCode> telling my system to set up two windows. The <Data> field of that packet would let the system know where it should put each window, and how they should be sized.

From that point on, each packet is just another "place text" command. In the top window, the text would be coming from the MAIL utility of the source system. The bottom window would be getting the interrmittent lines of discussion from the CHAT I was involved in.

If I decided that I wanted to get a new program from one of the listings areas, I might open a third window to do this, overlapping my mail message as I write it. Again, we'd get a new "split windows" command, and some coordinates for the placement of this window.

I could search the library and find the program I am looking for, and then download it. Since the download is typically a non-interactive process, I might close the window. If the download became riddled with errors, another window might open to tell me about the problems the system was having with my file. Otherwise, I would continue to work on my letter, occassionally popping back down to the exchange with XYZ Software to put my two-cents in about their product. While I'm not "looking" at the other two windows, they're still updating because my system is still receiving packets with their <Tag>'s. If someone in the CHAT made a particularly neat point, for example, I might drag my mouse down there or poke a hot key to get there and add my two cents. When I was done, I could move again to the window where I was.

This way, the outgoing data would be tagged as coming *from* a particular window, as well. Maybe the <CommandCode> would be "say something". The <tag> would be the number of the window where I typed what I said, and the <Data> would be simply what I typed.

Should I decide to move around windows, the sending system would be notified. It could then reformat text that was coming my way, or perhaps use a slightly modified format for sending listings. For example, if it knew that my database-searching window was only thirty-six columns wide, it might not give the "Comments" field of each record it listed. If I did have a wider window, however, the "Comments" field might be sent to me.

Though some might argue it would be possible that such activity could bog down the system and not really generate any stronger throughput, I think that the typical user would strongly benefit from such a situation. How much data do you actually send and receive in an interactive CHAT? Most of the time is spent waiting for the other person, or other members, to send their replies. That "dead air" time could be used to send me my file. I could send back, perhaps as a complete packet in itself, a copy of my letter. Certainly, the time I spent looking around in the database would be mostly waiting around for the system to answer my request for information.

We've covered the three very common uses for computer-based communications systems. The first is the exchange of binary files, from user-to-user or in user-to-public, such as found in SIGs or Forums or Users Groups. The next is one-on-one or one-on-group chatting, such as found in CompuServe's famous CB Simulator or in The SOURCE's CHAT product. The third is the interrogation of databases; searching for news stories, looking for a bibliography reference, or finding a precedent for a legal matter, perhaps.

These three activities could easily be compressed into a packeted interface, and the windowing presentation layer for the PC user would be easy to develop and simple to implement, as I've described above.

I believe that the two biggest problems involve the implementation of such a service from the host's end. First, there would be no way to accurately bill someone. It would not be very fair to charge a user with only a single window and process the same rate as someone who is enjoying a CHAT, downloading a file, compiling their waiting notes, and jotting down a note all at the same time. I suppose that billing could be done on a per-window, per-service basis. A higher rate would apply for the first window, but ever other window would be much less.

The other would be to find someone to implement such an innovative protocol. Such an item would no doubt bring on a great deal of interest, but a substantial amount of time would be spent developing the system for each microcomputer, as well as for the host.

Who's going to take the ball? And, better yet, when?

I would love to have your feedback on these ideas; please feel free to write or call.

------
Author's note: You can reach Mike at: Mike Blaszczak, 35
Ginger Lane #229, East Hartford, Connecitcut 06118
The fine print: CompuServe is a H and R Block Company. "The CB
Simulator" is a servicemark of CompuServe. UNIX is a registered
trademark of American Telephone and Telegraph. The SOURCE is a
registered service mark. CHAT is a servicemark held by The
SOURCE. BIX and CoSy are registered trademarks of McGraw-Hill,
Incorporated. Participate is a registered trademark of NETI.
MS-DOS is a registered trademark of Microsoft. PS/2 and OS/2 are
registered trademarks of IBM. 80286 and 80386 are registered
trademarks of Intel. VAX, VT-series and VT-100, and PDP are
trademarks of Digital Equipment Corp. Prime and Pr1me are
trademarks of Prime Computer.