Soundlan
Aus Chaostreff Aargau
Inhaltsverzeichnis |
Projektbeschrieb
Dieses Projekt entstammt der Ideenwelt Andreas'.
Es wird ab dem 25.11.2005 aktiv verfolgt.
Folgendes soll erreicht werden:
Über Signale, die von einer Soundkarte einer Sender-Maschine A ausgehen (über Boxen/Kopfhörer, Sound Out (Maschine A)->Sound In (Maschine B)) sollen Datentransfers erfolgen.
Die Empfänger-Maschine B erhält diese Daten, wie suggeriert, über Sound In, entweder direkt über Kabel oder über Mikrofon.
Diese Tonsignale sollen von der Maschine B demoduliert werden, interpretiert als TCP/IP-Pakete; je nach verwendetem Frequenzbereich und Messensfeinheit der Wellen sind zumindest Transfers im zweistelligen KBit-Bereich denkbar (mit max 20kHz sollten so 10 kbit erreichbar sein).
Funktionieren soll der Spass auf allen verwendeten Plattformen, soweit GNU/Linux und NetBSD.
Virtuelle Netzwerkgeräte werden dafür geschafft, dass ein gewöhnliches TCP/IP-Netzwerk aufgebaut wird, welches sich musikalisch manifestiert ;).
Entscheidungen (vom 25.11.2005)
- FSK (Frequency Shift Keying) wird verwendet
- Entwicklungsplattformen: GNU/Linux, NetBSD (soweit)
- Zu verwendender Frequenzbereich: ~2khz
- Programmiersprache: C
- Verwendung von Threads und Sockets oder memory mapping
- Verwendung von tun/tap (virtuelle Netzwerkgeräte)
- Einrichtung CVS Repos
Todo
Anfänge
- Einchecken ersten, konzeptionellen Codes (noch ohne TCP/IP-Unterstützung)
- POSIX-/UN*X-Interoperabilität sicherstellen
TCP/IP verwenden
Wenn einmal die Datenübertagung einzelner Bits und Bytes klappt, wäre es schön, ein IP Interface zu haben, so dass man TCP und UDP Pakete verschicken kann.
- Vorschlag: Verwendung des TUN/TAP Treibers
- Vorteile
- wir müssen nichts am Kernel programmieren (was neben unvermeidlichen, massenhaften Abstürzen vermutlich auch zur Folge hätte, dass wir nicht mehr gleichzeitig Linux und *BSD unterstützen könnten)
- wohl deutlich einfachere Implementierung als mit einem Kernelmodul
- wir können sowohl Pakete auf IP Level (TUN), wie auch auf Ethernet Level (TAP) versenden
- Interface kann normal mit ifconfig konfiguriert werden
- Nachteile
- scheint relativ alt zu sein - gibt es was neueres?
- Vorteile
Datenrate maximieren, Fehleranfälligkeit minimieren
- ggf. verschiedne Modulationsarten testen
- Frequenzabstand (falls FSK verwendet wird) optimieren
- natürlich könnte man auch Richtmikrofone verwenden, aber das ist wohl eher zu teuer
- die Reichweite kann wohl einfach durch grössere Lautstärke erhöht werden - nicht sehr interessant..
Daten in Soundstreams verstecken
Falls alles soweit klappt, wäre es auch schön, die Daten in Musik zu verstecken, und so unaffällig zu übertragen (Steganographie)
Verschlüsselung
Und falls wir dann noch Zeit haben, könnten natürlich die Daten auch noch verschlüsselt werden
Ursprünglich hätten eigentlich die optionalen Schritte markiert werden sollen, aber es zeigt sich, dass alle Schritte optional sind und das Endprodukt auch mit vorhandenen Binaries zusammengebastelt werden könnte (Schritte 1-3 mit Amateurfunkprogrammen oder Morseprogrammen wie CW, Schritt 4 mit netcat (was allerdings nur einen Port als Zugangspunkt zur Folge hatte, statt einem IP oder Ethernetendpunkt, 2-3 Ebenen tiefer), Schritt 5 wäre dann Parameteroptimierung, Schritt 6 könnte mit sox bewerkstelligt werden und Schritt 7 mit cryptcat oder stunnel o.ä. - interessant übrigens, dass man mit den ziemlich gleichen tools auch progs wie skype ersetzen könnte). Allerdings geht es ja auch irgendwie darum, ein wenig zu coden und etwas dabei zu lernen, also sollten wir wohl möglichst auf die Verwendung von vorhandenen Binaries verzichten.
Falls wir modular und sauber programmieren, sollten die einzelnen Teile auch später austauschbar sein. Schön wäre zudem die Verwendung von CVS und Doxygen.
