Finished internal protocols

This commit is contained in:
Michiel Broek
2004-11-28 15:19:26 +00:00
parent ac2c34c9d5
commit 70792652c8
4 changed files with 511 additions and 336 deletions

Binary file not shown.

Before

Width:  |  Height:  |  Size: 5.6 KiB

After

Width:  |  Height:  |  Size: 12 KiB

View File

@@ -14,22 +14,37 @@
</HEAD>
<BODY>
<BLOCKQUOTE>
<div align='right'><h5>Last update 15-Jun-2002</h5></div>
<div align='center'><H1>MBSE BBS Setup - BBS Setup - Transfer Protocols.</H1></div>
<div align='right'><h5>Last update 28-Nov-2004</h5></div>
<div align='center'><H1>MBSE BBS Setup - BBS Setup - File Transfer Protocols.</H1></div>
<H3>Introduction.</H3>
<p>
It might look strange that you have to define transfer protocols for the bbs
while for the mailer you don't need to do that. This is historic, ifcico
already had internal protocols and the precessor of the bbs package had external
protocols. Because my priority was make the bbs working it still is that way.
When time comes I will build some of the protocols internal, adding external
protocols will allways be possible.
MBSE BBS has Xmodem, Ymodem, Ymodem-1K, Ymodem-G, Zmodem and Zmodem-8K (aka
ZedZap) build in. In addition some external protocols are added to the setup but
they are disabled by default. When the bbs is started the first time, a set of
default protocols is created. The code used is based on the code from lrzsz
package wich is based in the original code written by Chuck Forsberg.
<p>
When you configured the sources and build mbse, the configure script searched
for excisting transfer protocols. When mbsetup was run the first time, when mbtask was
started, the protocols found on your system are already configured with the
right paths and enabled.
Ymodem is receiver driven. That means if the user has selected plain Ymodem at
the bbs and
his local client is using Ymodem-G and when the user starts a download, the files are
sent with Ymodem-G and not with plain Ymodem. With the same configuation an
upload will be sent with plain Ymodem. With downloads, the Ymodem at the bbs
will use what the client wants: 128 or 1K data blocks, crc of checksum, normal or
streaming Ymodem-G.
<p>
Zmodem is transmitter driven. That means if the user has selected Zmodem-8K at
the bbs and his local client is using normal Zmodem and when the user starts a
download, the download is sent with Zmodem-8K. With the same configuration an
upload will be sent with plain Zmodem. With uploads, the Zmodem at the bbs
doesn't care what is being used, it will adapt to the client program.
<p>
These days (2004) nobody should use Xmodem anymore but when I wrote Ymodem you
also get Xmodem because they are the same. Only with Xmodem the user has to
type in the filename to both sides. If you enable it you are on your own and you
may need to change the sources to make it really work because I didn't add
typing in the filename at the bbs. Also, Xmodem is restricted to 8.3 filenames
and the bbs uses long filenames.
<P>&nbsp;<p>
<H3>Transfer Protocols Setup.</H3>
@@ -40,13 +55,14 @@ right paths and enabled.
<strong>Upload </strong>The full path and filename and parameters to upload files.
<strong>Download </strong>The full path and filename and parameters to download files.
<strong>Available </strong>If this protocol is available.
<strong>Batching </strong>If this is a batching protocol.
<strong>Bi direct </strong>If this is a bi-directional protocol (Not supported yet).
<strong>Internal </strong>If this is internal or external protocol.
<strong>Advice </strong>A small advice to the user shown before the transfer starts.
<strong>Efficiency </strong>The efficiency in percent. Has no real meaning.
<strong>Deleted </strong>If this protocol must be deleted.
<strong>Sec. level </strong>The security level a user must have to select this protocol.
</pre>
Some fields cannot be changed when this is an internal protocol, they are
hardcoded.
<P>
<IMG SRC="../images/protocol.png" alt='File transfer protocols'>
<P>