HttpEndpoint nicht mehr erreichbar

[Philip]

Hallo Leute,

ich habe für eine xbase Anwendung eine Internetanbindung gebaut, hierzu nutze ich Websockets.
Ich baue den http endpoint eigentlich wie in der Doku beschrieben auf:

cPort := Var2Char(PORT)


oHttp := HttpEndpoint():new( PORT, "*" )



if FILE("C:\certificates\xyz.pfx")
 oHttp:setCertificateFromFile( "C:\certificates\localisa.pfx" )

else

dcmsgbox("SSL Zertifikat nicht gefunden.")

endif


lStarted := oHttp:start()


Und das klappt alles wunderbar auch mit den Websocket dann, nur eben für knapp einen Tag, nach einem Tag ist der Port nicht mehr erreichbar.

Ich habe debugged und folgendes probiert:
ohttp:islistening() -> .t.
ohttp:port -> {PORT}
ohttp:lasterror -> 0

Also die Anwendung scheint noch zu korrekt laufen laut xbase aber der port ist weder von außen noch über den localhost.

Hat da jemand ähnliche Erfahrungen?

Lg
Philip

[Wolfgang Ciriack]

Hast du mal probiert, KeepAlive auf .T. zu setzen ?

[Dominik Krebs]

Benutzt die die aktuellste Xbase Version?
Es gab eine PDR, bei der ein Verbindungsaufbau über http, bei einem Endpoint der auf https lauscht zum nicht mehr reagieren der Anwendung führte.

[Dominik Krebs]

https://www.alaska-software.com/scripts ... PDRID=7659

[Philip]

Oh wow, danke für die Antworten. Die Version muss ich mal checken, aber ist das in neuen Versionen gelöst das Problem?

Das mit dem Keep Alive ist mir nicht ganz klar, es tritt nämlich auch auf wenn ich mich zb. Einen Tag einfach gar nicht verbinde. Und eine Einstellung von http Endpoint aus seh ich da nicht.

Aber da man ja nie weiß wer den Port scannt und womöglich über http versucht sich zu verbinden könnte der beschriebene Bug das Problem verursachen.

[Philip]

Aja das Issue is solved habe ich eben gelesen, dann teste ich mal die neueste Version.

[Philip]

Hm … ich habs nun mit version 2.00.2256 probiert aber leider gleiches Ergebnis/Problem. Hat noch jemand eine Idee? Oder wie ich das debuggen kann?

[Dominik Krebs]

Du kannst mal versuchen unter dem Pfad "C:\ProgramData\Alaska Software\logfiles" in das passende Log zu schauen. Eventuell findest du hier einen Hinweis.

Ansonsten kann ich dir noch diesen Link empfehlen https://ilx.alaska-software.com/index.p ... dpoint.41/

[Philip]

Aja danke für den Tipp, gibt zumindest ein paar Info was so passiert ist, aber letztendlich nicht tragisches ein paar GET /, GET /.git/config, GET /aaa9 und so sachen, da versucht hald jemand was zu erwischen. Aber ich habe selbst die selben request gesendet um das Problem zu reproduzieren aber leider kein Erfolg.

Interessant fand ich noch:
No-Global-Config: c:\…\global.config
Was ist das? Kann ich da Konfigurationen festlegen?
Seh auch immer cxp-application, vermutlich will xbase default mäßig cxp machen.

Ich nutze meinen Endpoint ausschließlich für websickets, kann ich alles andere irgendwie blockieren? Vielleicht über das config file? Vielleicht löst das ja mein problem.

Irgendwie ist die Doku da sehr mager, zu cxp aber auch zu HttpRequest und co steht meist nur „TBD“. Alaska ist wohl noch nicht im www angekommen.

[Dominik Krebs]

Vielleicht ist es dann sinnvoll sich mal an Alaska zu wenden.
Eventuell ist ja doch ein Fehlverhalten seitens Alaska.

[Philip]

Das werde ich wahrscheinlich als nächstes machen, bin noch am debuggen. Ich habe ein „finding“ wenn ich mit curl meinen endpoint über http fetchen will, hängt curl weil es kein response bekommt, währenddessen habe ich das selbe verhalten, dass ich den WebSocket nicht verwenden kann.

Weiß nicht ob das das Problem reproduziert aber es hat ähnliche Symptome und klingt auch wie das in den Issue beschriebene Problem aber das ist resolved und ich arbeite mit der späteren Version 2.00.2256.

Nun hätte ich 2 Fragen, 1. kann xbase sowas wie eine rewrite rule? Weil über https klappt der curl, also vielleicht ist die Lösung alle http auf https rewriten…

Und ich habe die Funktion SocketNegotiatenSSL gefunden die wie HttpEndpoint in der Group SSL ist, aber die funktioniert nur mit Socket, von WebSocket seh ich da nichts.
Das klingt wie ein Lösungsansatz aber ich will nicht Sockets verwenden, da ich unnötige Arbeit auf meiner Seite sehe. Hat da jemand Erfahrungen mit der Funktion und Websockets?

[Philip]

Alternativ kann ich einen apache als proxy davor hängen aber dass kann doch nicht sinn und zweck einer „modernen“ software sein, xbase muss da doch Lösungen haben…

[Dominik Krebs]

Also ich arbeite jetzt schon ziemlich lang mit der HttpEndpoint und WebHandler Klasse. Ich habe ähnlich Probleme gehabt wie du, bis die PDR schlussendlich behoben wurde.

Bist du sicher das die Runtime auch aktuell ist?

Eventuell ist es auch ein Software Problem von deiner Seite aus. Hast du mal Quellcode den du verwendest?

[Philip]

Hi,

also die Runtime hat den richtigen Zeitstempel, beim übersetzen sehe ich auch "Xbase++ (R) ProjectBuilder Version 2.00.2256", ich habe eben dllinfo.exe benutzt um die cxpcore10.dll zu untersuchen (diese wird in web.ch erzwungen) und auch da sehe ich die Version 2.00.2256, also wüsste nicht wo ich da einen Fehler mache.

Mein Code ist eigentlich recht einfach, mal ohne den Code der ganzen Member auch überschaubar:

Code: Alles auswählen

#include "web.ch"
#INCLUDE "DCDIALOG.CH"

#define INTERNAL_PORT 82
#define PORT 81

PROCEDURE MASY_WEBS(isWeb)
LOCAL cPort
LOCAL cHtml
LOCAL lStarted

cPort := Var2Char(PORT)

oHttp := HttpEndpoint():new( PORT, "*" )
oHttpMasy := HttpEndpoint():new( INTERNAL_PORT, "localhost" )

if FILE("C:\certificates\localisa.pfx")
    oHttp:setCertificateFromFile( "C:\certificates\localisa.pfx" )
else
    dcmsgbox("SSL Zertifikat nicht gefunden.") TIMEOUT 1
endif

if isWeb
    lStarted := oHttp:start()
    IF .NOT. lStarted
      DCMSGBOX "Startup error. Check if port "+cPort+" is already in use."
      RETURN
    ENDIF
endif

lStarted := oHttpMasy:start()
IF .NOT. lStarted
* DCMSGBOX "Hinweis: Port "+cPort+" bereits benutzt." TIMEOUT 1
  RETURN
ENDIF

RETURN

CLASS MasyWebSocket FROM WebSocketHandler
  HIDDEN:
      VAR auth
      VAR isMasy
      VAR partner
      VAR passcode
      VAR id
      VAR user
      VAR isMain
  EXPORTED:
    METHOD onConnect
    METHOD onDisconnect
    METHOD onText
    METHOD onBinary
    METHOD send
    METHOD setPartner
    METHOD getStats
ENDCLASS

[Dominik Krebs]

Hallo,
ich würde noch oHttp sowie oHttpMasy als LOCAL deklarieren.
Das wird jetzt aber vermutlich nicht das Problem sein.

Hat es einen Bestimmten Grund weshalb du mit dem WebSocketHandler() und nicht dem WebHandler() arbeitest?

PS:
Aktuell gibt es es noch die Offene PDR 7705
https://www.alaska-software.com/scripts ... PDRID=7705

Vielleicht betrifft dich das ja auch.

[Philip]

Hallo,

Ja das hatte ich zum debuggen global gestellt, danke.

Passwort hat mein Zertifikat keines.

Ja, WebSocket weil die ursprüngliche Anwendung mehrere exe (Fenster) startet, ich wollte die Applikation komplett online verfügbar machen, aber auch backward kompatibel halten.
Darum verbinde ich je exe ein Browser Fenster oder Tab, schließe die exe wenn der Tab geschlossen wird und nutze die Bidirektionale Verbindung um die gui auch up zu date halten, quasi die express gui, einfach in den Browser gespiegelt mit allen Funktionalitäten.
Hab mir da ein „Framework“ für express ausgedacht dass die Elemente in json Format an den Browser schickt und der baut die gui gleich auf, klappt sonst eigentlich super.
Darum websocket.

[Philip]

Hi,

also gute Neuigkeiten ich meine es gelöst zu haben, danke für die guten Tipps zum debuggen.
War echt hilfreich.

Im Ende war es tatsächlich eine dll die nicht neu gebaut wurde und sich versteckt hat. Aber habe dadurch auch einiges gelernt.

Werde es nun ausgiebig testen.

[Dominik Krebs]

Klasse