Entries Tagged as 'WebSocket'

This is the first in a series of posts on WebSocket proxy configuration.

ColdFusion uses dedicated port (8575/8577) to start its internal WebSocket Server by default. Earlier, these ports were required to be always accessible from outside. This setup works well for intranet applications. But for public facing web applications, it is not advisable to keep port open and let it be accessible from outside.

ColdFusion 11 has introduced proxy support for WebSocket. There is a new proxy module that can be configured with IIS and Apache Web Server which intercept ColdFusion WebSocket requests and redirect the requests to the ColdFusion’s internal WebSocket Server. Now, web applications communicate to WebSocket server over the same port on which web application is running.

How to start WebSocket proxy service?

In order to start WebSocket proxy service follow steps mentioned below:

  • Login to ColdFusion Administrator.
  • Navigate to Server Settings > WebSocket.
  • Select “Use Proxy” option under Enable WebSocket Service.
  •  Submit Changes.
  • Restart ColdFusion Application service.

    How to configure WebSocket proxy with ColdFusion?

    We have shipped WebSocket Proxy Configuration tool along with ColdFusion 11 which can be used to configure WebSocket proxy with IIS and Apache Web Server on all supported platforms.

    WebSocket Proxy Configuration tool can be located at:

    •  <cf_install_root>/cfusion/bin/wsproxyconfig.exe(for windows platform)
    •  <cf_install_root>/cfusion/bin/wsproxyconfig.sh(for non-windows platform)

    Supported web servers with WebSocket proxy:

    • IIS 8 or above
    • Apache Web Server 2.2.*

    Upcoming posts in this series:

    • How to configure WebSocket proxy with IIS
    • How to configure WebSocket proxy with Apache Web Server
    • Tuning ColdFusion 11 WebSocket proxy configuration with IIS 8 or above


    Debugging ColdFusion websockets is not the easiest things, at least not as easy as using websockets. ColdFusion 10 provides a seamless integration to websockets. It provides it's own messaging layer and client side JS functions to subscribe and publish messages to a web sockets. As CF websockets works Asynchronously that makes debugging even more complicated.

    However CF10 websockets messages provides some sort of information. It is a bit difficult for beginners.
    Specifically when there is an error message. it is very difficult to determine it is from client side or server side.

    Here is a small tool that will help the beginners in CF10 websockets to debug their application(from client side).This tool will enable a CF programmer to see what is going in and out of the websocket at the browser. It also highlights if there  is any error.


    download and view screenshots


    ColdFusion WebSockets are lightning fast and presents an opportunity to create realtime applications. This time I've created an application that tries to push HTML5 video content over a WebSocket. The idea here is to use a temporary Canvas, since it allows you to draw a video frame on it and then transfer the contents of the drawn video frame (as base64 encoded Image) over a ColdFusion WebSocket channel to the subscribers.

    I've posted this on my blog along with the demo video and code. Check out Pushing HTML5 Video content over ColdFusion WebSockets.

    The very first and  easy step to setup WebSocket is to use the default Channel Listener .But if you need to implement business logic to control the WebSocket system in your application you will have to use a custom Channel Listener CFC.

    Channel Listener has six methods which can be used to control

    • who is allowed to publish data over a websocket channel
    • who is eligible to recieve data  over a websocket channel
    • how to present data to different users

    For more details on how to implement the logic to restrict the right to publish data , read my blog entry - ColdFusion WebSocket Part4:Restricting Right to Publish


    Most of the ColdFusion WebSocket responses are asynchronous, which essentially means that  the response to your WebSocket method calls (such as getSubscriberCount, getSubscriptions, publish, invokeAndPublish, or invoke) come to message handler.

    Since there are different types of responses and all of them come to the message handler, application developer has to interpret each response, figure out the operation that triggered, and show the responses appropriately.

    Let us try to crack  how to categorize the responses received.For more details checkout  my thrid entry on ColdFusion Websocket blog series 

    -Evelin Varghese