HS/FS (Web) limitierung gleichzeitiger TCP-Abfragen

[makki]

Hallo,

wir hatten das Thema schonmal glaub ich, aber ich finds nicht mehr..

Nun, es ist ja leider so, dass der HS bei TCP-Abfragen, falls die Verbindung nicht seitens des Gegners getrennt wird, immer 10sek wartet bevor die TCP-Verbindung seitens des HS geschlossen wird und die Abfrage die Daten auswertet.
Soweit so schlecht, gestern ist mir aber nun aufgefallen, dass der HS offenbar auch nur eine TCP-Verbindung gleichzeitig zu einem Host "abarbeitet" (?) d.h. man ist auf 6 Abfragen/Minute beschränkt, oder mach ich was falsch ?

Konkret, ich habe einiges an einer 8-Port Moxa und davon zwei Sachen via TCP: USV (4006/tcp), alle 2 Minuten 5 Abfragen und neuerdings den Aq-Computer (4008/tcp) mit 4 Abfragen/Minute (die ich gern noch öfter laufen lassen würde).
Seit ich nun letztere aktiviert habe, bekomme ich auch von der USV nicht mehr alle Antworten und im Debug sieht man recht gut dass die Abfragen auf beide auch nur mit jew. 10s Abstand ablaufen, obwohl sie gleichzeitig laufen sollten und könnten.
Nun sollte das ja eigentlich kein Thema sein, die eigentliche Abfrage ist ja in wenigen ms durch und die Moxa erlaubt sogar bis zu vier Verbindungen/Port (d.h. es könnten immer gerade 3 aus-idlen), nur die Limitation auf eine Verbindung/Host in Kombination mit dem 10s Timeout macht das ganze nahe unbrauchbar..

Ich hab auch schon mit dem Inactivity-Timeout der Moxa (1000-5000ms) gespielt, nur funktionieren die Abfragen dann komischerweise gleich garnicht mehr.
Einer einen Tipp für mich wie man da drumherumarbeitet ?
(Screenshots anbei falls es doch an ganz was anderem liegen kann )

Makki

[Gast]

Makki,
Deine Frage kann Dir sicherlich der Hersteller am Besten beantworten.

Aus dem "Bauch" heraus logisch. Der HS kann viel, doch eine Abarbeitung einer Vielzahl von Datenpaketen aus einem TCP-Netz könnte eine neue Herausforderung an dieses Gerät stellen. Meiner Meinung nach ist hierfür der HS derzeit noch nicht gerüstet.
Vielleicht noch in Erinnerung unser Thema mit NAS-Systemen. Bei hoher Netzbelastung gehen die in die Knie. Die Industrie reagierte auf diese Erkenntnisse und hat mittlerweile die neueren Systeme mit Prozessoren und Speicher ausgerüstet. Sind jetzt in der mittleren Preisklasse somit kleine "Rechnerlein".

[PeterH]

Hallo Makki,

der HS serialisiert die Webabfragen.
(also eine nach der anderen)

Bei einer Abfrage geht der HS davon aus, das der Server die Verbindung trennt.
(oder der HS trennt sie nach einem Timeout von 10 Sekunden selber)

Bei dem Moxa sollte man aber auch über UDP arbeiten können.
Damit hast du diese Beschränkungen nicht.

[makki]

hmm, dass alle serialisiert werden ist ja noch schlimmer als ich vermutet habe, erklärt mir aber wenigstens einiges..
Am trennen der Verbindung seitens der Moxa spiele ich noch, das müsste ja irgendwie gehen und würde die Sache stark entschärfen, der grösste Wunsch wäre aber wie bereits mal angemerkt, dass man den 10s-Timeout seites des HS konfigurieren kann. Weil das Problem wird man bei z.B. Telnet-basierten Geschichten immer wieder haben..

Die meisten Sachen laufen ja über UDP, nur halte ich davon wenig wenns a) übers WAN läuft und b) hab ich das Problem die Antworten zuzuordnen.
Für die USV gehts garnicht, weil ich nicht mehr weiss zu welcher Frage die Antwort (nur eine Zahl) gehört und beim dem AQ-Computer muss ich mir dann wohl wieder einen Baustein zum parsen schreiben.. Das ginge halt mit der TCP-Abfrage, wo ich die jew. Antwort direkt in der jew. Abfrage auswerte erheblich einfacher.

Makki

[PeterH]

Du kannst beim Empfang von UDP-Telegrammen jedes Telegramm abhängig von der Absender-IP getrennt verarbeiten.
(eigene Regeln..)
Damit sollte die Gerätezuordnung der IP-Telegramme kein Problem sein.

Ausserdem könnte man den verschiedenen Moxas unterschiedlich Ports im HS geben.
Dies wäre eine weitere Möglichkeit der Gerätezuordnung.

[meudenbach]

...weil ich nicht mehr weiss zu welcher Frage die Antwort (nur eine Zahl) Makki

verstehe ich nicht ?? Warum sollte das nicht gehen. Ich zb. huste ein UDP BC ins Netz und jeder meiner Mac's gibt mir seine Status über UDP zurück und natürlich weiss ich, welcher Mac mir geantwortet hat....

LG

[makki]

Damit sollte die Gerätezuordnung der IP-Telegramme kein Problem sein.

Ausserdem könnte man den verschiedenen Moxas unterschiedlich Ports im HS geben.
Dies wäre eine weitere Möglichkeit der Gerätezuordnung.

Hmm, ich fürchte das hilft mir nichts.. Es ist eine Moxa mit 8 Ports, also nur eine Quell-IP. Die einzelnen Geräte (Ports) kann ich natürlich auf unterschiedliche UDP Zielports am HS legen, nur der Grund warum ichs mit TCP mache ist (siehe erster Screenshot):
ich schicke ein f<CR> und bekomme "100.0 NA" (Batterie-Ladestatus) als Antwort, schreibe diese ins iKO und fertig.
- ein "P<CR>" und bekomme "024.0 NA" (Load) usw.
Wie soll ich dann beim UDP-Empfang ohne komplexe Logik zuordnen, ob ich gerade den Battstatus oder die Load bekommen habe ?

Gleichzeitig wird noch der Erfolg/Fehlerstatus direkt gesetzt, was zwar mit Watchdog&co auch anders geht, es ist nur mit TCP signifikant einfacher zu realisieren. Eben weil man keine eigene Sicherungsschicht bauen muss (ich weiss, ich weiss, ihr mögt UDP )
Die USV liesse sich anders lösen, soll also nur als Beispiel dienen warum TCP mit einfachem zuordnen der Antwort. Und der Aq-Computer wiegesagt mit einem Baustein der die Unterschiedlichen Antworten parsed auch, nur für 4 Werte ist das signifikant aufwändiger als 4 simple Abfragen, weil das einzige Problem der 10s-Timeout zusammen mit der serialisierung ist.
Spätestens beim Denon-Receiver oder vergleichbarem via Telnet ists dann vorbei mit den UDP-Workarounds.
Ich geh jetzt mal sniffen was mit dem inactivity-timer der Moxa schiefläuft..

Makki

[makki]

Also ich baue das ganze jetzt auf UDP um, weils mir natürlich auch sämtliche Webabfragen gehörig ausbremst.

Trotzdem hab jetzt mal die Inactivity-time auf der Moxa zwischen 500-5000ms aktiviert und mitgesnifft.
Versteht mich nicht falsch, es geht mir ein bisschen ums Prinzip weil ich die Sache endlich mal in Griff bekommen möchte da bei einigen geplanten Anwedungsfällen UDP entweder schlicht nicht geht und/oder ich es für sensible Steueraufgaben immernoch für ungeeignet halte, weil man sich immer selber was nachbauen muss um zu gewährleisten dass es auch wirklich ankam.

Das sieht im Capture jedenfalls wunderbar aus, die Moxa schickt die Antwort und nach dem eigenstellten Inactivity-timeout einen RST.
Nur der HS verarbeitet die Antwort nicht ?! Also weitergesnifft, stelle ich den Inactivity-Timeout aus und lasse den HS nach 10s ausidlen (was per FIN/ACK, nicht RST passiert) klappts.
Ohne jetzt einen Blick in die RFC zu werfen, ich glaube das Verhalten der Moxa mit dem RST ist völlig i.O., nur der HS ignoriert die Antwort dann schlicht. (Anhang 1)

Andere Frage: sieht man im Debug eigentlich irgendwo wieviele Bidir-Abfragen in der Pipeline hängen ?

Makki

[viceversa]

Also mein Wunsch wäre es auch, das man den Timeout der Webabfrage konfigurieren kann. Ich habe auch Probleme mit meinen Telnet-Webabfragen.
Warum wird eigentlich die Webabfrage nicht beendet wenn man "Verbindung nach einer bestimmten Anzahl an Daten beenden" ankreuzt? Das würde unsere Probleme vielleicht schon lösen.

[makki]

Warum wird eigentlich die Webabfrage nicht beendet wenn man "Verbindung nach einer bestimmten Anzahl an Daten beenden" ankreuzt? Das würde unsere Probleme vielleicht schon lösen.

Wird sie schon, musst nur die Bytes genau zählen Das klappt, ist nur halt bei dynamischer Länge auch nicht die Lösung..

Makki

[viceversa]

Also du meinst, wenn ich beispielsweise 512 bytes statische Lange abfrage und nach 512 bytes die Abfrage beende, muß ich nicht die 10s warten?
Ich kann mich erinnern das dies bei meinen Versuchen auch nicht gelang.