Perl Daemon schreiben ?

[JuMi2006]

Ich komme einfach auf keinen grünen Zweig mit dem Empfang vom Socket. Das Plugin ist mittlerweile so weit dass ich es gern produktiv testen würde aber das Auslesen des eBus/Socket vertrödelt entweder zu viel Zeit bzw. verliert Telegramme (read) oder blockiert quasi als Dauerschleife mit Telegrammhäppchen (read).
Mit einem if($fh) ist das Plugin auch dauerbesetzt. Zeit für Multi-Thread .
Außer einem Auslagern in ein externes Script mit minütlich aktualisierender Datendatei fällt mir grad nichts ein.

[makki]

Kein Problem..

Makki

[JuMi2006]

Ich meinte da eher an Größe ?
rechne ich mal 500 Telegramme mit jeweils 10 Bytes sind das 5kB ... machbar?

[makki]

a) 170, also dezimal angeben
b) Jein, es bleibt 50% glücks-sache (ich habe erst gestern meine AQ-computer von der toten Moxa umgestellt und geflucht wie ein Rohrspatz.. ein Serial-to-UDP Daemon liegt in der Luft, aber eigentlich keine Zeit..)
c) In Plugin_info kann man alles speichern, Zeichen auf jeden Fall, für komplexe Datentypen liegt ein Beispiel im SVN..

Makki

[JuMi2006]

o.k. das bringt Licht ins dunkel, in meinem Fall nach kurzem Test aber wohl doch unbrauchbar.

Der Datensatztrenner wird wie übergeben? 0xAA / AA / 170 ???

Würde socat bei bei einem funktionierendem EOL auch wirklich bis zum EOL warten und dann linewise senden? Oder ist das dann doch eher Glückssache?

Was kann eigentlich ein plugin_info an Daten ab ? Das würde sich ja zum merken gut eignen.

[makki]

Soweit richtig..
recv ist insofern gefährlich, weil es blockieren kann wenn nichts kommt!

Dem socat kann man das Stand heute nicht beibringen, es hilft nur

if ($fh) # Plugin wurde wegen anliegender Daten (select()) gestartet
{
# byteweise lesen
# Rest bei Telegrammende merken
# usw.
}

Was aber schon viel hilft ist die Option
,icanon=1
bei der seriellen Seite des socat, dann kommen die Daten erheblich geordneter.
Zweite Variante:
,eol=XX

sofern es einen Datensatztrenner gibt.
Da muss man aber leider immer etwas rumprobieren, bis das rund geht.

-> Ich hab vorhin nen neuen socat ins Repository geschoben (1x Update), der 1.6er hatte da wie mir gestern auffiel noch einen hässlichen Bug mit UDP-Datagram.

Makki

[JuMi2006]

Damit kann ich schonmal "nur auf Nachfrage" empfangen ... gerade eingebaut um für das Senden auf den eBus das SYNC Zeichen abzuwarten (Also immer nur 1Byte lesen und auswerten). Jetzt wird jeder Befehl zu 99% auch von der Heizung empfangen.

my $buf;
recv($socket[$socknum],$buf,1);

Wenn ich es richtig verstanden habe dann ist read das Lesen aus dem Buffer des Sockets, geht also, sofern so viele Zeichen im Puffer vorhanden sind recht schnell.
Dagegen liest recv "heiß" vom Socket und dann eben nur so viele Zeichen wie gerade reindröseln ?

Für ein SYNC-Zeichen wäre also ein recv eher zu verwenden als ein read ?

Für das regelmäßige Auslesen (gepufferter Daten) wäre jetzt aber das read sinniger ?

Bei der Annahme dass der Buffer des Sockets auf 8kbyte (oder 4kbyte?) begrenzt ist (Stimmt das?). Wie bekommt man jetzt den Spagat hin dass:
1. Zwischen zwei Leseintervallen genug Daten vorhanden sind um ein Warten des Plugins auf neue Daten zu vermeiden.
2. Zwischen zwei (evtl. zu langen) Leseintervallen Daten aus dem Buffer geschmissen werden (max. Buffergröße).

Hab ich das jetzt halbwegs verstanden ?

Gruß Mirko

[JuMi2006]

Ich komme mit dem Plugin aber leider nicht weiter:

Liest 100 Zeichen ein, das Plugin läuft dann aber auch immer solange bis die 100 Zeichen da sind:

if ($fh) {
 my $buf;
 read($fh,$buf,100)

Liest immer nur ein paar Zeichen ein (keine 24), das Plugin läuft damit aber eben (teilweise mehrmals) jede Sekunde:

if ($fh) {
 my $buf;
 recv($fh,$buf,24,0);

Wo soll ich dem socat denn sagen dass er mir bitte immer wenigstens 1000 bytes senden soll ?

Ich würde das schon gerne nur im Plugin lösen.

[makki]

Wenns wirklich um timing geht, ist weder Perl noch Python noch PHP eine Option..
Das ist aber meistens nicht der Fall, sowas geht mit einem Plugin (socat->UDP->Plugin) ganz wunderbar auch hier & heute. Genau dafür sind die Plugins ursprünglich gemacht worden (nicht als Logik-Engine..)

Wenns genauer sein muss, würd ich eher zu C(++) greifen

Makki

[JuMi2006]

Ich würde für mein aktuelles "eBus-Projekt" gern einen Perl Daemon schreiben der mir ständig und im Hintergrund die eBus-Telegramme liest, filtert und dann für das Wiregate-Plugin bereitstellt.

Hintergrund:
Die Telegramme auf dem eBus kommen im Schnitt mindestens 1-2 mal pro Sekunde. Damit ist ein normales Plugin ja dauerbesetzt. Da die Socketverbindung steht, könnte der Daemon ja darauf zugreifen. Jetzt würde ich im eigentlichen Plugin alle 5 Minuten, oder nach Anforderung, die Telegramme auswerten. Das schein mit die sauberste Lösung.

Eignet sich FIFO dafür oder gibt es einen eleganteren/einfacheren Weg?
Schön wäre es wenn man auf die gesammelten Telegramme quasi sofort aus dem Wiregate-Plugin zugreifen kann.

Das ganze eBus-Projekt würde dann im Zweifel ein Wiregate-Plugin, ein Perl-Modul und den Daemon beinhalten und so hoffentlich eine bidirektionale Verbindung von KNX und eBus ermöglichen.

Danke und Gruß Mirko