TCP/UDP Nachrichten Verarbeitungszeit

[saft6luck]

Kann es sein, dass es damit zusammenhängt, das eine Verbindung keinen Handle bekommen hat, und man erst mit dem connect warten muß, bis die alte rausgeworfen wird? Vielleicht ist da eine zeitliche Überschneidung bei der Anfrage des Verbindungsaufbaus.

Da sprichst du von der Linux-Ebene, oder? Einen Handle kann man im eibPC auch sehen, aber wie könnte ich den testen?

Wenn wir hier testen mit z.B. netcat oder auch mit (einem) iPAd und CF konnte ich das nicht beobachten und halte das auch nicht für "normal". Es ging da immer innerhalb 1s. 5 Sekunden oder mehr ist nicht normal und es wäre interessant, woran das genau liegt. Dazu braucht man aber erst mal eine definierte Testumgebung oder Analyse

Dann werde ich mal zusammenschreiben, wie meine Testaufbau genau aussieht. Evtl. kann ich meinen Code ja noch entsprechend zur Test-SW umschreiben.

[enertegus]

Da sprichst du von der Linux-Ebene, oder? Einen Handle kann man im eibPC auch sehen, aber wie könnte ich den testen?

Sorry, war unpräzise.
ich dachte an den Rückgabewert von connecttcp, der ändert sich ja asynchron, d.h. beim Timeout müsste das sich bemerkbar machen bzw. wenn ein neuer connect aufgemacht wird. Aber da fällt mir ein, im vorliegenden Fall arbeitet der EibPC als Server, oder?
Dann würde ich auch mal per Wireshark sehen wollen, was da für Pakete ausgetauscht werden.

[saft6luck]

Aber da fällt mir ein, im vorliegenden Fall arbeitet der EibPC als Server, oder?

Ja. Die Verbindung steht eigentlich schon, die öffnet man im Client, bevor man etwas senden kann.

Dann würde ich auch mal per Wireshark sehen wollen, was da für Pakete ausgetauscht werden.

Stimmt, Wireshark könnte ich auch mal anwerfen ... mal sehen ob da was zu sehen ist.

[ppfeifer]

Hallo,
Ja eigentlich agiert der EibPC hier als Server.
Auf was sollte man achten, wenn man mit Wireshark mitsnifft?

Lg, Peter

[ppfeifer]

Hallo alle miteinander,

nach langer Zeit muss ich das Thema wieder aufgreifen. Wie gesagt, versende ich von meiner Mobotix T24 TCP Netzwerkmeldungen aus an den EibPC, der dann die Meldung abfragt und dementsprechend Aktionen setzt.

Anfangs hab ich der Mobotix die Schuld gegeben, weil ich ja vom EibPC begeistert bin. Ich hab aber nie wirklich herausfinden können, an welchem Ende es hakt.

Zu diesem Zweck hab ich mir jetzt einen kleinen Java TCP Server geschrieben und auf der Mobotix bei meinen Netzwerkprofilen den Java TCP Server neben dem EibPC als Empfänger angegegeben.

Netzwerkmeldungs-Profil 'IP_FrontDoorPIN_Notify'
Zieladresse: 192.168.1.253:4809 192.168.1.144:6789
Meldung: OPEN_DOOR

Wenn ich das dann mit dem Mobotix internen Netzwerkkonfigurations Tester teste bekomm ich die Meldung "OPEN_DOOR" immer unter 2 Sekunden am Display angezeigt. Der EibPC reagiert manchesmal auch in derselben Zeit (was Akzeptabel wäre) aber meiste Zeit dauert es aber 10 oder sogar 23 Sekunden bis der EibPC reagiert.

Das ist natürlich nicht klasse, wenn ich vor der Haustür stehe, den PIN eingebe und fast eine halbe Minute warten muss, bis die Haustür aufgeht.

Was mir auch noch aufgefallen ist, entstehen diese langen Wartezeiten nur, wenn ich den EibPC innerhalb weniger Sekunden mit den Netzwerkmeldungen "bomardiere". Warte ich eine gute Minute erhalte ich auch immer eine Reaktionsszeit von 2 Sekunden.

Ab und an ist das natürlich ärgerlich weil ich schnell mal das Gargentor und die Haustür aufmachen will. Und dazwischen will ich aber keine Minute vergehen lassen.

Habt ihr eine Idee?

lg, Peter

[enertegus]

Was mir auch noch aufgefallen ist, entstehen diese langen Wartezeiten nur, wenn ich den EibPC innerhalb weniger Sekunden mit den Netzwerkmeldungen "bomardiere". Warte ich eine gute Minute erhalte ich auch immer eine Reaktionsszeit von 2 Sekunden.

Was genau meinst du denn mit „bombardieren"?

[ppfeifer]

Morgen,

Was genau meinst du denn mit „bombardieren"?

Innerhalb von 5 Sekunden wieder eine TCPIP Meldung an den EibPC schicken.

Eine Frage hätte ich noch zu closetcp(port,ip). Wenn ich von der Mobotix (192.168.1.5 vom Port 40001) eine Meldung an den EibPC schicke, kann ich vom EibPC aus mit closetcp(40001,192.168.1.5) die Verbindung schließen?

lg,

Peter

[enertegus]

Innerhalb von 5 Sekunden wieder eine TCPIP Meldung an den EibPC schicken.

Das an sich kann der EibPC aber sicher verarbeiten, es sei denn, die Verbindung bricht immer wieder mal ab. Dann muss der EibPC erstmal den TCP Stack initialisieren und da gab es in der aktuellen Version noch einen Bug, der sich ggf. auswirken könnte (sicher ist das aber nicht, ob die neue Version auch dein Problem hier fixen wird).
Kannst Du den Telegrammverkehr zum EibPC irgendwie mitloggen (wireshark am entsprechenden Switch)?
Eine Mobotix haben wir hier auch, ggf. kann sich das mal die Steffi anschauen und die Konfig ähnlich machen und das Problem nachvollziehen.

Eine Frage hätte ich noch zu closetcp(port,ip). Wenn ich von der Mobotix (192.168.1.5 vom Port 40001) eine Meldung an den EibPC schicke, kann ich vom EibPC aus mit closetcp(40001,192.168.1.5) die Verbindung schließen?

Wenn der EibPC selber der Server ist, nein. Dann beendet der EibPC die Verbindung selber nach 30 Sekunden ohne Telegrammverkehr.

[ppfeifer]

Guten Abend,

ich versende bei der Mobotix jede einzelne Netzwerknachricht von einem eigenen Port aus (40001-40011). Und siehe da, der eibPC macht jetzt genau das, was ich von ihm erwarte.

Jetzt weiss ich aber leider noch immer nicht, was/wer das Bottleneck ist Aber ich bin auf jeden Fall zufrieden. So hab ich mir das Zusammenspiel Mobotix und eibPC von Anfang an vorgestellt.

lg,

Peter

[EPIX]

was ich in diesem Zusammenhang nicht verstehe:

Der Enertex® EibPC empfängt immer auf Port 4806. Dieser Port kann nicht verändert werden und ist
vom Sender von UDP Telegrammen zu berücksichtigen.
readudp überprüft im Eingangspuffer des Enertex® EibPC, ob ein UDP Telegramm vorliegt. Wenn
dies der Fall ist, so werden die Argumente der Funktion, in jedem Fall Port und IP, soweit mit Daten
„gefüllt“, bis die empfangene Datenmenge (eingetroffenes UDP Telegramm) zur Datenlänge der Argumente der readudp Funktion passen.
Eine Besonderheit ist die Verwendung der event-Funktion: Sie zeigt an, ob ein Telegramm eingelesen wurde. Im vorliegenden Beispiel haben wir uns darauf verlassen, dass die Daten vom richtigen
Port und Absender kommen. Wir hätten aber auch folgendes Schreiben können, um uns zu versi chern...
if event(readudp(Port,IP,StringPlayer)) and (Port==808u16) and IP=192.168.22.21) then \\

Wenn der eibpc nur auf 4806 empfängt, was bedeuted dann das Beispiel und warum muss man den Port in readudp angeben...

[Uwe!]

es gibt Sender- und Empfänger-Port. Die müssen nicht gleich sein!

[EPIX]

aber ich muss doch beim Sender bereits auf den "richtigen" POrt des eibPC senden, oder nicht.?

Also Sender: sendupd @IP-des-eibpc:4806

[Uwe!]

Ein UDP-Telegramm hat aber immer Quell-Port und Ziel-Port.
Jeder der AN den EibPC etwas senden will, muss mit Ziel-Port 4806 senden, da der EibPC nur auf diesem lauscht.
Er kann aber (grundsätzlich) mit einem beliebigen Quell-Port senden!

Dein Beiepiel "@IP-des-eibpc:4806" definiert den Ziel-Port.

[EPIX]

ahh, OK - Danke!!

[EPIX]

ich stehe vor dem gleichen Problem:
meine Mobotix sendet via TCP an den eibpc eine Nachricht - diese wird jedoch zurückgewiesen:

 
 Verschicken einer Netzwerkmeldung gemäß Profil "Gesamt". Das kann bis zu einer Minute dauern: INF: loading notify profile ip_54f19dab ... INF: name given by user is Gesamt ... INF: set profile send order "sequential" INF: set profile address "192.168.1.228:4806" INF: set profile data type "msg" INF: set profile message "GESAMT $(ID.NAM) event $(FPR.ENO)." INF: set profile raw boundary "--next-image--" INF: set profile send port "4001" INF: force generation of current JPEG ...  ERR: [hdl#1] Connection refused(111): connect to 192.168.1.228:4806 failed! ERR: [hdl#1] Connection refused(111): connect to 192.168.1.228:4806 failed! Result: ERR: Verbindung an Port 4806 vom Host-Computer 192.168.1.228 verweigert!

der Code im eibPC lautet

tcpSenderPort=4001u16
tcpSenderIP=0.0.0.0
tcpSenderString=$                         $

if event(readtcp(tcpSenderPort,tcpSenderIP,tcpSenderString)) then {
 MyText=convert(tcpSenderIP,$$)+$:$+tcpSenderString;
} endif

WebLogger(WebOutWetterID,MyText,$0.8$)

kann es sein, dass readtcp nur funktioniert wenn man es öffnet? (connecttcp?)

"Witzigerweise" zeigt der Code nämlich die Wetterabfragen brav im Weblogger-Fenster an