HTML5 client reduce prograamers effort by providing client in html5 websocket client. It will be beneficial to many programmers to learn how to use this html5 websocket client with server in java.
i want to create an Example of HTML5 client communicating with a java server, but i am not able to find out the way how to do it. can anyone throw a light on it ?
Reference : demo html5 client/server with c++
I have found a demo on http://java.dzone.com/articles/creating-websocket-chat but its not working for me..
I’ve implemented a simple java server side example which we can take a look at. I’m starting off by creating a ServerSocket which listens for a connection on port 2005
As defined in the RFC standard for the websocket protocol, when a client connects through a websocket, a handshake must be done. So let’s take a look at the handshake() method, it’s pretty ugly so will walk stepwise through it:
The first part reads the client handshake.
The client handshake looks something like this (this is what chrome gave me, version 22.0.1229.94 m), according to the RFC – section 1.2!
Now we can use the keys-map to create a corresponding response in the handshake process. Quoting from the RFC:
So that’s what we have to do! concatenate Sec-WebSocket-Key with a magic string, hash it with the SHA-1 hash function, and Base64-encode it. This is what the next ugly one-liner does.
Then we just return the expected response with the newly hash created into the "Sec-WebSocket-Accept" field.
}
We have now established a successfully websocket connection between the client and the server. So, what now? How do we make them talk to each other? We can start by sending a message from server to client.
NB! We do from this point on, not talk to the client with HTTP anymore. Now we must communicate sending pure bytes, and interpret incoming bytes. So how do we do this?
A message from the server have to be in a certain format called "frames", as spesified in the RFC – section 5.6. When sending a message from the server, the RFC states that the first byte must specify what kind of frame it is. A byte with value 0x81 tells the client that we are sending a "single-frame unmasked text message", which basically is – a text message. The suqsequent byte must represent the length of the message. Following this is the data, or payload. Well, okay… let’s implement that!
So to send a message to the client, we simply call sendMessage("Hello, client!".getBytes()).
That wasn’t too hard? What about recieving messages from the client? Well, it’s a little more complicated, but hang in there!
The frame sendt from the client is almost structured the same way as the frame sendt from the server. First byte is type of message, and second byte is payload length. Then there is a difference: the next four bytes represents a mask. What’s a mask, and why is messages from the client masked, but the servers messages not? From the RFC – section 5.1, we can see that:
So the easy answer is: we just HAVE to. Well why do we have to, you may ask? Didn’t I tell you to read the RFC?
Moving on, after the four byte mask in the frame, the masked payload is following on. And one more thing, the client must set the 9th leftmost bit in the frame to 1, to tell the server that the message is masked (Check out the neat ASCII-art frame in the RFC – section 5.2). The 9th leftmost bit corresponds to our leftmost bit in our second byte, but hey, that’s our payload length byte! This means that all messages from our client will have a payload length byte equal 0b10000000 = 0x80 + the actual payload length. So to find out the real payload length, we must subtract 0x80, or 128, or 0b10000000 (or any other number system you may prefer) from the payload length byte, our second byte in the frame.
Wow, okay.. that sounds complicated… For you "TLDR"-guys, summary: subtract 0x80 from the second byte to get the payload length…
Now that we have read the whole message, it’s time to unmask it so we can make some sense of the payload. To unmask it I’ve made a method which takes the mask, and the payload as arguments, and return the decoded payload. So the call is done with:
Now the unMask method is rather sweet and tiny
Same goes for getSizeOfPayload:
That’s all! You should now be able to communicate in both directions using pure sockets. I will add the complete Java-class for the sake of completeness. It is capable of recieveing and sending messages with a client using websockets.
And a simple client in html:
Hope that this will clear something up, and that I threw some light on it 🙂