| |
SQ6BOT > PSBBS 01.07.96 13:46l 137 Lines 6073 Bytes #-10328 (0) @ WW
BID : T66SR6BOX002
Read: DO3SMK GUEST
Subj: Re: Public Source BBS
Path: DB0AAB<DB0MFG<OE7XCI<OE7XKJ<DB0PV<DB0ISW<OE7XBB<OE8XPK<OE6XHG<OE3XBS<
OE1XIB<OE1XBB<OE1XAB<OE3XZR<OK0PBX<SP6KBL<SR6BOX
Sent: 960629/1804z @:SR6BOX.#WRO.POL.EU [BayCom-Mailbox [Wroclaw]] BCM1.37b
From: SQ6BOT @ SR6BOX.#WRO.POL.EU (Zipu)
To : PSBBS @ WW
SM0ORB wrote:
> But please let's make the code in such a way so it is easy to port
> to unix and possibly other types of computers. Let's not forget that
> the PowerPC chips have come. With some care in coding it should be
> possible to make an easily portable program.
There will be a lot of #ifdef & #ifndef UNIX ;-)
> Preferably not too much like FBB.
> I think you are right on separate channels for "local login" and
> "management". I even would like the local login channel to go through
> a virtual COM port so that it "really" is the same as for the users.
There can be 'loopback' interface...
> What about a BBS working with both TCP/IP and AX.25 ?
> Mail coming from TCP/IP users/BBS's enters the AX.25 net at this point,
> the TCP/IP station putting it in gets an R:-line identifying it as a
> subordinate BBS.
> Mail from the BBS net sent to a TCP/IP station gets a RFC style header
> entry.
> That way the originating system can always be identified as subordinate
> to the own BBS and return mail is hopefully correctly routed.
Hm, there would be a bit code to write to support TCP/IP. But everything
is possible. I don't like the way JNOS routes messages from and to
AX.25 net...
> :BBS should work as a TSR - to allow other (ex. node) programs. And should
> :use as much EMS memory, as it is possible.
> Hmmm.......
> I don't think that will work other than on a very small BBS. Consider
> disk operation together with communication, thats hard to do.
> One more point is that using EMS is not easy, all kind of memory
> swapping with a TSR program must be considered very dangerous.
I gave up idea of TSR. If someone wants to have a node, he should buy
next PC and not slow down the BBS (but we can build node into BBS!)
> I think it will be easier to make it a program wich runs under OS/2
> then you have better memory management and can use built in functions
> for multitasking. Note that all BBS programs for DOS have their own
> multitasking kernel built in. This includes node software. And running
> several program with multitasking kernels on one machine works poorly,
> they tend to lock things up for each other.
> Agree with the following additions:
> - KISS mode support
It requires writing whole ax.25 like level... ;(
But it's necessary, because with hostmode TNC BBS would be able to
support 8 or 16 users (as many as TNC software supports).
> :Rolf again (commenting Peter)
> :>We also have to discuss way of storing messages on the disk to not make
> :>searching too slow.
> :Hashing table maybe?
> Maybe a part to have replaceable ?
> I think that on OS/2 systems ordinary file access would do fine, the
> disk access is really great as compared to DOS or Windows.
Try to persuade to a typical sysop ;-) to install OS/2 or Linux >8^)_)
> Please... No config.h
> It's better to specify very clear interfaces to each part of the program
> and have options in a config file to shut parts down or even replace
> the code with code in another file. We do not need to build the program
> as one big chunk of code in one file, the code could be separetad into
> several files where each file holds one specific function. If anyone
> wants to change a part he/she makes a replacement for one of the
> files, or just adds another file. The user (sysop) should not have
> to recompile the program to configure it.
Hm, we can try. Or distribute whole program in several versions - with
different options compiled in.
> But put your compilers a bit aside for a few days and let's discuss the
> structure a bit. I know it's hard to keep the fingers away from code
> generating but if there is no structure to start with there could be
> serius problems a little later on.
>
> I suggest a basic structure like this:
> - BBS kernel : handles the databases and operations on mails
> - Disk interface : handles all disk operations
> - User interface : handles command interpretation
> - Console I/O : handles the screen, keyboard and mouse
> - Radio interface : handles TNC's, connects, timings, protocols
> - Multitasking kernel : distributes CPU time to all other parts
>
> A user reading a mail would be handled as this:
> 1. The Radio interface receives connect and initiates a new user stream
> in the User interface.
> 2. The User interface receives a read command and sends a read request
> to the BBS kernel
> 3. The BBS kernel contacts the Disk interface to open the mail file
> and sends the data back to the User interface
> 4. The User interface sends the mail to the Radio interface with paging
> according to the users settings
> 5. The Radio interface transmit the message with time sharing according
> to the load on the channel
I just began to write code (I was unable to resist the temptation.... ;-)))
and it looks as follows:
One multitasking kernel (it's a bit buggy, but works somehow):
One process - parsing keyboard input.
Attaching a TNC of TFPCX or any else interface (from config file or
by sysop on-line) creates another process: TNC_poll (or TFPCX_poll)
that polls TNC to check if some data is available.
(one process for each interface)
And plan for nearest future:
When TNC polling process detects an incoming connection, then it creates
another process ('user_in_BBS') and passes to him all data incoming
on this channel. This process interpretes incoming data and executes
user's commands (it doesn't require to fork another processes - one
for one user it's enough - anyway we can add some commands, that would
be available for user to run in the background).
> Now you have a lot to comment :-)
Done. ;)
I didn't want to send sources in this early stage to @WW, but I'll do it
anyway. Take a look at them and tell me what can be added or corrected
(especially in multitasking kernel - I have some problems with memory
allocation... And signals have to be added soon...).
I'll try to write loopback interface tonight ;-)))
73, Peter
Read previous mail | Read next mail
| |
