By arungupta on Nov 07, 2012
TOTD #183 explained how to build a WebSocket-driven application using GlassFish 4. This Tip Of The Day (TOTD) will explain how do view/debug on-the-wire messages, or frames as they are called in WebSocket parlance, over this upgraded connection. This blog will use the application built in TOTD #183.
Viewing WebSocket farmes require special settings because all the communication happens over an upgraded HTTP connection over a single TCP connection. If you are building your application using Java, then there are two common ways to debug WebSocket messages today. Other language libraries provide different mechanisms to log the messages.
Lets get started!
Chrome Developer Tools provide information about the initial handshake only. This can be viewed in the Network tab and selecting the endpoint hosting the WebSocket endpoint.
You can also click on "WebSockets" on the bottom-right to show only the WebSocket endpoints.
Click on "Frames" in the right panel to view the actual frames being exchanged between the client and server.
The frames are not refreshed when new messages are sent or received. You need to refresh the panel by clicking on the endpoint again.
To see more detailed information about the WebSocket frames, you need to type "chrome://net-internals" in a new tab. Click on "Sockets" in the left navigation bar and then on "View live sockets" to see the page.
Select the box with the address to your WebSocket endpoint and see some basic information about connection and bytes exchanged between the client and the endpoint.
Clicking on the blue text "source dependency ..." shows more details about the handshake.
If you are interested in viewing the exact payload of WebSocket messages then you need a network sniffer. These tools are used to snoop network traffic and provide a lot more details about the raw messages exchanged over the network. However because they provide lot more information so they need to be configured in order to view the relevant information.
Wireshark (nee Ethereal) is a pretty standard tool for sniffing network traffic and will be used here. For this blog purpose, we'll assume that the WebSocket endpoint is hosted on the local machine. These tools do allow to sniff traffic across the network though. Wireshark is quite a comprehensive tool and we'll capture traffic on the loopback address.
Start wireshark, select "loopback" and click on "Start".
By default, all traffic information on the loopback address is displayed. That includes tons of TCP protocol messages, applications running on your local machines (like GlassFish or Dropbox on mine), and many others. Specify "http" as the filter in the top-left. Invoke the application built in TOTD #183 and click on "Say Hello" button once. The output in wireshark looks like
Here is a description of the messages exchanged:
- Message #4: Initial HTTP request of the JSP page
- Message #6: Response returning the JSP page
- Message #16: HTTP Upgrade request
- Message #18: Upgrade request accepted
- Message #20: Request favicon
- Message #22: Responding with favicon not found
- Message #24: Browser making a WebSocket request to the
- Message #26: WebSocket endpoint responding back
How are you viewing your WebSocket messages ?
Here are some references for you:
- JSR 356: Java API for WebSocket - Specification (Early Draft) and Implementation (already integrated in GlassFish 4 promoted builds)
#183 - Getting Started with WebSocket in GlassFish
- Binary data as payload
- Custom payloads using encoder/decoder
- Error handling
- Interface-driven WebSocket endpoint
- Java client API
- Client and Server configuration
- Other topics from the API