ubuntuusers.de

Socket tcp oder udp unter Shell-Programmierung überhaupt möglich?

Status: Gelöst | Ubuntu-Version: Ubuntu 10.04 (Lucid Lynx)
Antworten |

snafu1

Avatar von snafu1

Anmeldungsdatum:
5. September 2007

Beiträge: 2133

Wohnort: Gelsenkirchen

theinlein schrieb:

Dieses Shell-Script ruft sofort tclsh auf (die ersten 3 Zeilen, damit ist man unabhängig davon, wo tclsh installiert ist – aber: Bäcksläsch als letztes Zeichen am Zeilenende nicht vergessen).

Müsste das nicht theoretisch auch mit #!/usr/bin/env tclsh klappen?

mgolbs

(Themenstarter)

Anmeldungsdatum:
11. Januar 2009

Beiträge: 269

Wohnort: Tirschenreuth - Löbau

Hallo,

danke für die Tipps. Das tclsh Skript wie zuletzt gelistet funktioniert prima auf den Arms Psion Netbook PsionLX sowie auf Zaurus SL5500, nur beim Zaurus muss ich /usr/bin/tcl8.3 angeben. Ich schaffe damit aber nur etwa 410Hz (Psion), 525Hz (Zaurus) Abtastfrequenz der AD's gegnen 730Hz auf Ubuntu.

Die Frage eines reinen Shell Socket steht noch. Ich muss mal die Hinweise der vielen Meldungen unter i386/amd64 ausprobieren. Melde mich dann wieder. Wobei eine Lösung generell unter busybox für mich auch wichtig ist - dnp7520, 5280... http://www.dilnetpc.com/linuxcontrol/DNP7520HWR.pdf bzw. http://www.dilnetpc.com/dnp0038.htm, denn ob ich da überall tclsh finde/installieren kann ist eher fraglich.

Gruß und vielen Dank Markus

Vain

Avatar von Vain

Anmeldungsdatum:
12. April 2008

Beiträge: 2510

track schrieb:

Das Problem ist aber, dass der TCP-Dämon nicht läuft, und dem zufolge das Pseudogerät /dev/tcp/.... nicht existiert.

Falls du dich auf mein „/dev/tcp“-Geraffel oben beziehst: Das geht auch ohne tcpd. Um ehrlich zu sein, habe ich auch noch nie etwas mit dem Ding gemacht und weiß gar nicht, wie das da ablaufen würde. Das „/dev/tcp“, was ich meine, gibt es im Dateisystem nicht, und das funktioniert auch ausschließlich in der Bash. Die tut einfach so, als gäbe es das, und öffnet dann ein Socket.


mgolbs schrieb:

Wobei eine Lösung generell unter busybox für mich auch wichtig ist

Die Busybox hat ein Mini-Netcat, das heißt da „nc“. Auf meiner alten FritzBox 7170 geht das dann so:

1
echo -ne 'GET / HTTP/1.0\n\n' | nc heise.de 80

Wenn du die Antwort einer Variablen zuweisen willst, musst du dann Command Substitution machen:

1
2
reply=$(echo -ne 'GET / HTTP/1.0\n\n' | nc heise.de 80)
echo "$reply"

theinlein

Anmeldungsdatum:
29. Dezember 2007

Beiträge: 1279

snafu1 schrieb:

theinlein schrieb:

Dieses Shell-Script ruft sofort tclsh auf (die ersten 3 Zeilen, damit ist man unabhängig davon, wo tclsh installiert ist – aber: Bäcksläsch als letztes Zeichen am Zeilenende nicht vergessen).

Müsste das nicht theoretisch auch mit #!/usr/bin/env tclsh klappen?

JA, müsste klappen - mir fällt jetzt kein großes Problem ein, außer dass der Prozessname dann immer 'tclsh' hieße statt dass der Name des Scriptes verwendet würde. Ich verwende (auch aus Gewohnheit) immer die andere Variante.

theinlein

Anmeldungsdatum:
29. Dezember 2007

Beiträge: 1279

mgolbs schrieb:

Hallo,

danke für die Tipps. Das tclsh Skript wie zuletzt gelistet funktioniert prima auf den Arms Psion Netbook PsionLX sowie auf Zaurus SL5500, nur beim Zaurus muss ich /usr/bin/tcl8.3 angeben. Ich schaffe damit aber nur etwa 410Hz (Psion), 525Hz (Zaurus) Abtastfrequenz der AD's gegnen 730Hz auf Ubuntu.

Die Frage eines reinen Shell Socket steht noch. Ich muss mal die Hinweise der vielen Meldungen unter i386/amd64 ausprobieren. Melde mich dann wieder. Wobei eine Lösung generell unter busybox für mich auch wichtig ist - dnp7520, 5280... http://www.dilnetpc.com/linuxcontrol/DNP7520HWR.pdf bzw. http://www.dilnetpc.com/dnp0038.htm, denn ob ich da überall tclsh finde/installieren kann ist eher fraglich.

Gruß und vielen Dank Markus

Sehe ich das richtig, dass du 750 mal in der Sekunde das MC-Teil abfragen willst und der soll dir ein kByte Block als Antwort liefern? Diese eher 'aufdringliche Art' der Netzwerk-Kommunikation scheint mir nicht unbedingt effizient.

Wie testest du das?

Hast du bedacht, dass das Versenden eines Paketes u.U. hinausgezögert wird, weil es nach Auffassung des Treibers zu wenige Daten enthält und der auf einen Nachschlag wartet? Wenn du direktes SENDEN haben willst, musst du ein 'flush' auf den Socket machen. Bei Python weiß ich nicht, was man da einbaut; bei tcl hieße es auch 'flush'.

Evtl. ist da noch was rauszuholen. Insbesondere, weil dein Python-Script nach dem Senden sofort auf die Antwort wartet - da könnte es zu Totzeiten kommen.

mgolbs

(Themenstarter)

Anmeldungsdatum:
11. Januar 2009

Beiträge: 269

Wohnort: Tirschenreuth - Löbau

Hallo,

vorerst die beste Nachricht. Mit dem im Thema beschriebenen bash Skript über:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
#!/bin/bash

# Öffne als Filedeskriptor Nummer 3 eine TCP-Verbindung zu heise.de auf
# Port 80. Das "<>" heißt, dass dieser Deskriptor zum Lesen und
# Schreiben benutzt werden kann (wie bei einem Socket). 
exec 3<>/dev/tcp/192.168.1.99/50290

# Schicke einen einfachen HTTP-Request an heise. Die Umleitung ">&3"
# hinten heißt einfach, dass der String auf den eben geöffneten
# Deskriptor und damit auf das Socket geschrieben wird. Wichtig ist auch
# "-e" beim echo, denn das sorgt dafür, dass "\n" als Zeilenumbruch
# ausgewertet wird.
echo -ne 'getadc 1 \r\n' >&3

# Lies von Deskriptor Nummer 3 bis es dort nichts mehr zu lesen gibt.
# Das holt die komplette Antwort vom Server ab.
cat <&3

# Schließt den Deskriptor wieder.
exec 3>&-

klappt der Zugriff auf einem i386 oder amd64 System prima.

user1@lenovo64bitcaelinux:~/Desktop$ sh ./avrnetio_bash.sh 
718
^Z
[2]+  Angehalten              sh ./avrnetio_bash.sh
user1@lenovo64bitcaelinux:~/Desktop$ 

Damit ist mein Anliegen dank Eurer Hilfe für mich zur vollsten Zufriedenheit ausgegangen.

Sehe ich das richtig, dass du 750 mal in der Sekunde das MC-Teil abfragen willst und der soll dir ein kByte Block als Antwort liefern? Diese eher 'aufdringliche Art' der Netzwerk-Kommunikation scheint mir nicht unbedingt effizient.

Das sehe ich ganz genau so.

Ich habe jetzt drei Lösungen die laufen, Python Skript, TCL Skript und reine Shell Lösung. Flush verwende ich schon im TCL Skript, in Python wohl irgend wie im s.send(Nachricht) schon drin.

Mit den 400..750 Hz pro AD bin ich noch gar nicht ganz zufrieden. Von der Datenrate müsste mehr gehen. Messsystem hat nur Arm, Cross Over Kabel und Controller.

An der Firmware des MC kann ich nichts machen. Es gibt offene Firmwarelösungen für die Hardware die man sich anpassen könnte http://www.ethersex.de/index.php/Main_Page. Da steck ich nicht weit genug drin und mir fehlt vor allem die Zeit. Habe zwar die Ethersex Installation gemacht, nach meinen Wünschen konfiguriert und *.hex erzeugt und auf einen neuen MC aufgespielt - läuft prima, aber eben noch keine eigene Anpassung bezüglich 2..10 kHz Abtastrate.

Vielen Dank für die tolle Unterstützung!

Gruß Markus

Antworten |