Skip to end of metadata
Go to start of metadata

IG 6.1 will integrate first-class support for web sockets.


  • Tunnel web socket flows transparently
  • Secure/Filter HTTP handshake
  • Proper connection handling in regards to errors
  • SSL termination at IG


  • Filtering at the web socket frame level
  • Automatic reconnection if IG-App link is lost/broken
  • Automatic TLS support (depending if the outgoing connection is secure or not)
  • Secure (OAuth 2 for example) the outgoing HTTP Handshake


Phase 1: Handshake

During this phase, the outbound connection is created, and a first message (WebSocketExchange) is written to the connection to initiate it.

The connection's message is progressively refined down to an HTTP handshake request. When the response is received, if it is a successful upgrade response, the CHF promise is completed, http filter deactivated (not needed anymore, we'll only deal with byte buffers now) and inbound connection is upgraded.

At the end of this phase, the connection is ready to function and forward web socket messages (as byte buffers) back and forth.

Phase 2: Flows

Inbound flow

This flow is for messages coming from the user-agent, targeting the protected application.

The WS adapter implements the Servlet ReadListener interface that is notified whenever some bytes are ready to be read from the stream. It then collect them into a Grizzly Buffer and directly write them into the Connection (sending to the protected application).

Outbound flow

This flow is for messages coming from the protected application, targeting the user-agent.

The WS adapter implements the Servlet WriteListener interface that receive notification when the stream is ready to be written. At this point, if the internal adapter's buffer is not empty, we forward its content into the servlet's stream.

When a message comes from the protected application, it ends up in the adapter, if the stream is ready for write, we directly push the buffer content into it. If not, we append the buffer value to the adapter's buffer (will be pushed when stream is ready notification will be received).

Obviously there is a lock between theses 2 methods because a thread from Tomcat and a thread from Grizzly can try to write the adapter's buffer content at the same time.

Schema (use arrows to navigate)



Summarizing here what needs to be done/verified on a QA Point of view.


  • Bi-directional web socket message forwarding
    • Text/binary messages
    • Partial messages
  • Connection termination and resource releasing
    • User-agent close the inbound connection
    • Connection between IG and app is broken


  • Measure latency
  • Measure horizontal scaling capabilities (number of concurrent connections)


  • Add WebSocketProxyFilter to reference guide
  • Add new section in the gateway guide
    • Extend sample application with websocket support (server / client side ?)


  • No labels