This may be a noob question, and I admit that I am a noob when it comes to websockets. With ColdFusion, channels seem to be part of the core but when I research websockets in general, excluding ColdFusion, I cannot find documentation on channels. Are channels part of websockets that I’m not finding or are channels a ColdFusion added layer on top of websockets?
Reason for my question, I have a third-party device that offers a websocket communication option. Reading the device documentation, it all sounds simple enough until you try to align the device with CF as the device has no mention of channels. I’ve done some successful experimentation with AWS WebSocket API and it does not mention channels. What is the source of this mythical channel?
Newbie
1 posts
Steve, how did things resolve? Did any of the below help?
Steve, just so I understand correctly. You are wanting to communicate to ColdFusion’s WebSocket server from your third part device.
Can you specify what device and how you configure the WebSocket connection?
If it is trying to just use the WebSocket API directly, you will need to be able to do some extra coding to make it communicate with ColdFusion’s WS Server.
I have several examples that you can review on my GitHub, but I believe this one might be able to help you best if the scenario above is what you are trying to accomplish.
I have been trying to post an answer here, but for some reason I don’t see it offered. And if I try to post it again, it says it’s a duplicate. It had a few links in it, so perhaps it’s awaiting moderation. I will ask Adobe.
Steve, I can’t say I know the answer for sure, but I think I’ve found it by a: searching for the term: websockets “channels” and b: reading mention of “channels” in the CF docs and resources.
Taking the latter first, the primary non-doc resource on CF websockets is this Adobe article which introduced them with cf10. And in it, Awdhesh describes how CF’s ws implementation has two modes (see “WebSocket communication modes”). The first is broadcast mode, which uses channels. The second is p2p (point to point) mode, which does not. The former is for a given websocket to communicate with multiple clients at once. The latter is for one-to-one communication.
While the doc page for cfwebsocket itself doesn’t mention these modes as any sort of attribute, at the bottom of the page it points to the Developer Guide chapter on websockets, and that has sections on p2p and broadcast modes showing it’s simply a matter of whether one uses channels (as defined in application.cfc typically) or not.
So note first that use of channels is optional in CF.
Second, I find many results on the web indicating that the concept of channels in websockets is not unique to CF, but supported by many other websocket solutions. And the references to channels seem to be referring to it as multi-plexing (or “mux”). And it seems it may well be based on an “extension” for websockets originally proposed several years ago (https://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-11), which is implemented in clients using a special header that servers know how to interpret.
As such, when you read about various resources, note they may be older and from before that extension was implemented. Or some clients may still not yet have implemented it. I can’t say I have any experience to indicate whether this is a feature you should or should not expect to work with different clients.
I will say that the last section in the Dev Guide chapter on websockets offers browser version support info. I think that’s more about which support html5 (on which websockets was based) rather than on which may support mux/channels.
Hopefully someone with more specific experience can chime in, or with this new info you may be able to dig around to get still more clarity on the point.
You must be logged in to post a comment.
23 Nov
10AM Pacific
Online
