Tag Archives: websocket

Slides from Nuts and Bolts of WebSocket at #Devoxx 2014

Peter Moskovits from Kaazing (@peterm_kaazing) and I gave a university talk at Devoxx 2014 on Nuts and Bolts of WebSocket. The slides are now available at:

The entire session is recorded and will be made available on parleys.com in the coming weeks/months.

The complete script for the demo is available at github.com/arun-gupta/nuts-and-bolts-of-websocket (including pointers to the demos). Most of the demos are anyway available at the following links:

Positive feedback from twitter overall:

And it was rated the top talk for the day until 6pm:


With Red Hat spirit, “the more you share, the more you grow”, share the slides and demos all over and spread the love!

Happy Devoxx!

STOMP over WebSocket (Tech Tip #53)

STOMP is Simple Text Oriented Messaging Protocol. It defines an interoperable wire format that allows a STOMP client to communicate with any STOMP message broker. This provides easy and widespread messaging interoperability among different languages, platforms and brokers.

The specification defines what makes it different from other messaging protocols:

It is an alternative to other open messaging protocols such as AMQP and implementation specific wire protocols used in JMS brokers such as OpenWire. It distinguishes itself by covering a small subset of commonly used messaging operations rather than providing a comprehensive messaging API.

STOMP is a frame-based protocol. A frame consists of a command, a set of optional headers and an optional body. Commonly used commands are:

  • SEND
  • ACK
  • NACK

WebSocket messages are also transmitted as frames. STOMP over WebSocket maps STOMP frames to WebSocket frames.

Different messaging servers like HornetQ, ActiveMQ, RabbitMQ, and others provide native support for STOMP over WebSocket. Lets take a look at a simple sample on how to use STOMP over WebSocket using ActiveMQ.

The source code for the sample is available at github.com/arun-gupta/wildfly-samples/tree/master/websocket-stomp.

Lets get started!

  1. Download ActiveMQ 5.10 or provision an ActiveMQ instance in OpenShift as explained at github.com/arun-gupta/activemq-openshift-cartridge.
  2. Download WildFly 8.1 zip, unzip, and start as bin/standalone.sh
  3. Clone the repo and deploy the sample on WildFly:
  4. Access the application at localhost:8080/websocket-stomp-1.0-SNAPSHOT/ to see the page as:techtip53-default-page
  5. Specify text payload “foobar and usse ActiveMQ conventions for topics and queues to specify a queue name as “/queue/myQ1”. Click on Connect, Send Message, Subscribe, and Disconnect buttons one after the other. This will display messages on your browser window where WebSocket connection is established, STOMP message is sent to the queue, subscribed to the queue to receive the message, and then finally disconnected.STOMP frames can be seen using Chrome Developer Tools as shown:


    As you can see, each STOMP frame is mapped to a WebSocket frame.

In short, ActiveMQ on OpenShift is running a STOMP broker on port 61614 and is accessible on localhost:61614 by port-forwarding. Clicking on Connect button uses the Stomp library bundled with the application to establish a WebSocket connection with ws://localhost:61614/. Subsequent buttons send STOMP frames over WebSocket as shown in the Frames tab of Developer Tools.

Read more details about how all the pieces work together at jmesnil.net/stomp-websocket/doc/. Jeff has also written an excellent book explaining STOMP over WebSocket and lot more other interesting things that can be done over WebSocket in his Mobile and Web Messaging book.


WebSocket Chat on WildFly and OpenShift (Tech Tip #51)

Chat is one of the most canonical sample to explain WebSocket. Its a fairly commonly used interface and allows to explain the fundamental WebSocket concepts very easily. Of course, Java EE 7 WebSocket has one too, available here! You can easily run it on WildFly using the following steps:

And then access it at http://localhost:8080/chat/.

One of the biggest advantage of WebSocket is how it opens up a socket over the same port as HTTP, 8080 in this case. If you want to deploy this application to OpenShift, then WebSocket is available on port 8000 for regular access, and 8443 for secure access. This is explained in the figure below:


 If you want to run this Chat application on OpenShift, then use the following steps:

  1. Click here to provision a WildFly instance in OpenShift. Change the name to “chatserver” and everything else as default. Click on “Create Application” to create the application.
  2. Clone the workspace:
  3. Edit the first line of “javaee7-samples/websocket/chat/src/main/webapp/websocket.js”from:
  4. Create the WAR file:
  5. Copy the generated WAR file to the workspace cloned earlier:
  6. Remove existing files and add the WAR file to git repository:
    And this shows the output as:

And now your chat server is available at: http://chatserver-milestogo.rhcloud.com and looks like:



Securing WebSocket using wss and HTTPS/TLS (Tech Tip #50)

50th tip on this blog, yaay!

Tech Tip #49 explained how to secure WebSockets using username/password and Servlet Security mechanisms. This Tech Tip will explain how to secure WebSockets using HTTPS/TLS on WildFly.

Lets get started!

  1. Create a new keystore:
    Used “websocket” as the convenience password.
  2. Download WildFly 8.1, unzip, and copy “websocket.keystore” file in standalone/configuration directory.
  3. Start WildFly as
  4. Connect to it using jboss-cli as:
  5. Add a new security realm as:
    And configure it:
  6. Add a new HTTPS listener as:
  7. A simple sample to show TLS-based security for WebSocket is available at github.com/javaee-samples/javaee7-samples/tree/master/websocket/endpoint-wss. Clone the workspace and change directory to “websocket/endpoint-wss”. The sample’s deployment descriptor has:
    This ensures that any request coming to this application will be auto-directed to an HTTPS URL.
  8. Deploy the sample by giving the command:

Now accessing http://localhost:8080/endpoint-wss redirects to https://localhost:8080/endpoint-wss. The browsers may complain about self-signed certificate. For example, Chrome shows the following warning:


And Safari shows the following warning:


In either case, click on “Proceed to localhost” or “Continue” to proceed further. And then a secure WebSocket connection is established.

Another relevant point to understand is that a non-secure WebSocket connection cannot be made from an https-protected page. For example the following code in our sample:

will throw the following exception in Chrome Developer Tools:


Securing WebSockets using Username/Password and Servlet Security (Tech Tip #49)

RFC 6455 provide a complete list of security considerations for WebSockets. Some of them are baked in the protocol itself, and others need more explanation on how they can be achieved on a particular server. Lets talk about some of the security built into the protocol itself:

  • The Origin header in HTTP request includes only the information required to identify the principal (web page, JavaScript or any other client) that initiated the request (typically the scheme, host, and port of initiating origin). For WebSockets, this header field is included in the client’s opening handshake. This is used to inform server of the script origin generating the WebSocket connection request. The server may then decide to accept or reject the handshake request accordingly. This allows the server to protect against unauthorized cross-origin use of a WebSocket server by scripts using the WebSocket API in a browser.

    For example, if Java EE 7 WebSocket Chat sample is deployed to WildFly and accessed at localhost:8080/chat/ then the Origin header is “http://localhost:8080”. Non-browser clients may use the Origin header to specify the origin of the request. WebSocket servers should be careful about receiving such requests.

  • WebSocket opening handshake from client must include Sec-WebSocket-Key and Sec-WebSocket-Version HTTP header field. XMLHttpRequest can be used to make HTTP requests, and allows to set headers as part of that request as:
    If XMLHttpRequest tries to set any header fields starting with Sec- then they are ignored. So a malicious user cannot simulate a WebSocket connection to a server by using HTML and JavaScript APIs.

In addition to these two primary ways, WebSockets can be secured using client authentication mechanism available to any HTTP servers. This Tech Tip will show how to authenticate Java EE 7 WebSockets deployed on WildFly.

Lets get started!

  • Clone Java EE 7 Samples workspace:
  • The “websocket/endpoint-security” sample shows how client authentication can be done before the WebSocket handshake is initiated from the client. This is triggered by including the following deployment descriptor:
    Some key points to understand about this descriptor:

    • <url-pattern> indicates that any request made to this application will be prompted for authentication
    • <auth-constraint> defines the security role that can access this resource
    • <login-config> shows that file-based realm is used with basic authentication
    • <security-role> defines the security roles referenced by this application

    In our particular case, the page that creates the WebSocket connection is protected by basic authentication.

  • Download WildFly 8.1, unzip, and add a new user by invoking the following script:

    This will add user “u1” with password “p1” in group “g1”. The group specified here needs to match as defined in <role-name> in the deployment descriptor.

  • Deploy the sample by giving the command:

Now when the application is accessed at localhost:8080/endpoint-security then a security dialog box pops up as shown:


Enter “u1” as the username and “p1” as the password to authenticate. These credentials are defined in the group “g1” which is referenced in the deployment descriptor. Any other credentials will keep bringing the dialog back.

As soon as the request is successfully authenticated, the WebSocket connection is established and a message is shown on the browser.

If you are interested in securing only the WebSocket URL then change the URL pattern from


In websocket.js, change the URL to create WebSocket endpoint from:


Note, how credentials are passed in the URL itself. As of Google Chrome 38.0.2125.104, a browser popup does not appear if only WebSocket URL requires authentication.

Next Tech Tip will explain how to secure WebSocket using wss:// protocol.

JBoss EAP 6.3 Beta Released: WebSockets, Domain recovery, New console homepage, Improved Security

JBoss EAP 6.3 Beta is released!


This release brings continued progress on the road to making EAP the most manageable and secure Java EE 6-compliant Application Server for traditional and cloud based workloads.

Where to download ?

For current customers with active subscriptions, the Beta can be downloaded from the customer support portal and support tickets can be logged on the Beta.

For community users developing applications that will be deployed on a supported EAP, the Beta can be downloaded from www.jboss.org/products/eap under development terms & conditions, and questions can be posed to the EAP Forum.

Where are docs ?

Complete documentation is available on customer support portal, and here are quick links:

What’s new ?

  • New console homepage featuring a view restricted according to the user’s role and permissions and allowing easy access to:
    • Common tasks and actions within EAP
    • Useful support information within the Red Hat Customer Portal
    • Developer links to tutorials and forums on jboss.org
  • Use the console and patching wizard to easily apply, rollback and view patches.
  • Domain recovery allows users to:
    • Manage multiple servers from a single point with domain mode
    • Configure slave hosts with multiple options to connect to a master host
    • If the primary master host fails, slave hosts may be promoted to become backup master host
    • Remaining slave hosts will automatically search for and connect to a backup master
  • Support for WebSockets implementation, a protocol allowing for full-duplex bi-directional, real-time communication between the client and server
  • Security Vault Enhancements including custom vault implementation and ability to store system-properties and CLI SSL password
  • Kerberos authentication for Datasources for selected databases
  • Management subsystems for PicketLink IDM and Federation allowing you to create and apply security configurations for application(s) from within the container. This is more efficient and less risky than having to maintain separate xml security configuration files within each application, forcing you to redeploy those applications if any changes were made.

If you are looking for a Java EE 7-compliant Application Server, then download WildFly.

WebSocket in JBoss EAP 6.3 (Tech Tip #23)

JBoss EAP (Enterprise Application Platform) is the commercially supported version of community supported JBoss AS 7.x. JBoss EAP 7 is scheduled to be released next year and will provide full compliance with Java EE 7. In the meanwhile, JBoss EAP 6.3 is getting ready to be released later this year.

Download JBoss EAP 6.3 Alpha, or this is also linked from the main downloads page.

A quick summary of JBoss EAP 6.3 is:

Features an updated administrative console that includes a new homepage and exposes the new JBoss EAP 6.2 patching features.  Also includes domain discovery and recovery improvements and support for WebSockets.

WebSocket ?

Yes, JBoss EAP 6.3 provides support for WebSocket using JSR 356 API. However this feature needs to be explicitly enabled by adding the following WEB-INF/jboss-web.xml to your .war file:

A wide variety of WebSocket samples are available here. Try these samples on EAP 6.3 Alpha, and we are looking forward to your feedback.

I tried the canonical chat sample and the output from Chrome and Firefox looked like:


Bug #1083038 provide more details on this feature.

Which WebSocket sample are you going to try ?


REST vs WebSocket Comparison and Benchmarks

One of the common questions asked during my #JavaEE7 presentations around the world is how do WebSockets compare with REST ?

First of all, REST is a style of architecture so what really people mean is RESTful HTTP. As an architecture cannot be compared with a technology. But the term is so loosely used that they are used in place of each other commonly.

Lets start with a one line definition for WebSocket …

Bi-directional and full-duplex communication channel over a single TCP connection.

WebSocket solves a few issues with REST, or HTTP in general:

  • Bi-directional: HTTP is a uni-directional protocol where a request is always initiated by client, server processes and returns a response, and then the client consumes it. WebSocket is a bi-directional protocol where there are no pre-defined message patterns such as request/response. Either client or server can send a message to the other party.
  • Full-duplex: HTTP allows the request message to go from client to server and then server sends a response message to the client. At a given time, either client is talking to server or server is talking to client. WebSocket allows client and server to talk independent of each other.
  • Single TCP Connection: Typically a new TCP connection is initiated for a HTTP request and terminated after the response is received. A new TCP connection need to be established for another HTTP request/response. For WebSocket, the HTTP connection is upgraded using standard HTTP Upgrade mechanism and client and server communicate over that same TCP connection for the lifecycle of WebSocket connection.
  • Lean protocol: HTTP is a chatty protocol. Here is the set of HTTP headers sent in request message by Advanced REST Client Chrome extension.
    And the response headers received from WildFly 8:
    These are 663 characters exchanged for a trivial “Hello World” echo. The source code for this simple application is here.

    For WebSocket, after the initial HTTP handshake, the data is minimally framed with 2 bytes.

Lets take a look at a micro benchmark that shows the overhead caused by REST over a WebSocket echo endpoint. The payload is just a simple text array populated with ‘x’. The source code for the benchmark is available here.

The first graph shows the time (in milliseconds) taken to process N messages for a constant payload size.


Here is the raw data that feeds this graph:


This graph and the table shows that the REST overhead increases with the number of messages. This is true because that many TCP connections need to be initiated and terminated and that many HTTP headers need to be sent and received. The last column particularly shows the multiplication factor for the amount of time to fulfill a REST request.

The second graph shows the time taken to process a fixed number of messages by varying the payload size.


Here is the raw data that feeds this graph:


This graph shows that the incremental cost of processing the request/response for a REST endpoint is minimal and most of the time is spent in connection initiation/termination and honoring HTTP semantics.

These benchmarks were generated on WildFly 8 and the source code for the benchmark is available here.

Together the graph also shows that WebSocket is a more efficient protocol than RESTful HTTP. But does that mean it will replace RESTful HTTP ?

The answer to that, at least in the short term is, NO!

  • WebSocket is a low-level protocol, think of it as a socket on the web. Every thing, including a simple request/response design pattern, how to create/update/delete resources need, status codes etc to be build on top of it. All of these are well defined for HTTP.
  • WebSocket is a stateful protocol where as HTTP is a stateless protocol. WebSocket connections are know to scale vertically on a single server where as HTTP can scale horizontally. There are some proprietary solutions for WebSocket horizontal scaling, but they are not standards-based.
  • HTTP comes with a lot of other goodies such as caching, routing, multiplexing, gzipping and lot more. All of these need to be defined on top of WebSocket.
  • How will Search Engine Optimization (SEO) work with WebSocket ? Works very well for HTTP URLs.
  • All proxy, DNS, firewalls are not yet fully aware of WebSocket traffic. They allow port 80 but might restrict traffic by snooping on it first.
  • Security with WebSocket is all-or-nothing approach.

This blog does not provide any conclusion because its meant to trigger thoughts!

And if you want a complete introduction to JSR 356 WebSocket API in Java EE 7, then watch a recently concluded webinar at vJUG:

So, what do you think ?

J-Fall 2013 Report

1 day, 32 sessions, 4 hands-on lab, 1200 developers, 41 speakers = AWESOME J-Fall 2013! There probably was no better way to celebrate the 10th anniversary of this conference.

This was my third J-Fall (2009 and 2011) and the numer of attendees and overall quality of this conference has improved significantly every time.

The conference started for me at Schiphol where I met Sharat Chander from Oracle. The long ride from the airport to Nijkerk gave us lot of time to catch up with my recent ex-colleague. The speakers’ dinner in the evening was very enjoyable and helped with fighting the jetlag.

The very first session was a talk by Jaap ter Woerds on Building scalable network applications with Netty. The talk gave a quick introduction to Netty and showed a sample application built using it. The slides are available. You can always reach out directly to the speaker or to Norman Maurer – core developer of @netty_project.

My very first talk of the conference turned out to be a replacement talk because of a “missing speaker”. The slides are available:

Getting Started with WebSockets and Server-Sent Events
from Arun Gupta

Twitter feedback seems to indicate that ~60 attendees enjoyed the talk. This session is recorded and should be available on parleys.

The second talk was about code-drive introduction to Java EE 7. This talk used Java EE 7 Samples and explained the new/major improvements to the platform. Here are the specific samples explained in the talk:

All of these samples were created using GlassFish and work on WildFly Beta2 Snapshot (build your self as explained in Tech Tip #1) as well. This session should be available on parleys as well.

The afternoon was packed with the Java EE 7 hands-on lab using NetBeans/GlassFish to about 25 attendees. The latest lab content is always available at github.com/arun-gupta/javaee7-hol. A WildFly version of this lab will is already being worked upon.

And here is my twitter list of the people I met: @BertBertman, @BertBreeman, @Sharat_Chander, @javafxpert, @steveonjava, @hansolo_, @pbakker, @sander_mak, @lucasjellema, @reginatb38, @momatwork, @Bogaart, @tgrall, @JavaWithMarcus, …

Check out some pics …


And the complete album at: