Inoffizielles deutsches Xbase-Forum

Hi,
Der Webserver scheint nicht darauf zu reagieren, wenn die maximalen Connection erreicht werden. Ich habe String und Codeblock versucht. Beides führt nicht zum Ziel. Es wird weder bei String der Textinhalt dem Client angezeigt, noch wird beim Aufruf des Codeblocks irgdenwas gemacht. Das einizge was beide gemeinsam zu haben scheinen ist, die Session wird geschlossen und der Client gibt die Meldung aus, das er die sichere Seite nicht mehr aufrufen kann.
Hat irgendwer das schonmal umgesetzt und auch gezielt geprüft um bestätigen zu können es klappt oder nicht?

Wie machst Du das? Bei nichtpersistenten Verbindungen ist es wirklich schwer, so viele gleichzeitige Zugriffe zu generieren, dass onMaxConnect feuert. Bist Du sicher, dass es das ist, was passiert? Protokollierst Du die gleichzeitigen Sitzungen usw.?

ich habe zunächst erstmal die MaxConnection auf 1 gesetzt und dann in einer Testumgebung von verschiedenen Seiten darauf zugegriffen. Dabei wurde mir immer angezeigt am Webserver, wieviel Connection gerade offen waren. Das hat gepaßt, es wurde die 1 angezeigt. Es war natürlich etwas kompliziert schnell alle Aufrufe syncron hinzubekommen, aber ich denke mal, es sollte geklappt haben. Dabei wurde aber der String nicht aufgerufen.
Dann habe ich einen Codeblock genommen, der eine Funktion aufruft. Diese Funktion wurde nur 1x bei der Initialisierung aufgerufen, danach nicht mehr wieder. Wenn ich nunvon 3 Seiten mehr oder weniger gleichzeitig auf den Webserver zugreife, wird die Funktion auch nicht aufgerufen. Jedenfalls wurde der Breakpoint niemals aktiviert. Keine Ahnung wie ich das sonst testen sollte.
Wenn ich max Connection hochgetzte habe, war es auch recht schwierig die fehlermeldung bzgl. der sicheren Seite zu produzieren.
Wie gesagt, ich habe es heute zum erstem Mal gezielt geprüft, weil ich eigentlich nach einem anderen Fehler gesucht habe. Ich weiß also nicht, ob es jemals gegriffen hätte.

Die Syntax ist ja (vor dem Start des Servers):
Die Funktion bekommt dann die Client-Instanz als Parameter:
Wenn ich MaxConnections auf 0 setze, nimmt der Server überhaupt keine Verbindungen an - und antwortet sofort hiermit:
Xb2.NET/3.6.04.355 server is temporarily busy!
Please try your request later...

nur mal so gefragt, ist die Seite verschlüsselt, oder einfach nur HTTP?

Beides. SSL unterscheidet sich ja nur dadurch, dass man dem Server ein SSL-Kontext-Objekt zuweist.

Was passiert denn, wenn Du Deinen Server mal auf 0 (Null) Connections runterfährst? Dann müsste onMax sofort feuern, wenn es einen Kontaktversuch gibt.

genau das gleiche wie vorher

Hallo, Manfred.

Es verhält sich tatsächlich mit und ohne SSL unterschiedlich. Ich nehme an, dass die "SendBusy"-Methode schlichtes http macht, also nicht mehr auf den https-Request antwortet. Das ist bei mir auch so - ich bekomme auch den "Connection Reset", und zwar mit serversignierten und mit "echten" Zertifikaten im SSL-Kontext. Letztlich wird das an den aktuellen Browsern liegen. Du kannst keine http-Antwort mehr auf einen https-Request schicken. Das wäre eine Frage für Boris' Forum. Ohne SSL bekommt man die Meldung, die ich oben gezeigt habe, wenn man an Boris' Beispielcode nichts ändert, also das oClient:SendBusy() als Standardverhalten behält.

Aber der onMaxConnect-Slot verhält sich in jedem Fall richtig - der im Codeblock hinterlegte Code wird ausgeführt.

Hi Tom,
freut mich zu hören, das ich nicht falsch lag. Allerdings habe ich den Verdacht, oder Eindruck, das es generell bei SSL nicht klappt. Bei mir wird ::onMaxConnection() überhaupt nicht aufgerufen bei SSL Aber warten wir mal ab was Boris auf Deinen Beitrag antwortet.

Bei mir wird es aufgerufen. Ich erhalte die gleiche Fehlermeldung wie Du, wenn onMaxConnect feuert. Vorher (max. Connections nicht erreicht) antwortet der Server mit allem, womit er antworten soll. Ohne SSL ist das auch so, und bei Erreichen der max. Connections arbeitet SendBusy einwandfrei.

so wie es aussieht hat Boris den Fehler behoben. Aber wohl leider nicht für die, die zu dem Zeitpunkt als der Fehler erkannt wurde eine aktuelle Sub hatten und jetzt nicht mehr. Denn die Bereinigung kommt erst mit dem nächsten Release.

Mit der aktuellen Version ist das Problem gelöst. Auch gegen die bekannte Variante per DoS Attake den Server zu plätten ist die neue Version nun imun.