WebSocket Server

[Dadido3]

Doch, mit dem Debugger kannst du den Programmfluss anhalten, wenn der Server sich aufhängt. Im Idealfall zeigt dir die IDE dann die Stelle wo es im Kreise läuft.
Eventuell musst du den Programmfluss mehrfach starten und stoppen um ein vollständiges Bild zu bekommen. Und es ist vom Zufall abhängig, welcher Thread in der IDE angezeigt wird. Aber bei einer Applikation mit 2 Threads (Dem Websocket-Server Thread und dem Hautpthread) sollte es einigermaßen klappen.

Also wenn es dann passiert, einfach mal das Programm mehrfach anhalten, und die verschiedenen Stellen aufschreiben. Es kann auch helfen das Programm dann mal schrittweise auszuführen (F8). Je mehr informationen hierbei gesammelt werden, desto besser kann man hinterher nachvollziehen was schief läuft.

[stevie1401]

Alles klar, so werde ich es machen.
Wieder etwas dazugelernt
Vielen Dank für deine Hilfe!

[stevie1401]

Als ich den Websocket-Server über einen verschlüsselten Apache-Proxy-Reverse Server laufen lassen wollte, wollte es so gar nicht mit der Websocket-Weiterleitung klappen.

Erst NicTheQuick kam nach langem Suchen auf die Idee einmal den Quellcode des PB-Websocketservers anzuschauen.

Und dort fanden wir dann den Fehler:

Der Apache-Server sendet ein kleines "websocket" und nicht "Websocket". Und auch "upgrade" und nicht "Upgrade".
Da muss man erst einmal drauf kommen.

Deshalb habe ich die Zeilen in der Datei Websocket_Server.pbi jetzt mit einem LCase versehen:

Code: Alles auswählen

 If LCase(*Client\HTTP_Header\Field("Upgrade")) = "websocket"
              If FindString(LCase(*Client\HTTP_Header\Field("Connection")), "upgrade")
              Endif
 Endif

[NicTheQuick]

Wieder ein gutes Argument für OpenSource. Man kann einfach selbst auf Bugsuche gehen, wenn man ein Problem mit einem Programm oder eine Bibliothek hat.

[Dadido3]

Oh, da hab ich garnicht dran gedacht. Aber alle browser, welche ich getestet hatte, hatten damit funktioniert. Ich hätte nicht damit gerechnet, dass nen Proxy sich anders verhält.

Ich hab die Standards nochmal genauer angeschaut: Laut HTTP Standard müssen alle Namen (Nicht Werte) der Header-Felder case-insensitive sein. Und laut dem WebSocket Standard müssen auch die Werte der Header-Felder "Upgrade" und "Connection" case-insensitive sein. Danke für die Info, ich werde es gleich korrigieren.

Damit ist jetzt auch Version 1.000 erreicht. Mein altes Versionsschema lässt nicht beliebig viele "minor updates" zu.

[stevie1401]

Hey Dadido3,
hier eine kleine Rückmeldung nach langem Testen:

Der Server funktioniert gut.
Dennoch habe ich festgestellt, dass manchmal nicht alle Nachrichten beim Client ankommen. Vielleicht auch nicht beim Server, sodass er dann nicht richtig antworten kann.
Unter Linux passiert dies häufiger als bei Windows, passieren tut es aber bei beiden Systemen.

Ab 130-150 Clients, welche ca alle 2-3 Sekunden kleine Strings senden, ist es bemerkbar, dass nicht immer alles ankommt.

Leider fällt mir noch immer keine gute Testmethode ein. Im eigenen Lan funktioniert natürlich immer alles prima, aber sobald Clients "von draussen" kommen, treten die Fehler auf.

Hast du eine Idee woran das liegen könnte?

Ach ja, ab und zu stürzt der Server denn doch noch mal ab. Leider kann ich dir die Stelle wo es hakt nicht nennen, denn die zeigt die Linux-IDE nicht an. Die IDE schließt dann einfach die Console, tut aber so, als würde das Programm noch laufen.

[Dadido3]

Gut, dass es jetzt einigermaßen funktioniert.

Leider kann ich so nicht nachvollziehen woher die Abstürze kommen. Als alternative zum Debugger könntest du noch die OnError Bibliothek benutzen, siehe diesen Code als Beispiel. Dazu muss noch in den Compileroptionen die OnError-Unterstützung eingeschaltet werden. Die Ausgabe geschieht dann per stdout/console.

Das mit den verschwindenden Nachrichten könnte mit dem Crash zusammenhängen, oder es könnte ein zusätzliches Problem sein. Ich würde auf jeden Fall erstmal versuchen den Absturzgrund herauszufinden.

Auch mal auf den Speicherverbrauch schauen. Es wäre möglich, dass die Applikation einfach beendet wird, wenn der Speicher knapp wird (Zumindest hab ich das mal auf einem linux VPS erlebt, da wurden ohne Vorwarnung Programme geschlossen wenn man an seine beim webhoster gebuchte Arbeitsspeichergrenze kam). Die Lösung wäre dann, rauszufinden woher das Speicherleck kommt.

Edit: Der Beispielcode von oben funktioniert natürlich nur wenn der debugger ausgeschaltet ist.

[stevie1401]

Besten Dank! Werde ich mal testen!

[stevie1401]

Hey Dadido3

ab und zu stürzt der Server bei

Code: Alles auswählen

ForEach *Object\Client()

ab.
Ich vermute, der Server will dann an einen Client senden, den es nicht mehr gibt.
Auch wenn ich in meinem Code bei jedem Senden eine Prüfung mache ob der Client wirklich noch in der Liste Client() ist, scheint das nicht zu reichen.

Kannst du in der Websocket_Server.pbi da vielleicht noch einen Schutz oder eine Prüfung einbauen?
Leider verstehe ich den Code nicht, sodass ich das leider nicht kann.

Wäre echt super

Stevie

[Dadido3]

Ich schaue mir mal gerade alle relevanten Stellen an. Bei welcher Zeile(nnummer) stürzt er denn genau ab?

Zum Schutz: Sobald du von einem Client #Event_Disconnect erhälst, ist dieser nicht mehr gültig, und darf auf keine Weise mehr verwendet werden. Eventuell werde ich eine Überprüfung einbauen, entweder durch simples Durchsuchen der List (Langsam), oder über eine Map. Aber wenn du bereits versucht hast sicherzustellen, dass der *Client in der Client() liste vorhanden ist, dürfte es daran nicht liegen.