| |
SM0ORB > PSBBS 01.07.96 15:33l 118 Lines 5259 Bytes #-10327 (0) @ WW
BID : 7855_SK0MK
Read: GUEST
Subj: Re: Public Source BBS
Path: DB0AAB<DB0FSG<DB0IGL<DB0KCP<DB0ZKA<DB0LX<DB0RBS<DB0SEL<DB0ZDF<DB0AIS<
DB0SIF<DB0NHM<DB0SAW<DB0HRO<OZ4BOX<OZ3BOS<OZ7PAC<OZ3BUL<OZ3BOD<SK6FV<
SK6YW<SK6BA<SK6LK<SM7FEJ<SM7TYU<SK7AF<SM5SUH<SK5AS<SK5BN<SK5UM<SK0MK
Sent: 960630/2230Z @:SK0MK.TELGE.AB.SWE.EU #:7855 [JO89TE] $:7855_SK0MK
From: SM0ORB@SK0MK.TELGE.AB.SWE.EU
To : PSBBS@WW
SQ6BOT (commenting me)
:> 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 ;-)
Well, i don't think they have to be so many. If most of the parts that
are operating system or machine dependant is placed in their own code
block and we allow some duplicate code in those parts then it can still
be reasonably clean. Remember i wrote "port" not "recompile".
: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...
Yes for DOS it would be quite a lot to write. I was more thinking about
OS/2, Win95 and Linux environments. There it would be more like writing
some drivers for radio access and some interface functions to existing
TCP/IP code.
:> - 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).
Also required if we shall have support for all TNC's, Kantronics host
mode is not compatible with WA8DED :-(
I have a HAM friend here who has actually written AX.25 interpreter
already, think we can borrow code from him ? Actually i will try
to persuade him to join, he's a good programmer.
:> 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^)_)
It was easy to get me to install it, guess i'm not "typical" :-) ^
!
Whats that supposed to be ???? -----------------------------------!
:> Please... No config.h
:Hm, we can try. Or distribute whole program in several versions - with
:different options compiled in.
Yes thats one solution, although not the best.
The ideal would be that each function is controlled by a text config file
that is read on startup. For a KISS TNC it is nessesary with information
to the driver what fysical port that is used, for the rest of the system
that this is a device to send data to, and for the connection manager to
know he has to monitor this device for connects. The program part registers
with the scheduler to get CPU time and thereby get an identifier so other
program parts can identify it. This way only a few basic parts need to
be in a system, the rest is optional.
: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)
Figures :-) I saw it already in your previus writings.
This far it seams like you got things the right way so keep on.
: 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).
This looks good for incoming data, but i think you would need two processes
for the TNC, one for receive and one for send. Otherwise there may be
problems with timing, or shall we call it channel capacity sharing, when
there are several users requesting different type of data and having
difficulties hearing each other. In such a case the BBS needs a little
more adjusting capabilities, for example, don't ack user1 until user2 has
sent an ack to my data.
Also i think two processes for each user may give easier code in each of the
processes. Don't be afraid to split up code, it sounds more but are
generally easier.
: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 ;-)))
Haven't seen it yet, hope it makes the it up here.
One interface per night! By you! What will be left for the rest of us ? :-)
A little background on myself since i make all theese suggestions:
I have been working with telephone exchanges for 15 years, programming,
testing, searching for faults and also some system designing.
Now most of the time is used for other things than programming so i'm a
bit rusty on the code lines. By the way, if i write some code piece and
you can't get it right with the syntax then maybe i've mixed up some
languages ;-)
/Anders
Read previous mail | Read next mail
| |
