tr0nix
der-mit-dem-tux-tanzt
Hallo zusammen
Ich habe einen Projektauftrag in der Schule gekriegt, einen Com-Port Server zu realisieren. Das heisst, dass der Client den COM-Port auf einer fremden Maschine anspricht. Das ganze ist natürlich "virtuell", also es muss sich auf der Clientseite ein Treiber (o.ä.) registrieren, damit Programme wie üblich einen COM-Port sehen, welcher im Hintergrund jedoch über TCP/IP auf einen Server verbunden ist.
Da unter Unix ja jedes Gerät ein File ist, und sich dieses in sehr vielen Anwendungen definieren lässt, kam mir die Idee, das entsprechende Devicefile (in meinem Projekt wäre es /dev/ttySx) transparent einem anderen System verfügbar zu machen.
Experimente:
NFS export von /dev, mount auf Clientseite
Ja, ist gebastelt, ist unschön, ist Sicherheitsrisiko (etc. pp.) aber hat eh nicht funktioniert . Wär die easymode Lösung gewesen. Gab Probleme beim Zugriff, der Export liess sich zwar mounten, aber ich konnte nicht auf die Files darin zugreifen. Idee verworfen.
Selbstgeschriebenes Tool
Jetzt wirds schon interessanter. Ich hab ein Tool geschrieben in Perl, bei welchem ein FIFO-File auf dem Client mit dem Devicefile auf dem Server verbunden wird.
Clienttool schreibt in FIFO-File wie in ein Devicefile -> Daemon nimmt Message und sendet sie an Server -> Server schreibt Message in Device
Das ganze natürlich bidirektional (falls Device antwortet) und asynchron. Es scheint seinen Dienst eigentlich korrekt zu machen, aber mein Testprogramm mpg123 verweigert (noch) den Dienst mit einer EINVAL-Meldung (musste truss'en).
Ich hab euch die 2 Perlscripts mal angehängt, wer Lust hat soll es ausprobieren! Die Scripts sind Quick & Dirty aber erledigen ihren Dienst. Ich übernehme keine Garantie wenn jemand Devices damit schleisst , sollte eigentlich aber auch nicht passieren.
BTW. der erste der es schafft so die Festplatte versehentlich zu formatieren kriegt n'Bier
//Edit: scheinbar verweigert so ziemlich jedes Tool die Zusammenarbeit mit dem FIFO . Naja, schöner Versuch wars trotzdem .
Ich habe einen Projektauftrag in der Schule gekriegt, einen Com-Port Server zu realisieren. Das heisst, dass der Client den COM-Port auf einer fremden Maschine anspricht. Das ganze ist natürlich "virtuell", also es muss sich auf der Clientseite ein Treiber (o.ä.) registrieren, damit Programme wie üblich einen COM-Port sehen, welcher im Hintergrund jedoch über TCP/IP auf einen Server verbunden ist.
Da unter Unix ja jedes Gerät ein File ist, und sich dieses in sehr vielen Anwendungen definieren lässt, kam mir die Idee, das entsprechende Devicefile (in meinem Projekt wäre es /dev/ttySx) transparent einem anderen System verfügbar zu machen.
Experimente:
NFS export von /dev, mount auf Clientseite
Ja, ist gebastelt, ist unschön, ist Sicherheitsrisiko (etc. pp.) aber hat eh nicht funktioniert . Wär die easymode Lösung gewesen. Gab Probleme beim Zugriff, der Export liess sich zwar mounten, aber ich konnte nicht auf die Files darin zugreifen. Idee verworfen.
Selbstgeschriebenes Tool
Jetzt wirds schon interessanter. Ich hab ein Tool geschrieben in Perl, bei welchem ein FIFO-File auf dem Client mit dem Devicefile auf dem Server verbunden wird.
Clienttool schreibt in FIFO-File wie in ein Devicefile -> Daemon nimmt Message und sendet sie an Server -> Server schreibt Message in Device
Das ganze natürlich bidirektional (falls Device antwortet) und asynchron. Es scheint seinen Dienst eigentlich korrekt zu machen, aber mein Testprogramm mpg123 verweigert (noch) den Dienst mit einer EINVAL-Meldung (musste truss'en).
Ich hab euch die 2 Perlscripts mal angehängt, wer Lust hat soll es ausprobieren! Die Scripts sind Quick & Dirty aber erledigen ihren Dienst. Ich übernehme keine Garantie wenn jemand Devices damit schleisst , sollte eigentlich aber auch nicht passieren.
BTW. der erste der es schafft so die Festplatte versehentlich zu formatieren kriegt n'Bier
//Edit: scheinbar verweigert so ziemlich jedes Tool die Zusammenarbeit mit dem FIFO . Naja, schöner Versuch wars trotzdem .
Anhänge
Zuletzt bearbeitet: