Früher lief es NUR auf telexgateway.de, dann hat Fred was geändert, dass es auf allen 3 Servern verteilt lief.
Nach einiger Zeit (ein bis zwei Monate, würde ich sagen) lief es dann nicht mehr und nur wieder auf
dem tlnserv2. Und dann konnten wir Fred nicht mehr fragen.....
mfg
henning +++
925302 treu d - T1000Z (Hauptanschluss)
55571 fvler a - T100S
210911za hmb d - T150 (Werkstatt)
218308 test d - T1000S/LS (Werkstatt)
925333 =treu d (Minitelex Sanyo SF100) defekt
Fax G2/G3: 05176-9754481 (Sanyo SF100 Thermofax) defekt
Von der Funktion her sind eigentlich die Instanzen des Centralex-Servers unabhängig. Die kommunizieren nicht untereinander sondern nur mit einem der Teilnehmer-Server. So habe ich das jedenfalls verstanden. Da man im i-Telex-System die Adresse des Centralex-Servers nicht separat eingeben kann, müssen die Centralex-Server auf den Teilnehmer-Servern laufen.
Ich vermute auch, dass die Last nicht automatisch auf mehrere Centralex-Server verteilt wird. Es wird vermutlich immer der verwendet, der im i-Telex-System an erster Stelle eingetragen ist. Aber es müsste bei Ausfall eines Centralex-Servers automatisch der nächste verwendet werden.
Die Teilnehmer-Server 1 und 3 laufen meines Wissens aktuell auf Raspberry Pis. Ich weiß nicht, ob die in der Lage sind, bis zu 100 Verbindungen, für die der Centralex-Dienst aktuell ausgelegt ist, zu händeln.
Aktuell sind 50 Teilnehmer bei Centralex angemeldet, aber natürlich nicht alle aktiv.
Folgende Benutzer bedankten sich beim Autor detlef für den Beitrag (Insgesamt 3):
mein Arduino-Code in der Remote-Server-Version (Centralex) läuft schon sehr stabil. Heute habe ich Tests gemacht bei der die Verbindung zum Remote-Server unterbrochen wurde, um zu testen, ob meine State-Machine das jeweilige Problem in den Griff bekommt. Dadurch gab es logischerweise sehr viele Anmeldungen meines Arduinos beim Remote-Server.
Irgendwann hat dann der Remote-Server jede Anmeldung "rejected", hier die TCPIP-Daten:
TCPIP-Data: 4 4 6F 6F 70 0
Command: Reject
Length: 4
Data (in ASCII): OOP
Ich habe mal in den Centralex-Quelltext geschaut. Reject_OOP kommt vom Centralex-Server und bedeutet "Out Of Ports".
Auf dem Centralex-Server sind aber 50 Ports frei. Möglicherweise wird da was gecachet und es kommt zu Engpässen, wenn zuviele Anfragen reinkommen.
Folgende Benutzer bedankten sich beim Autor detlef für den Beitrag:
vielen Dank für die Info. Vermutlich wird der Server am Wochenende am stärksten beansprucht.
Dann kann ich meinen Code lassen, wie er ist. Wenn ein Reject empfangen wird, versucht die State-Machine sich ein paar Sekunden später erneut anzumelden.
Ich finde nur die avisierten 150W bzw. 600W recht heftig, da ich ja nur ca. 5 Watt (80V x max. 0.06A) benötige. Bei den China-Dingern habe ich Angst davor, dass sie mir die "Bude abfackeln".