Waybackwhen, I wrote this proposal for a very simple BBS networking protocol. There were several in existence, but the specs were always complicated. I wanted something someone could implement without a Phd ;-)
The following is a proposal for a new CoCo BBS message networking protocol created by Allen Huffman at Sub-Etha Software. This protocol was designed to easily allow the CoCo community to link BBSs together for mass communication within this network.
Background:
Several successful BBS networking protocols are already in existence such as FidoNet and WWIVNet. Although very powerful, these systems require large amounts of disk space to operate and have so far been limited only to systems with hard drives.
Introducing the Sub-Etha Net:
The proposed “Sub-Etha Net”, henceforth known as SENet, will be a low-hardware CoCo specific network designed for the sole purpose of linking the online CoCo community together with one massive public message base.
At this time, no private messages between systems will be supported. This will greatly limit the amount of overhead required by each system. Current protocols have required each system within the net to store a “net list” containing information on ALL systems within the network. SENet will not require such a list and no “hub” systems are needed.
How it Will Work:
In order to link with the network, the Sysop will simply insert the phone number of the system it wishes to net with and configure a few settings which control when and what it will transfer. The system you plan to net with will also add your number to its listing. Once this has been done, no further configuration will be required. A simple message pointer flag stored for each system is all that is required to keep track of messages.
An Example: System A will call System B and transfer messages.
At the specified time, System A dials a number stored in it’s net list.
Upon connection, System A waits for a prompt (such as “Press Return:”) then sends an escape code and it’s phone number (in the form ###-###-####) to System B.
System B will look up that number in it’s net list and either ACKnowledge or request the number to be resent (in case of line noise).
If several unsuccessful attempts are made, System B will disconnect. (If this was caused by line noise, this forces System A to redial and try for a better connection.)
After a successful connection, System A sends a four byte number stored in it’s net list which instructs System B to send all messages it has from that number on.
System B then sends messages (with appropriate error checking).
System A will ACKnowledge the transfer (or request data to be resent).
Depending on System B’s configuration, System B will either send a final ACKnowledgement and disconnect, OR it will send it’s four byte number for a message request.
System A then sends messages (with appropriate error checking).
System B will ACKnowledge the transfer (or request data to be resent).
System A will send a final ACKnowledgemend and disconnect.
Message base structure:
To keep things a simple as possible, the message base will contain only the following information…
- From: Name of poster (30 characters)
- Subj: Message subject (40 characters)
- Date: Date/time posted (6 character packet)
This allows the message “header” to fit in one 80 column line of information. Any other information such as “To:” or “Reply to:” will be contained in the actual message text portion of the file. This allows excellent flexibility for future expansion.
I wonder what else I will find in my archives. I still think something like this was a good idea — low overhead, simple to implement even in BASIC (though requiring an assembly language remote terminal driver), and “just enough to get the basic stuff done.”
Maybe one day we’ll do something like that using a CoCo and a $10 WiFi Modem for it ;-)
Until then…