mit html5 Client mit einem Server in Java

8

HTML5-Client reduziert den Aufwand für Programmierer, indem er einen Client im html5-Websocket-Client bereitstellt. Es wird für viele Programmierer von Vorteil sein zu lernen, wie man diesen html5 Websocket Client mit Server in Java benutzt.

Ich möchte ein Beispiel für einen HTML5-Client erstellen, der mit einem Java-Server kommuniziert, aber ich bin nicht in der Lage, die Vorgehensweise zu finden. kann jemand Licht darauf werfen?

Referenz: demo html5 Client / Server mit C ++

Ich habe eine Demo auf Ссылка gefunden, aber es funktioniert nicht für mich ..

    
Hemant Metalia 03.10.2012, 05:18
quelle

6 Antworten

19

Ich habe ein einfaches Java Server-Beispiel implementiert, das wir uns ansehen können. Ich beginne damit, eine ServerSocket zu erstellen, die auf Port 2005 auf eine Verbindung wartet

%Vor%

Wie im RFC-Standard für das Websocket-Protokoll definiert, wenn ein Client über einen Websocket eine Verbindung herstellt, Handshake muss durchgeführt werden. Sehen wir uns die Handshake () -Methode an, sie ist ziemlich hässlich und wird dadurch schrittweise durchlaufen: Der erste Teil liest den Client-Handshake.

%Vor%

Der Client-Handshake sieht ungefähr so ​​aus (das hat mir chrome, Version 22.0.1229.94 m) gegeben, laut RFC - Abschnitt 1.2!

%Vor%

Jetzt können wir mit der Schlüsselzuordnung eine entsprechende Antwort im Handshake-Prozess erstellen. Zitat aus dem RFC:

  

Um zu beweisen, dass der Handshake empfangen wurde, muss der Server zwei nehmen   Informationen und kombinieren sie zu einer Antwort. Der Erste   Information kommt aus dem | Sec-WebSocket-Key | Header-Feld   im Client-Handshake. Für dieses Headerfeld muss der Server übernehmen   der Wert und verketten dies mit dem Globally Unique Identifier,   "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" in String-Form, was ist   wahrscheinlich nicht von Netzwerkendpunkten verwendet werden, die das nicht verstehen   WebSocket-Protokoll. Ein SHA-1-Hash (160 Bits), Base64-codiert, davon   Verkettung wird dann im Handshake des Servers zurückgegeben.

Das müssen wir also tun! verketten Sie Sec-WebSocket-Key mit einer magischen Zeichenfolge, hacken Sie sie mit der Hash-Funktion SHA-1 und Base64-encodieren Sie sie. Das ist es, was der nächste hässliche Einzeiler tut.

%Vor%

Dann geben wir einfach die erwartete Antwort mit dem neu erstellten Hash im Feld "Sec-WebSocket-Accept" zurück.

%Vor%

}

Wir haben jetzt eine erfolgreiche Websocket-Verbindung zwischen dem Client und dem Server hergestellt. So was jetzt? Wie bringen wir sie dazu, miteinander zu reden? Wir können damit beginnen, eine Nachricht vom Server zum Client zu senden. Achtung! Von diesem Punkt an tun wir nicht mehr mit dem Client mit HTTP zu sprechen. Jetzt müssen wir kommunizieren, reine Bytes zu senden und eingehende Bytes zu interpretieren. Wie machen wir das?

Eine Nachricht vom Server muss in einem bestimmten Format namens "frames" sein, wie im RFC - Abschnitt 5.6 beschrieben. Beim Senden einer Nachricht vom Server gibt der RFC an, dass das erste Byte angeben muss, um welche Art von Rahmen es sich handelt. Ein Byte mit dem Wert 0x81 teilt dem Client mit, dass wir eine "Single-Frame unmasked text message" senden, was im Grunde eine Textnachricht ist. Das nachfolgende Byte muss die Länge der Nachricht darstellen. Daran schließen sich die Daten oder Nutzdaten an. Nun, okay ... lass uns das umsetzen!

%Vor%

Um eine Nachricht an den Client zu senden, rufen wir einfach sendMessage ("Hallo, Client!". getBytes ()).

Das war nicht zu schwer? Was ist mit Empfangen von Nachrichten vom Client? Nun, es ist ein wenig komplizierter, aber hängen Sie dort drin!

Der vom Client gesendete Rahmen ist fast strukturiert wie der vom Server gesendete Rahmen. Das erste Byte ist der Nachrichtentyp und das zweite Byte ist die Nutzdatenlänge. Dann gibt es einen Unterschied: Die nächsten vier Bytes repräsentieren eine Maske . Was ist eine Maske, und warum sind Nachrichten vom Client maskiert, aber die Server Nachrichten nicht? Aus dem RFC - Abschnitt 5.1 können wir folgendes sehen:

  

... ein Client muss alle Frames maskieren, die er an den Server sendet ... Ein Server darf keine Frames maskieren, die er an den Client sendet.

Also ist die einfache Antwort: Wir müssen einfach. Nun, warum müssen wir fragen? Habe ich Ihnen nicht gesagt, dass Sie den RFC lesen sollen?

Nach der 4-Byte-Maske im Frame folgt die maskierte Payload. Und noch eine Sache, der Client muss das 9. am weitesten links gelegene Bit im Rahmen auf 1 setzen, um dem Server mitzuteilen, dass die Nachricht maskiert ist (siehe den ordentlichen ASCII-Art-Rahmen im RFC - Abschnitt 5.2). Das 9. Bit ganz links entspricht unserem Bit ganz links in unserem zweiten Byte, aber hey, das ist unser Payload-Length-Byte! Dies bedeutet, dass alle Nachrichten von unserem Client ein Payload-Längenbyte haben, das gleich 0b10000000 = 0x80 + der tatsächlichen Nutzdatenlänge ist. Um also die tatsächliche Nutzdatenlänge herauszufinden, müssen wir 0x80 oder 128 oder 0b10000000 (oder ein anderes Zahlensystem, das Sie bevorzugen) vom Nutzdatenlängenbyte, unserem zweiten Byte im Rahmen, subtrahieren.

Wow, okay .. das hört sich kompliziert an ... Für Sie "TLDR" -Fehler, Zusammenfassung: subtrahiere 0x80 vom zweiten Byte, um die Payload-Länge zu erhalten ...

%Vor%

Nachdem wir nun die gesamte Nachricht gelesen haben, ist es an der Zeit, sie zu entlarven, damit wir uns ein Bild von der Nutzlast machen können. Um es zu demaskieren, habe ich eine Methode erstellt, die die Maske und die Nutzlast als Argumente verwendet und die dekodierte Nutzlast zurückgibt.Also ist der Anruf erledigt mit:

%Vor%

Jetzt ist die unMask-Methode ziemlich süß und winzig

%Vor%

Gleiches gilt für getSizeOfPayload:

%Vor%

Das ist alles! Sie sollten nun in der Lage sein, mit reinen Sockets in beide Richtungen zu kommunizieren. Ich werde der Vollständigkeit halber die komplette Java-Klasse hinzufügen. Es ist in der Lage, Nachrichten mit einem Client über Websockets zu empfangen und zu senden.

%Vor%

Und ein einfacher Client in html:

%Vor%

Ich hoffe, dass dies etwas klären wird, und dass ich etwas Licht darauf geworfen habe:)

    
Andak 20.10.2012, 00:42
quelle
4

Verwenden Sie jQuery-Ajax-Anforderungen von der Client-Seite und Ruhe-Dienste auf der Serverseite.
Hier über das Erstellen eines Kriegsmoduls mit Rest Service

Artikel 1 (Rest Service)

hier abour jQuery ajax

Artikel 2 (jQuery Ajax)

Um Java-Socket-Server zu schreiben, brauchen Sie nur das Hauptprogramm mit

zu erstellen %Vor%

es ist die Hauptkaskade des Serverteils

    
Ilya 03.10.2012 08:21
quelle
1

Lies diesen Blog. Es behandelt, wie Sie Ihre Arbeit mit Federrahmen erreichen können. Volle Unterstützung sollte bald hinzugefügt werden, wenn nicht bereits hinzugefügt.

Ссылка

Ich würde auch vorschlagen, die Frühlings-Release-Notes zu überprüfen.

    
Tinman 17.10.2012 20:36
quelle
0

Sie führen GlassFish aus. Web-Sockets sind nicht standardmäßig aktiviert. Um sie zu aktivieren, müssen Sie den folgenden einzeiligen Befehl in Ihrer Domäne ausführen:

%Vor% Die Methode

HttpServlet.init(...) wird vom Servlet-Container aufgerufen, um einem Servlet anzuzeigen, dass das Servlet in Betrieb genommen wird. * So, Ihre Log-Nachricht gibt nicht die Wahrheit.

    
Timofey Gorshkov 11.10.2012 20:20
quelle
0

Sie können dies auch mithilfe eines vorhandenen Frameworks wie: jWebsocket

erreichen     
Mehdi Karamosly 30.10.2013 00:51
quelle
0

Dies ist derselbe Code oben, nur können Sie Nachrichten vom Client empfangen, die über den 126 Bytes liegen. Viele Web-Socket-Quellcodes haben keine Fragmentierung gefunden.

%Vor%     
user3101886 16.12.2013 11:02
quelle