| |
SQ6BOT > PSBBS 08.07.96 01:37l 82 Lines 4647 Bytes #-10317 (0) @ WW
BID : 776SR6BOX00F
Read: DL3MHT GUEST
Subj: Progress report
Path: DB0AAB<DB0PV<DB0WGS<OE3XSR<OE3XZR<OK0PBX<OK0PHL<SP6KBL<SR6BOX
Sent: 960707/2041z @:SR6BOX.#WRO.POL.EU [BayCom-Mailbox [Wroclaw]] BCM1.37b
From: SQ6BOT @ SR6BOX.#WRO.POL.EU (Zipu)
To : PSBBS @ WW
Dear fellows,
I will begin from the most recent problem - the KISS interface.
I wrote, that JNOS works with my TNC and loopback and doesn't cut frames.
I was wrong. JNOS cuts frames and TFPCX cuts frames. So, fortunately,
it's problem of TNC or loopback, but not the PSBBS (I hope so...).
You can attach KISS TNC by typing: attach kiss <interface name>
<i/o port> <irq number> <tnc-to-pc speed>. You can set KISS parameters
using: kissparam <parameter number> <value>.
PSBBS uses serial communication routines written by Stefan DL1ELY
(part of iface.c file and whole sio_intr.c and sio.h).
Second thing I wrote is AXIP link support - based on FTP Packet
Driver. I made it mainly for my own use - I have access to the radio port
only through AXIP link, so it's the only way for me to test the software.
There is no possibility of setting up IP addresses and only Ethernet type
packet driver is supported. I will add setting IP addresses soon. Packet
driver interface is taken from JNOS (files pktdrvr.c, pkvec.asm, pcgen.asm,
asmgloba.h).
To do on AX.25 layer: AX.25 window (!!!).
Now returning to Hank W0RLI's proposals. Making BBS as many
stand-alone portions is a good idea - especially for sysops. They would
be able to tune up BBS to meet their need without editing config.h file
and recompiling the whole.
There is probably no need to make our own protocol for communications
between drivers, as there are already some - tested and working. Additionaly
we would be able to use already written drivers. Unfortunately I know
completely NOTHING about such drivers and about protocol specifications.
Could anybody help me?
I think I will be able to write some standard SCC cards drivers,
but more important now is the BBS itself. Up till now I heard no advice
about the way of storing messages. So here are some of my thoughts:
Messagese cannot be stored in separate files - this eats too much disk
space. I was thinking about making some big files and each of them would
contain one board. But there will be a problem with deleting expired
messages - each board file must be copied to a new one after skipping
some old messages on the beginning. So in case with 200 MB of stored files
each midnight BBS will have to copy, for example, whole 199MB of data
deleting 1MB on the beginning. [1]
Second thought is making one big file that fills whole disk space.
Inside such file we have more flexibility. First possibility is making our
own file structure and store messages in our own way - for example with
"cluster" size of 512 bytes (our FAT-like structure would be very big,
besides that we would be able to store more messages).
Another possibility - much easier - is making inside such big file
a ring-buffer. In such case all messages would have _the same_ expiry time
and will be deleted just by moving 'begin-of-messages' pointer.
Just in this moment I got another idea - I think it's the best one!
Each board will have separate directory. In each of such directories
there will be something like described in point [1], but NOT AS ONE BIG
FILE, but lots of cluster-sized (ex. 16, 32 kB) files. All files joined
together would make the big file described in [1], but they wouldn't
be joined. While reading from such file-chain, when we get to the end
of one file, we just jump to the beginning of the next in the sequence,
so there will be no difference, what we use - one big file or file-chain.
And now the advantage: after message expiry we just delete files from
the beginning of the chain. And we move pointer from ex. file0000, byte 0
to file0039, byte 13285. We don't have to cut 13285 unused bytes in
file0039, because in wouldn't increase disk free space (remember cluster
size). So expiring would be fast, message searching too, there will be
also an index file (hmm, we can rewrite it each time we delete expired
messages), and no disk space would be lost! (almost). There will be a lot
of directory entries, although it wouldn't eat so much disk space (few
clusters for each board).
So what do you think now? Can I start making read/list/send
function using this disk storage scheme? Or it requires improving?
(maybe it's bad at all, but I cannot find what's wrong at the moment).
I'll send you sources update soon. Should I send exec also?
(BTW: it should be compiled using huge memory model).
I'm looking forward for your replies.
73,
Peter
Read previous mail | Read next mail
| |
