| |
DG1BBQ > DPTNT 07.01.99 12:38l 177 Lines 7474 Bytes #999 (999) @ DL
BID : F56NNWDB0VER
Read: GUEST
Subj: BS v2.00c Info
Path: DB0MAK<DB0ERF<DB0SHG<DB0FD<DB0VER
Sent: 990107/0929z @:DB0VER.#NDS.DEU.EU [Verden-Walle] DP5.07 $:F56NNWDB0VER
From: DG1BBQ @ DB0VER.#NDS.DEU.EU (Axel)
To: DPTNT @ DL
Hallo Leute,
da der Store&Forward vielerortens Beschränkungen unterliegt, ist es nicht
immer möglich, eine lange Datei in einem Stück einzuspielen. Grund dafür
ist beispielsweise, dass einige Boxsysteme (Baycom-Box, DieBox) noch keine
Wiederaufnahme bei Verbindungsabbruch (Resume) im Store & Forward beherrschen.
Bei einem Abbruch muss die Datei immer wieder ganz von Vorn übertragen werden,
was ganze S&F-Verbindungen zum Erliegen bringen kann. In kleineren Portionen
ist die Wahrscheinlichkeit grösser, dass die Files die Hürde Resume-Krüppel-
Boxen nehmen.
BS (BinSplit) wurde geschaffen, um lange Files in kleinere Stücke aufzuteilen.
Desweiteren ist es mit BS nun möglich, aufgeteilte BIN-Files in einem Rutsch
einzuspielen.
Dabei ist wie folgt vorzugehen (Beispiel):
Das einzuspielende File (z.B. TEST.EXE) binsplitten (ca. 30000 Bytes pro Teil),
mit Send-Befehl und BIN-Headern versehen und in ein gemeinsames File schreiben:
BS TEST.EXE -30000 -u -s "s software @dl #0"
- Erwartet die Box den Befehl und den Titel auf getrennten Zeilen, so ist
-s2 statt -s anzugeben!
- Wird eine BS-Version benutzt, die Langnamen unterstützt, empfiehlt es sich
dringend die -w Option mitanzugeben, wenn unklar ist, ob die Zielstation
mit langen Filenamen klarkommt! Das bedeutet aber nicht, dass dadurch die
Langnamen verloren gehen. Lediglich die Einzelteile und/oder das Uploadfile
erhalten 8.3-Namen. Werden so erzeugte Files wieder zusammengesetzt, wird
der Langname wiederhergestellt, wenn dabei eine Langnamenversion benutzt
wird.
Das resultierende TEST.UPL kann dann in einem Rutsch in die Box eingespielt
werden. In der Zeit kann man dann Däumchen drehen.
Es (!)MUSS(!) aber rein binär (also ohne BIN/BOXBIN/AUTOBIN-'Protokoll')
eingespielt werden, denn die #BIN#-Header sind im File ja schon enthalten.
Würde man MIT BIN/BOXBIN/AUTOBIN-Protokoll einspielen, ergäbe das nicht je
eine Nachricht pro Teil, sondern eine einzige sehr grosse Nachricht!
Leider verfügen noch nicht alle Terminalprogramme über die Möglichkeit des
rein binären Uploads (z.B. WinGT), aber das wird evtl noch(?).
Mit SP geht das rein binäre Uploaden z.B. mit ESC DB Filename.
Mit BayCom v1.6 geht es mit :RPRG, wenn vorher :AUTOBIN ausgeschaltet wurde.
Bei GP das Icon "Filetransfer" anklicken, und "Binärdatei" wählen.
Ein Warnhinweis noch:
Leider sind nicht alle Boxen in der Lage, BIN-Files, die derart eingespielt
werden, korrekt zu verarbeiten. Dies liegt an den Unzulänglichkeiten der
Kommandointerpreter, die es nicht verknusen, wenn ohne Beachtung der Frame-
grenzen eingespielt wird. Dies ist die Gelegenheit für die Boxpfleger, endlich
was dran zu tun ;->
Bei älteren DieBoxen vor Version 1.9b6 bitte nach althergebrachter Art
(BS-Optionen -b, -u und -s nicht verwenden) Stück für Stück per Hand
einspielen.
Sowohl die BayCom-, DieBox (ab 1.9b6), als auch die DP-Box kommen mit Uploads,
die wie oben hergestellt wurden, tadellos klar.
(Kommentar: Leider leider hat die DP-Box die Unart, persönliche Mails, die
BIN-Files enthalten, beim Forward nach FBB-Boxen in 7PLUS-Files zu wandeln.
Das kann zu Verwicklungen bezgl. der Filenamen führen! Besser wäre es,
wenn innerhalb DLs um FBB herumgeroutet würde, oder die wenigen FBB-Boxen
nur mit einem S&F-Partner zum DL-Netz hin S&F machen würden. Dann wäre auch
das für Sysops so erbauliche Problem verfälschter Lifetimes vom Tisch.)
FBB-Boxen können BIN-Files zwar im Fileserver verarbeiten, jedoch nicht in-
nerhalb von Mails! Dort ist BS tabu, bis F6FBB das endlich einbaut.
Ein Vorteil bei der Verwendung von BIN-Files ist, dass es nicht zu ERRs und
CORs kommen kann. Die Prüfsummen der Files werden von den einzelnen Boxen
beim Store&Forward überprüft, weshalb die Files mit allergrösster Wahr-
scheinlichkeit heil ankommen (abgesehen von Fehlern, die im Filesystem
der Box entstehen können und Resynchs bei Hostmodeterminalprogrammen).
Ebenfalls zu erwähnen ist der sehr geringe Overhead von BS, der dadurch
zustandekommt, dass nicht kodiert wird, sondern nur aufgeteilt wird!
Ich hätte BS schon vor einigen Jahren entsprechend erneuert, allerdings war
es bei den damaligen Boxversionen noch nicht möglich, BIN-Files gesammelt
einzuspielen. Das Ganze war damals einfach zu umständlich. Jetzt nicht mehr.
Die Optionen von BS sind möglichst simpel gehalten, weshalb ich auch auf eine
reguläre Anleitung verzichte. Eine History-Datei führe ich auch nicht für BS.
:-)
Eine Übersicht der Optionen erhält man durch Aufruf von BS ohne Parameter.
NEU in Version 2.00
===================
Es gab Kritik, dass die in BS verwendete 16Bit-CRC zu unsicher sei.
In der Tat ist sie nicht mehr angemessen, da die Grössenbeschränkung für
BS-Teile entfallen ist. Je grösser die per CRC zu sichernde Datei, desto
wahrscheinlicher wird es, dass Fehler zu einer identischen CRC führen und
damit unerkannt bleiben.
Ich habe mich daher entschieden, ein völlig neues BS-Format zu entwickeln,
das mehrere 32Bit-CRCs verwendet (eine pro Teil + eine Gesamt-CRC) und
eine 16Bit-CRC für den Header (der ist kurz, daher reicht dafür die
'kleine' CRC). Im Gegensatz zum alten Format ist JEDES Byte gesichert,
so dass die Datensicherheit erheblich gewachsen sein dürfte (abgesehen von
Bugs natürlich :-)
Ebenso habe ich im neuen Format Vorkehrungen für Systemspezifische Er-
weiterungen getroffen.
Das neue Format ist leider absolut inkompatibel zum Alten und lässt sich
daher nur mit BS-Versionen ab 2.00 verarbeiten.
Das alte Format wird aus Kompatibilitätsgründen weiterhin unterstützt. Es
können Dateien des alten Formats sowohl erstellt als auch verarbeitet werden.
Beim Zusammenfügen erkennt BS selbsttätig, um welches Format es sich handelt.
Lediglich beim Splitten muss die -O Option angegeben werden, wenn das alte
Format erwünscht ist.
Die im BS-Header enthaltenen Informationen sind der besseren Kontrolle wegen
weitgehend im Klartext enthalten.
Desweiteren spricht BS jetzt per Default Deutsch. Wer's lieber Englisch hat,
der füge folgende Zeile 'set BS_G=ok' in seine AUTOEXEC.BAT ein.
Ich hoffe, es sind nicht zuviele Bug enthalten. Immerhin ist der Quelltext
um fast 50% grösser geworden.
v2.00a
======
Einige Zeilen Quelltext hatten sich unbemerkt verflüchtigt. Daher funktioniert
die -R Option bei der v2.00 nicht korrekt. Das ist mit dieser Version behoben.
v2.00b
======
Minimal-Bugfix (Fehler beim Setzen des Filedatums beim Zusammenfügen alter BS-
Files). Der Fix betrifft nicht die DOS- und die Win95/NT-Version.
v2.00c
======
Fix für Fileserver-Betrieb. Es kam vor, dass BS Files, die grade per Hand in
den Fileserver eingespielt wurden, gleich wieder killte, da sie scheinbar
unvollständig waren.
Einige User gaben bei Bereichsangaben die BS-Fileextension als Nummer an,
z.B. 'bsget file b05-b0a', was natürlich nicht klappen konnte. BS erkennt
nun diesen Fehler und korrigiert die Werte automatisch.
Fuer den Betrieb beim User bringt diese Version keinerlei Änderungen, weshalb
dort die Version 2.00a (beziehungsweise 2.00c beim Atari) aktuell bleibt.
Folgende Archive sind z.Zt. verfügbar:
BS200CSR.ZIP Quelltext (für Linux, Amiga etc...)
BS200AEI.ZIP DOS-Version von BS 2.00a
BS200AEN.ZIP 32Bit-Version von BS 2.00a. Unterstützt lange Filenamen.
BS200AEA.LHA Amiga-Version von BS 2.00a. Unterstützt lange Filenamen.
BS200BES.ZIP AtariST-Version von BS 2.00b
73s, Axel DG1BBQ @DB0VER.#NDS.DEU.EU
Read previous mail | Read next mail
| |
