wir bauen grad an einem Banktransfer-IP-Tunnel

unsere idee ist es eine TCP-IP-Verbinung über Banküberweisungen von 0.01DM zu
fahren. Die durchschnittliche Latency von 4 Tagen stört uns jetzt mal ned

Also, die Datei wird in ein Format encoded in dem sie nur 7-bittige Zeichen 
hat und keine Groß/kleinschreibung da sie nur so banktransfer-kompatibel ist

eine standard-überweisung kann 2x27 zeichen verwendungszweck enthalten, eine
erweiterte 8x30(?), wir gehen von standard aus

grob gerechnet wird der datenstream etwa doppelt so groß wie die Rohdatei, wir
gehen mal von einer Rohdatei von 10MB aus, also 20MB nach dem encoden

Ein Paket kann 54 Zeichen enthalten, wir nehmen 4 für die Blockkennzeichnung
an, damit ergibt sich 50 Zeichen encoded Data pro Überweisung, nach der
Blockkennzeichnung kann der Empfänger die Überweisungen wieder zusammensetzen

um die 10MB Rohdaten zu überweisen werden also 200000 Überweisungen benötigt
was 2000DM kostet.

Um Überziehungszinsen zu vermeiden und um den Datenfluss zu kontrollieren 
schickt der Empfänger immer nach 2500 Überweisungen, also 25DM eine
Rücküberweisund mit einer CRC-Prüfsumme der empfangenen Daten in einer
25DM-Überweisung, um die Konten wieder auszugleichen. Falls hierbei ein Fehler
festgestellt wird müssen die letzten 2500 Überweisungen eben wiederholt werden.

Dies alles geschieht so oft bis die gesamte Datei überwiesen ist.

Dieses Verfahren sollte natürlich nur bei Überweisungsgebührenfreien Girokonten
(zb. bei Jugendlichen, Studenten) zum Einsatz kommen, bei gebührenpflichtigen
Konten sollte ehr auf IP-over-SMS umgestellt werden, was auch mobile
Übertragung ermöglicht.

Die Idee zu diesem Verfahren steckt natürlich noch in den Kinderschuhen aber
schon bald wird auf den Überweisungskanälen unserer Banken vielleicht schon
eine Tauschbörse entstanden sein :)

Auch Terminerinnerungen über Daueraufträge etc. sind geplant

------------------------------------------------------------------------------
(C) 2001 SQUelcher