Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
vbRichClient5 / cWebServer als WebSocket verwenden
151 views
Skip to first unread message
Wolfgang Bußmann
Oct 25, 2015, 5:17:41 AM10/25/15
to
Hallo,
ich versuche verzweifelt den WebServer aus Olaf's vbRichClient5 als
WebSocket zu verwenden.
Welchen Daten muss ich hierfür als Request.Response-Header verwenden?
Codeauszug:
**********
strSecString = Request.Headers.Item("Sec-WebSocket-Key") & GUID
Debug.Print strSecString
strDummy = New_c.Crypt.SHA1(strSecString, True)
Debug.Print strDummy
'externe Function wandelt Hex-Daten aus SHA1 in einen String um
strDummy2 = HexToString(strDummy)
Debug.Print strDummy2
strSecStringReturn = New_c.Crypt.Base64Enc(strDummy2)
Debug.Print strSecStringReturn
' strResponse = "HTTP/1.1 101 Switching Protocols" & vbCrLf & _
' "Upgrade: websocket" & vbCrLf & _
' "Connection: Upgrade" & vbCrLf & _
' "Sec-WebSocket-Accept: " & strSecStringReturn &
vbCrLf & vbCrLf
Request.Response.ResponseType = 101 '= switching protokol
Request.Response.AddHeaderEntry "Upgrade", "websocket"
Request.Response.AddHeaderEntry "Sec-WebSocket-Accept", strSecStringReturn
Request.Response.AddHeaderEntry "Connection", "Upgrade"
Request.Response.SetResponseDataString ""
'Request.Response.SetResponseDataString strResponse '- bei
auskommentierter Version
****************
Ich habe die auskommentierte, als auch die untere Version versucht.
Habe ich in der Berechnung des Sec-WebSocket-Accept String einen Fehler?
Sollte nach einigen Tests eigentlich richtig sein.
In Firefox wird mir ein "Internal Server Error 500" gemeldet. Was
natürlich nicht viel sagt. ;-(
Ich würde mich über jeden Tipp freuen. Und sagt bitte nicht, dass geht
nicht. ;-)
Gruß Wolfgang
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
Wolfgang Wolf
Oct 26, 2015, 3:54:47 AM10/26/15
to
Am 25.10.2015 um 10:17 schrieb Wolfgang Bußmann:
>
>
> Ich würde mich über jeden Tipp freuen. Und sagt bitte nicht, dass geht
> nicht. ;-)
>
Ich sage das nicht, aber ich fürchte Olaf sagt das, siehe (weit nach
>
>
> Ich würde mich über jeden Tipp freuen. Und sagt bitte nicht, dass geht
> nicht. ;-)
>
unten scrollen):
http://www.vbforums.com/showthread.php?788033-Experimental-VB6-FastCGI-Server
Schönen Gruß
W. Wolf
Wolfgang Bußmann
Oct 26, 2015, 1:23:36 PM10/26/15
to
Hallo Wolfgang,
> Leider war das nicht die Antwort, die ich "hören" wollte.
> Wahrscheinlich liegt es daran, dass zu viele Werte zurückgegeben werden.
> Normalerweise gehen nur drei Werte zurück:
> Upgrade: websocket
> Sec-WebSocket-Accept: berechneter SecCode
> Connection: Upgrade
> Zurückgeschickt werden aber (zumindest in meiner letzten Version):
> Upgrade: websocket
> ServerName: vbRichClient-WebServer
> Sec-WebSocket-Accept: berechneter SecCode
> content-Type: text/html
> Content-Length: xx
> Connection: Keep-Alive, Upgrade
> Ich hatte jetzt gehofft, dass man die zu übergebenden Daten im Header
> "manipulieren" kann. Ob der weitere Austausch von Daten möglich ist,
> konnte ich natürlich noch nicht testen. Vielleicht tauchen hier ja
> noch weitere "Fallstricke" auf.
> Falls jemand einen anderen guten VB6-WebServer kennt, der das kann,
> wäre kurze Info schön. Evtl. "erbarmt" sich Olaf " ja doch noch einmal.
> verlagern wir die Diskussion wieder in die NG?
Natürlich, ich hatte versehentlich den falschen "Antwortknopf" gedrückt. ;-)
> Die cWebServer-Klasse ist eine dünne Schicht zwischen der cTCPServer
> un der Anwendung. Das Problem dabei ist, dass hier die beiden
> hierarchisch angeordneten cWebRequest und cWebResponse-Klassen
> erzeugt und befüllt werden. Die cWebServer- Klasse bekommt ein
> TCPServer_DataArrival-Event, löst selbst das ProcessRequest-Event
> aus. Entscheidend ist am ende der Prozedur die
> beiden TCPServer.SendData mit den Header-Daten und den Nutzdaten.
> Man könnte also die cWebServer-Klasse nachprogrammieren und bei den
> Header-Daten nicht die interne .GetHeaderBytes-Funktion aufrufen
> sondern hier ein eigenen Header reinschieben. Das sollte machbar
> sein. Bin mir aber nicht sicher ob das reicht. Wir könnten das ja mal zusammen testen,
> wenn Olaf sich die nächsten Tage nicht meldet.
Verstehe ich das jetzt so, dass man einen cTCPServer nimmt, die
Request-Daten dann selbst verarbeitet und über den cTCPServer wieder die
Response-Daten verschickt?
Wir erstellen uns dadurch die cWebSocket Klasse selbst?
Übrigens, wo nimmst du die .GetHeaderBytes-Function her?
Nach meinen weiteren WebSocket Recherchen kommen aber auch noch einige
weitere Probleme auf uns zu. Z.B. Frames, Threading und Subprotocols. So
ganz einfach sollte das also nicht werden. Wichtig wäre erst einmal
einen einfachen Einstieg zu finden.
Siehe auch:
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers
In PureBasic fand ich folgendes:
https://github.com/Dadido3/WebSocket_Server
Vielleicht kann man aus diesem Code etwas übernehmen oder lernen.
Insgesamt gesehen sicher keine leichte Aufgabe. Aber leicht können Alle!
;-)
Beste Grüße
Wolfgang Bußmann
Wolfgang Wolf
Oct 27, 2015, 4:52:11 AM10/27/15
to
Am 26.10.2015 um 18:23 schrieb Wolfgang Bußmann:
[...]
cWeb-Klassen sind zu sehr auf HTML & Co. ausgelegt, z.B. wie du schon
bemerkt hast: nicht änderbare Header-Einträge (bzw. man kann sehr wohl
den Header erweitern, aber vorhandene Sachen nicht entfernen)
> Übrigens, wo nimmst du die .GetHeaderBytes-Function her?
sagte ich ja, ist eine interne Funktion der cWebResponse-Klasse, auf die
der Web-Server zurückgreift um die Header-Daten an den TCPServer zu
senden. In dieser Funktion sind bestimmte Header-Daten "fest verdrahtet"
und sind deshalb von außen nicht änderbar.
> Nach meinen weiteren WebSocket Recherchen kommen aber auch noch einige
> weitere Probleme auf uns zu. Z.B. Frames, Threading und Subprotocols. So
> ganz einfach sollte das also nicht werden. Wichtig wäre erst einmal
> einen einfachen Einstieg zu finden.
Das meinte ich mit "Bin mir aber nicht sicher ob das reicht". WebSockets
basieren darüber hinaus auf einer dauerhaften Verbindung. Ob bei
entsprechend dichten Datenaustausch dem TCPServer nicht die Puste
ausgeht, kann ich nicht beurteilen. Vielleicht müsste man dort auch noch
Hand anlegen, sofern das eingeschränkte VB-Threading das überhaupt
zulässt. Ich bin da echt nicht tief genug drin, um auch nur annähernd
die Machbarkeit einschätzen zu können. In einem überschaubaren Intranet
könnte das aber prinzipiell funktionieren.
Darf ich fragen: Was willst du (final) mit dem WebSocket anstellen?
>
> Vielleicht kann man aus diesem Code etwas übernehmen oder lernen.
>
> Insgesamt gesehen sicher keine leichte Aufgabe.
Hab's überschlagen, sind ja "nur" ca. 20 A4-Seiten PB-Code.
> Aber leicht können Alle!
> ;-)
Stimmt. In deinem ersten Link ist am Ende der Seite auch ein VB.Net
Tutorial. Vielleicht kommt man damit weiter. Vielleicht daraus erst mal
einen Pseudo-Code ableiten und dann mit den vbRichClient-TCP-Klassen
implementieren.
Olaf hat in vbforums seine Unterstützung auch angeboten, will das aber
nicht selbst machen. Gleiches gilt für mich: Ich habe im Moment keine
Verwendung für WebSockets, meine Motivation ist also begrenzt. Wenn du
dich rein hängen willst, kann ich aber helfen. Z.B. schon mal die
Basis-Kommunikation mit dem TCPServer vorbereiten ohne die WebKlassen
aus dem RichClient zu verwenden. Auf dieser Basis wärst du dann frei in
der Auswahl deiner Header und Protokolle. Habe da was aus einem anderen
TCP-Projekt, muss das halt extrahieren und aufbereiten. Wäre das ein
Einstieg?
Schönen Gruß
W. Wolf
[...]
>
> Verstehe ich das jetzt so, dass man einen cTCPServer nimmt, die
> Request-Daten dann selbst verarbeitet und über den cTCPServer wieder die
> Response-Daten verschickt?
>
> Wir erstellen uns dadurch die cWebSocket Klasse selbst?
>
Genauso ist es. Die Hauptarbeit macht eh die cTCPServer-Klasse. Die
> Verstehe ich das jetzt so, dass man einen cTCPServer nimmt, die
> Request-Daten dann selbst verarbeitet und über den cTCPServer wieder die
> Response-Daten verschickt?
>
> Wir erstellen uns dadurch die cWebSocket Klasse selbst?
>
cWeb-Klassen sind zu sehr auf HTML & Co. ausgelegt, z.B. wie du schon
bemerkt hast: nicht änderbare Header-Einträge (bzw. man kann sehr wohl
den Header erweitern, aber vorhandene Sachen nicht entfernen)
> Übrigens, wo nimmst du die .GetHeaderBytes-Function her?
der Web-Server zurückgreift um die Header-Daten an den TCPServer zu
senden. In dieser Funktion sind bestimmte Header-Daten "fest verdrahtet"
und sind deshalb von außen nicht änderbar.
> Nach meinen weiteren WebSocket Recherchen kommen aber auch noch einige
> weitere Probleme auf uns zu. Z.B. Frames, Threading und Subprotocols. So
> ganz einfach sollte das also nicht werden. Wichtig wäre erst einmal
> einen einfachen Einstieg zu finden.
basieren darüber hinaus auf einer dauerhaften Verbindung. Ob bei
entsprechend dichten Datenaustausch dem TCPServer nicht die Puste
ausgeht, kann ich nicht beurteilen. Vielleicht müsste man dort auch noch
Hand anlegen, sofern das eingeschränkte VB-Threading das überhaupt
zulässt. Ich bin da echt nicht tief genug drin, um auch nur annähernd
die Machbarkeit einschätzen zu können. In einem überschaubaren Intranet
könnte das aber prinzipiell funktionieren.
Darf ich fragen: Was willst du (final) mit dem WebSocket anstellen?
>
> Vielleicht kann man aus diesem Code etwas übernehmen oder lernen.
>
> Insgesamt gesehen sicher keine leichte Aufgabe.
> Aber leicht können Alle!
> ;-)
Tutorial. Vielleicht kommt man damit weiter. Vielleicht daraus erst mal
einen Pseudo-Code ableiten und dann mit den vbRichClient-TCP-Klassen
implementieren.
Olaf hat in vbforums seine Unterstützung auch angeboten, will das aber
nicht selbst machen. Gleiches gilt für mich: Ich habe im Moment keine
Verwendung für WebSockets, meine Motivation ist also begrenzt. Wenn du
dich rein hängen willst, kann ich aber helfen. Z.B. schon mal die
Basis-Kommunikation mit dem TCPServer vorbereiten ohne die WebKlassen
aus dem RichClient zu verwenden. Auf dieser Basis wärst du dann frei in
der Auswahl deiner Header und Protokolle. Habe da was aus einem anderen
TCP-Projekt, muss das halt extrahieren und aufbereiten. Wäre das ein
Einstieg?
Schönen Gruß
W. Wolf
Wolfgang Bußmann
Oct 28, 2015, 2:50:21 AM10/28/15
to
Hallo Wolfgang,
>
> Darf ich fragen: Was willst du (final) mit dem WebSocket anstellen?
Ich habe ein Programm für den Reitsport entwickelt. Ähnlich wie bei
> Darf ich fragen: Was willst du (final) mit dem WebSocket anstellen?
anderen Sportereignissen wird hierbei die Zeit von Lichtschranke Start
bis Ziel gemessen und angezeigt. Die Messung erfolgt über international
anerkannte Messgeräte der Firma Alge oder auch über eine eigene
Hardware-Eigenentwicklung. Im Programm sind natürlich noch diverse
andere reitsportspezifische Details enthalten.
Das Programm dient auch zur Ausgabe auf Großbildleinwänden (bis zu ca. 5
x 3 mtr.). Diese haben jedoch eine wesentlich geringere und teilweise
stark unterschiedliche Pixelauflösung als normale Monitore. Zur Zeit
muss ich daher noch für jede Großbildleinwand eine eigene "Ausgabe"
programmieren. Geht jeweils in eine Picturebox. Skalierungen sind leider
nicht möglich, da das Verhältnis Breite zu Höhe und wie gesagt, die
Pixelauflösung teilweise auch stark schwankt.
Ich möchte jetzt die aktuelle Zeit sowie andere Angaben in "relativer"
Echtzeit direkt an die HTML-Seiten übergeben. Eine Abfrage aus der
HTML-Seite heraus im "Sekunden" Takt möchte ich vermeiden.
Die Ansteuerungsprogramme der meisten Großbildleinwände bieten die
Möglichkeit, einen bestimmten Bildschirmbereich auszuwählen und direkt
auf die Großbildleinwand zu übertragen. Ich möchte daher meinen Kunden
die Möglichkeit geben, die Ausgaben mit Hilfe von HTML, CSS und
Javascript selbst anzupassen. Durch die Pixelangabe in HTML kann der
Kunde "seine" Anzeige ziemlich genau nachbilden. Der WebSocket schickt
dann nur noch die geänderten Werte an die HTML-Clients. Hierdurch müssen
nicht immer die kompletten Daten vom Client abgefragt werden.
> Hab's überschlagen, sind ja "nur" ca. 20 A4-Seiten PB-Code.
schauen, ob man hieraus vielleicht eine DLL basteln kann.
> Stimmt. In deinem ersten Link ist am Ende der Seite auch ein VB.Net
> Tutorial. Vielleicht kommt man damit weiter. Vielleicht daraus erst mal
> einen Pseudo-Code ableiten und dann mit den vbRichClient-TCP-Klassen
> implementieren.
DLL's aber auch auf dem jeweiligen Rechner "registriert" werden müssen
und ich die "registrierlose" Version bevorzuge, erst einmal zurückgestellt.
> Olaf hat in vbforums seine Unterstützung auch angeboten, will das aber
> nicht selbst machen. Gleiches gilt für mich: Ich habe im Moment keine
> Verwendung für WebSockets, meine Motivation ist also begrenzt. Wenn du
> dich rein hängen willst, kann ich aber helfen. Z.B. schon mal die
> Basis-Kommunikation mit dem TCPServer vorbereiten ohne die WebKlassen
> aus dem RichClient zu verwenden. Auf dieser Basis wärst du dann frei in
> der Auswahl deiner Header und Protokolle. Habe da was aus einem anderen
> TCP-Projekt, muss das halt extrahieren und aufbereiten. Wäre das ein
> Einstieg?
Ich habe aber diese noch nicht für HTML eingesetzt. Wenn Du
entsprechenden "Startcode" für HTML hast, wäre mir daran natürlich sehr
gelegen. Ich würde dann versuchen, den WebSocket erst einmal zum Starten
zu bringen. Weitere Details dann nach und nach.
Gruß Wolfgang
Wolfgang Wolf
Oct 29, 2015, 6:52:50 AM10/29/15
to
Am 28.10.2015 um 07:50 schrieb Wolfgang Bußmann:
[...]
die Leitung (in beide Richtungen), entsprechend schnell sind die
Requests. Das wäre (Überschrift WebService) mit dem RichClient sehr
einfach und sicher umzusetzen. Der Vorteil liegt in der Vermeidung der
(fehleanfälligen) permanenten Verbindung. Du musst z.B. permanent dafür
sorgen, dass diese wieder aufgebaut wird, falls sie verloren geht usw.
Auch Clientseitig ist die Sache (für deine Kunden, die die Seite selbst
pflegen wollen) komplizierter, finde ich.
Ein einfacher AJAX aus einem JS, der im halb-Sekundentakt pollt
(schreibt man das so?), würde in etwa so aussehen:
function GetData() {
nocache = "&nocache=" + Math.random() * 1000000;
var request = new XMLHttpRequest();
request.onreadystatechange = function() {
if (this.readyState == 4) {
if (this.status == 200) {
if (this.responseXML != null) {
data1 = this.responseXML...
data2 = this.responseXML...
}
}
}
}
request.open("GET", "ajax_inputs" + nocache, true);
request.send(null);
setTimeout('GetData()', 500);
}
Der WebServer ist ebenfalls ganz einfach. Den Takt schafft der Webserver
mit 10-20 Clients locker. Statt XML könntest auch JSON liefern (der
RichClient kann das auch) oder dein eigenes Datenformat entwerfen (würde
ich nicht machen).
[...]
>
> cTCPServer und cTCPServerClient benutze ich bereits für einiges andere.
> Ich habe aber diese noch nicht für HTML eingesetzt. Wenn Du
> entsprechenden "Startcode" für HTML hast, wäre mir daran natürlich sehr
> gelegen. Ich würde dann versuchen, den WebSocket erst einmal zum Starten
> zu bringen. Weitere Details dann nach und nach.
>
Ok, schreib mal ob du bei den WebSockets bleiben willst, dann stelle ich
was zusammen. Kann allerdings ein bisschen dauern, weil das unter
Freizeit gebucht werden muss ;-)
Schönen Gruß
W. Wolf
[...]
>
> Ich möchte jetzt die aktuelle Zeit sowie andere Angaben in "relativer"
> Echtzeit direkt an die HTML-Seiten übergeben. Eine Abfrage aus der
> HTML-Seite heraus im "Sekunden" Takt möchte ich vermeiden.
>
Also, bei einer Ajax-Anfrage gehen lediglich eine handvoll Bytes über
> Ich möchte jetzt die aktuelle Zeit sowie andere Angaben in "relativer"
> Echtzeit direkt an die HTML-Seiten übergeben. Eine Abfrage aus der
> HTML-Seite heraus im "Sekunden" Takt möchte ich vermeiden.
>
die Leitung (in beide Richtungen), entsprechend schnell sind die
Requests. Das wäre (Überschrift WebService) mit dem RichClient sehr
einfach und sicher umzusetzen. Der Vorteil liegt in der Vermeidung der
(fehleanfälligen) permanenten Verbindung. Du musst z.B. permanent dafür
sorgen, dass diese wieder aufgebaut wird, falls sie verloren geht usw.
Auch Clientseitig ist die Sache (für deine Kunden, die die Seite selbst
pflegen wollen) komplizierter, finde ich.
Ein einfacher AJAX aus einem JS, der im halb-Sekundentakt pollt
(schreibt man das so?), würde in etwa so aussehen:
function GetData() {
nocache = "&nocache=" + Math.random() * 1000000;
var request = new XMLHttpRequest();
request.onreadystatechange = function() {
if (this.readyState == 4) {
if (this.status == 200) {
if (this.responseXML != null) {
data1 = this.responseXML...
data2 = this.responseXML...
}
}
}
}
request.open("GET", "ajax_inputs" + nocache, true);
request.send(null);
setTimeout('GetData()', 500);
}
Der WebServer ist ebenfalls ganz einfach. Den Takt schafft der Webserver
mit 10-20 Clients locker. Statt XML könntest auch JSON liefern (der
RichClient kann das auch) oder dein eigenes Datenformat entwerfen (würde
ich nicht machen).
[...]
>
> cTCPServer und cTCPServerClient benutze ich bereits für einiges andere.
> Ich habe aber diese noch nicht für HTML eingesetzt. Wenn Du
> entsprechenden "Startcode" für HTML hast, wäre mir daran natürlich sehr
> gelegen. Ich würde dann versuchen, den WebSocket erst einmal zum Starten
> zu bringen. Weitere Details dann nach und nach.
>
was zusammen. Kann allerdings ein bisschen dauern, weil das unter
Freizeit gebucht werden muss ;-)
Schönen Gruß
W. Wolf
Schmidt
Nov 1, 2015, 5:48:39 AM11/1/15
to
Am 25.10.2015 um 10:17 schrieb Wolfgang Bußmann:
> Habe ich in der Berechnung des Sec-WebSocket-Accept String einen Fehler?
Ja.
Die SHA1-ReturnValue darf nicht als Hex-String, sondern muss als
ByteArray behandelt (und zusätzlich noch Base64-enkodiert) werden.
Hier mein aktueller Code für den Handshake...
Const ResponseGUID$ = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"
Dim SB As New cStringBuilder, B() As Byte, Crypt As New cCrypt
SB.AppendNL "HTTP/1.1 101 Switching Protocols"
SB.AppendNL "Upgrade: websocket"
SB.AppendNL "Connection: Upgrade"
SB.AppendNL "Sec-WebSocket-Accept: " & _
Crypt.Base64Enc(Crypt.SHA1(SecWebSocketKey & ResponseGUID))
SB.AppendNL ""
B = SB.ToUTF8
> Und sagt bitte nicht, dass geht nicht.
hab' ich jetzt erstmal eingebaut (RC5-version >= 5.0.38) -
RC5-Download wie immer von hier (ca. 2.4MB):
http://vbRichClient.com/Downloads/vbRC5BaseDlls.zip
Eine kleine VB6-WebSocket-PushServer-Demo mit zwei "Channels":
- ein simpler ServerTime-Push
- und ein kleiner Chat-Pusher
steht hier (ca. 6KB):
http://vbRichClient.com/Downloads/WebSocketPushServer.zip
ScreenShot (geht also sogar mit 'nem IE >= 10, für Leute die
das vielleicht mit einem MS-BrowserControl ausprobieren wollen):
http://vbRichClient.com/Downloads/WebSocketsDemo.png
Konkurrierender Multi-Client-Betrieb, getestet parallel mit
versch. Browser-Instanzen (IE10, IE11, Chrome, Firefox) funktioniert.
Olaf
Schmidt
Nov 1, 2015, 6:05:19 AM11/1/15
to
Am 29.10.2015 um 11:52 schrieb Wolfgang Wolf:
> Also, bei einer Ajax-Anfrage gehen lediglich eine handvoll Bytes über
> die Leitung (in beide Richtungen), entsprechend schnell sind die
> Requests. Das wäre (Überschrift WebService) mit dem RichClient sehr
> einfach und sicher umzusetzen. Der Vorteil liegt in der Vermeidung der
> (fehleanfälligen) permanenten Verbindung. Du musst z.B. permanent dafür
> sorgen, dass diese wieder aufgebaut wird, falls sie verloren geht usw.
> Auch Clientseitig ist die Sache (für deine Kunden, die die Seite selbst
> pflegen wollen) komplizierter, finde ich.
Jo, bei nur geringem Client-Count (also wenn das Produkt aus
> Also, bei einer Ajax-Anfrage gehen lediglich eine handvoll Bytes über
> die Leitung (in beide Richtungen), entsprechend schnell sind die
> Requests. Das wäre (Überschrift WebService) mit dem RichClient sehr
> einfach und sicher umzusetzen. Der Vorteil liegt in der Vermeidung der
> (fehleanfälligen) permanenten Verbindung. Du musst z.B. permanent dafür
> sorgen, dass diese wieder aufgebaut wird, falls sie verloren geht usw.
> Auch Clientseitig ist die Sache (für deine Kunden, die die Seite selbst
> pflegen wollen) komplizierter, finde ich.
Client-Anzahl x Polling-Frequenz noch so unter 200 Requests
pro Sekunde liegt), dann ist das noch im Bereich erträglicher
CPU-Loads auf Serverseite (< 5% oder so).
Wäre auf jeden Fall die robustere Lösung (das ist Polling
immer, im Vergleich zu "offengehaltenen Push-Kanälen", egal
in welchem Szenario).
Also solange die "Kosten an zus. CPU oder Traffic" in
erträglichem Rahmen bleiben, geht da eigtl. nix drüber.
Die Demo jedenfalls auch Code für einfache jsonAjaxRPCs.
Der WebSocket-Push-Support ist trotzdem einen Versuch wert -
habe hier keine Instabilitäten oder Verbindungsabbrüche
feststellen können ... falls das Ganze jedoch später in
einem WLAN-Szenario laufen soll, empfiehlt sich entspr.
intensiveres Testen (Verbindungs-Abbrüche sind dann
wahrscheinlicher).
Olaf
Wolfgang Bußmann
Nov 1, 2015, 11:27:33 AM11/1/15
to
Hallo Olaf,
>> Habe ich in der Berechnung des Sec-WebSocket-Accept String einen Fehler?
>
> Ja.
der Ausgabe einer Funktion aus PureBasic kontrolliert. Beide Strings
waren identisch. Interessehalber werde ich das aber noch einmal prüfen.
> http://vbRichClient.com/Downloads/WebSocketPushServer.zip
Vielen Dank für die Demo. Ist schon heruntergeladen. ;-)
Ich war schon mit einem kleinen Testprogramm angefangen, dass die Daten
über den TCPServer einliest. Request war soweit fertig, Response musste
noch erledigt werden.
> Konkurrierender Multi-Client-Betrieb, getestet parallel mit
> versch. Browser-Instanzen (IE10, IE11, Chrome, Firefox) funktioniert.
Ich werde beide Versionen (Polling oder WebSocket) ausführlichen Tests
unterziehen und schauen, ob ich mich nicht doch für die "sichere"
Variante entscheide.
Nochmals vielen Dank an Euch beide.
Wolfgang Bußmann
Nov 1, 2015, 11:27:45 AM11/1/15
to
Hallo Olaf,
vielen, vielen Dank, dass du dich doch noch "erbarmt" hast.
> Jo, bei nur geringem Client-Count (also wenn das Produkt aus
> Client-Anzahl x Polling-Frequenz noch so unter 200 Requests
> pro Sekunde liegt), dann ist das noch im Bereich erträglicher
> CPU-Loads auf Serverseite (< 5% oder so).
werde den Vorschlag in jedem Fall einem Test unterziehen.
> Der WebSocket-Push-Support ist trotzdem einen Versuch wert -
> habe hier keine Instabilitäten oder Verbindungsabbrüche
> feststellen können ... falls das Ganze jedoch später in
> einem WLAN-Szenario laufen soll, empfiehlt sich entspr.
> intensiveres Testen (Verbindungs-Abbrüche sind dann
> wahrscheinlicher).
lokalen Netz und dürfte daher vorerst keine Probleme bereiten.
Schmidt
Nov 1, 2015, 5:56:30 PM11/1/15
to
Am 01.11.2015 um 17:27 schrieb Wolfgang Bußmann:
>>> Habe ich in der Berechnung des Sec-WebSocket-Accept String
>>> einen Fehler?
>> Ja.
>
> Da ich ja keine Verbindung aufnehmen konnte, hatte ich meine
> Ausgabe mit der Ausgabe einer Funktion aus PureBasic kontrolliert.
> Beide Strings waren identisch. Interessehalber werde ich das aber
> noch einmal prüfen.
Sehe gerade, dass Du (anders als ich annahm) das abschließende
>>> Habe ich in der Berechnung des Sec-WebSocket-Accept String
>>> einen Fehler?
>> Ja.
>
> Da ich ja keine Verbindung aufnehmen konnte, hatte ich meine
> Ausgabe mit der Ausgabe einer Funktion aus PureBasic kontrolliert.
> Beide Strings waren identisch. Interessehalber werde ich das aber
> noch einmal prüfen.
Base64-Encoding nicht vergessen hattest (hatte ich überlesen,
sorry)...
Wenn Deine HexToString-Routine also keinen Fehler macht
(und letztlich genau die "String-Ascii-Bytes" produziert,
die das Weglassen des optionalen AsHexOutput-SHA1-Params
ebenfalls produziert, wie in meinem Beispiel, dann war
Deine Routine an der Stelle nicht falsch.
Die cWebServer-Klasse kann einfach nicht (da als higher
Level, "Simpel-http-Klasse" gebaut), einen *komplett* eigenen
Header-Response-Satz weiterleiten (die ersten Header-Zeilen
der http-Response werden intern immer automatisch generiert,
und ließen - vor meinem Update - eine dem Websocket-
Standard genügende "101-Response" einfach nicht zu.
Olaf
Wolfgang Wolf
Nov 2, 2015, 2:49:37 AM11/2/15
to
Am 01.11.2015 um 12:05 schrieb Schmidt:
>
> Jo, bei nur geringem Client-Count (also wenn das Produkt aus
> Client-Anzahl x Polling-Frequenz noch so unter 200 Requests
> pro Sekunde liegt), dann ist das noch im Bereich erträglicher
> CPU-Loads auf Serverseite (< 5% oder so).
>
Ja, habe hier bereits gegen 200 Clients gearbeitet, die sich aber nicht
>
> Jo, bei nur geringem Client-Count (also wenn das Produkt aus
> Client-Anzahl x Polling-Frequenz noch so unter 200 Requests
> pro Sekunde liegt), dann ist das noch im Bereich erträglicher
> CPU-Loads auf Serverseite (< 5% oder so).
>
im Sekundentakt melden, sondern ereignisgesteuert. Hatte noch keine
Probleme.
> Der WebSocket-Push-Support ist trotzdem einen Versuch wert -
> habe hier keine Instabilitäten oder Verbindungsabbrüche
> feststellen können ... falls das Ganze jedoch später in
> einem WLAN-Szenario laufen soll, empfiehlt sich entspr.
> intensiveres Testen (Verbindungs-Abbrüche sind dann
> wahrscheinlicher).
>
WebServer zu erweitern ist einfacher, sinnvoller als hier eine auf dem
TCPServer basierende Parallelentwicklung in Gange zu setzten.
Schönen Gruß
W. Wolf
0 new messages