HS/FS IP-Telegramme senden/empfangen TCP - nur eine Session

[swenga]

Hallo zusammen,

geplant ist eine Verbindung vom HS zu einem externen Prozeß herzustellen, bevorzugt würde ich gerne TCP nutzen (Übertragungssicherung). Wenn bei IP-Telegramme senden/empfangen jeweils ein Eintrag mit demselben Port existiert, kriegt das der HS auf die Reihe dass da nur eine Session geöffnet wird? Andernfalls wäre nämlich, wenn "Senden" eine Sitzung eröffnet, der Server-Port erstmal blockiert, so dass "Empfangen" keine Sitzung öffnen kann.

Wird die TCP-Session danach gehalten oder wann wird diese wieder ausgelöst? Die Hilfedatei schweigt sich dazu aus.

Danke schonmal, mfg,

[MatthiasS]

Der HS selbst kann keine TCP-Session halten. Das geht nur mit den Bausteinen von Nils, wie bei hsfusion oder dem Squeeze-Baustein von eckerho1.

[swenga]

Hallo Mathias,

danke fuer die Info. Das heisst dann wahrscheinlich, dass die Session nur aufgebaut wird wenn irgendwo der Abruf aus der Logik für "IP-Telegramm senden/empfangen" getriggert wird und unmittelbar danach wieder geschlossen wird.

Fuers Senden verstehe ich das, aber wie siehts beim Empfangen mit TCP aus? Hier muss doch mit nem Timeout gearbeitet werden, wie soll ich denn sonst wissen ob die Gegenseite schon alle Daten gesendet hat? Der erfolgreiche 3Way-Handshake (= Session offen) bedeutet ja nicht zwangsweise, dass die Gegenseite sofort mit Senden anfängt.

mfg

[NilsS]

Hi Swen,

beschreib mal was du machen willst.

Alles was der HS per default onbaord hat taugt dazu nicht.

Du kannst die den source vom Fritzbox Callmon nehmen und verändern, das hat Holger (eckerho1) auch für seinen Squeeze Baustien gemacht.

für kurze befehle ala telnet, kannst du sonst auch den urllib Baustein verwenden.

Wenn du Hilfe brauchst, meld dich einfach.

Bin ja auch wohl auch bald wieder am HS tätig, so wie es aussieht

[Bodo]

Bin ja auch wohl auch bald wieder am HS tätig, so wie es aussieht

Hoi
Könnte bitte mal jemand den Nils klonen. So drei bis vier mal...

[swenga]

Hallo Nils,

ich hatte die Woche mal geschrieben, dass durch die fehlende Uebertragungssicherung beim DACOM-SMS-Baustein (Loesung mit GSM-Modem) immer wieder mal Benachrichtigungen floeten gehen. Der Baustein erkennt die fehlende Quittung, setzt einen Fehlerausgang und das wars. Kein Resend oder so was...

Daher will ich das Gatewaying auslagern, also irgendwo eine Applikation, die Daten vom HS entgegennimmt und sie aufbereitet dann an die serielle Schnittstelle für das GSM-Modem schickt. Im Rückweg dann kommen Statusdaten (einkommende SMS, Calls, Signallevel etc) zurueck an den HS.

Wegen Übertragungssicherung wäre dann TCP meine Wahl. Wenn ich jetzt jeweils einen Eintrag bei IP-Senden und einen bei IP-Empfangen mache, wird daraus aber wie ich befuerchte nicht eine einzige Session, unsynchronisiert wird der HS dann den Port öffnen, Daten senden, wieder schliessen etc.

Eventuell koennte man eine Webafrage missbrauchen: Da wären Sende- und Empfangsdaten immer in einer TCP-Session. Dann gibts halt ein Command "Send SMS ....." und zurueck ein "HTTP OK" und ein weiteres Command "Get Status" und dann zurueck die Status-Daten in XML.

Oder man loest das ganze als Bytecode-Baustein

mfg


PS: Nils klonen, gute Idee. Ich nehm auch einen. Werde ihn auch fuettern und hegen, fest versprochen

[NilsS]

Wenn ich dich also richtig verstehe, dann möchtest du ein Moxa per TCP session, am besten kontinuierlich verbunden haben, richtig ?

Es könnte evtl. auch ein Modem am Com Port des HS gehen, das würde kaum einen Unterschied machen (solange keine FT1.2 da dran hängt )

Der Baustein sollte gethreaded werden, damit die Logik nicht gebremst wird.

Ich guck mir das sonst die Tage mal an ob ich den TCPBiDir mal völlig DUMM mal umschreibe. (E1 IP E2 Port E3 connect E4 sende zu TCP /A1 empfange TCP A2 connected A3 SystemLOG)


Das könnte man dann individuell nutzen.

gucken wir mal

[swenga]

Wenn ich dich also richtig verstehe, dann möchtest du ein Moxa per TCP session, am besten kontinuierlich verbunden haben, richtig ?

Korrekt. Wobei ich nicht direkt auf den Moxa gehen würde sondern auf nen Server-Port einer Win-/Linux-Applikation, die dann die spezielle Umsetzung der GSM-ASCII-API macht (Leichter zu entwickeln, da online debug-bar).

Aus derzeitiger Sicht werde ich wahrscheinlich folgendes machen:
-Kommunikation HS zu App via TCP, Session wird nur aufgebaut bei vorliegenden Daten und dann wieder geschlossen, Paketverluste werden nicht toleriert (Alarmmeldungen!)
-Kommunikation App zu HS via UDP, daher triggert jeder Empfang eine Auswertung, Verluste werden hier akzeptiert, da die Applikation ihren GSM-Status sowieso regelmaessig wiederholt und als ASCII-XML an den HS schickt.

Die Email-Alarmierungen würde ich dann auch über die Applikation erledigen. Ich habe im HS zwei Email-Alarmierungen hinterlegt, die eine kommt nachweislich immer zweimal, obwohl nur ein Trigger ausgeloest wird....

mfg

[epogo]

Bin ja auch wohl auch bald wieder am HS tätig, so wie es aussieht

Ups... NilsS.... Wird sich bei Gira / Dacom was tun das du wieder weiter entwickeln willst ?

[makki]

@Swen: stand dürfte sein: HS&persistente TCP-Verbindung: is nich (ohne grobe "Hacks")

Bin ja auch wohl auch bald wieder am HS tätig, so wie es aussieht

Nils, Du vermagst nicht nur B&L nen schrecken einzujagen Was ist/fehlt um diesen schlimmen Zustand hoffentlich ganz schnell wieder zu ändern ?

Makki

[swenga]

Hallo zusammen,

danke fuer die Antworten. Das ist natuerlich suboptimal. Dann stellt sich die Frage wozu TCP beim Senden/Empfangen enthalten ist und wie der Empfang realisiert wird. Spätestens hier muesste die Session doch erhalten bleiben, da der HS ja nicht weiss wann alle Daten gesendet wurden.

Bytecode wäre wohl die Allround-Lösung um so etwas zu erschlagen, allerdings haengt mir die Neustart-Orgie am HS mittlerweile sonstwo, so dass es wahrscheinlich wieder eine externe Applikation wird.

mfg

[NilsS]

@Swen: stand dürfte sein: HS&persistente TCP-Verbindung: is nich (ohne grobe "Hacks")

Naja, vielleicht gibts das ja bald in supported

Nils, Du vermagst nicht nur B&L nen schrecken einzujagen Was ist/fehlt um diesen schlimmen Zustand hoffentlich ganz schnell wieder zu ändern ?

alles Gut ..... die Sachen für den HS hab ich doch alle eigentlich fast fertig rumliegen ....

[makki]

so dass es wahrscheinlich wieder eine externe Applikation wird.

Ich glaube zu diesem Schluss kamen wir alle irgendwann Solange diese externe Sache nicht singulär dafür läuft ist es IMHO auch die sinnvolle Lösung, ein socat der aus TCP UDP macht reicht ja ggfs. (wenn man den Rest denn im HS parsen will/kann)

alles Gut .....

Puh, ok, alles gut

Makki

P.S.: Da fällt mir ein, das ich die Anbindung der AI/Altenheim - äh Siemens - WP von swenga nochmal irgendwann ohne Windows-hobel machen wollte

[swenga]

P.S.: Da fällt mir ein, das ich die Anbindung der AI/Altenheim - äh Siemens - WP von swenga nochmal irgendwann ohne Windows-hobel machen wollte

Mönsch makki,

du musst Zeit haben. Klopp das Ding doch in ne VM und schon hostet es auch Dein Linux. Wird wahrscheinlich auf dem Alix-Board ein bisschen knapp, aber es gibt ja auch erwachsene Rechner

Kuemmer Dich doch lieber mal um den 1 Wire-Zählerbaustein, so dass der WMZ mit dem Wiregate out-of-the-box geht *fg*

mfg

[makki]

Kuemmer Dich doch lieber mal um den 1 Wire-Zählerbaustein, so dass der WMZ mit dem Wiregate out-of-the-box geht *fg*

Geht doch schon laaang

*** Features:
* Support fuer DS2423 Counter-Module
...
-- 2009-11-13 22:14 +0200 : WireGate Development <devel@wiregate.de>

Makki