Skip to content


Websocket PID #98

francois2metz opened this Issue · 6 comments

4 participants


I want to use websockets to be able to push updates as soon as possible. But with the current implementation of websockets, we need to know the PID of the websocket controller. This PID is only available when we receive a message.

A solution would be to call handle_message with open param. What do you think about it?


Adding an open message is a possibility. Looking into it.


I started to implement my initial proposition, but in facts it doesn't resolve my issue. We need an API similar to streamcontent.


I started to implement my initial proposition, but in facts it doesn't resolve my issue. We need an API similar to streamcontent.

Your solution makes sense and I thought it does solve your problem. Although calling it handle_open would be more correct. handle_message({close, }) relates to a WebSocket close message, while open is an open event.

You'll have some backend that is triggering whatever you want to send to your clients. Each open callback could pass the websocket owner process Pid for the backend to store somewhere.

handle_open( something like Arg#) ->

I'm not very familiar with streamcontent but it seems like you have to do the same kind of thing with "The Pid must typically be passed (somehow) to the producer of the stream." in

You probably need to remove Pids from your backend when the connection closes, and I'm not sure if handle_message({close, ...}) gets called if the socket fails (as opposed to a close WebSocket message)

You can achieve all of the above (except removing Pids) right now by making your javascript send a message on the open event, as in


The name of the open callback is an ongoing topic. So let's move to another name.

For now even when the client send a message when the connection is opened, we are loosing the initial context. For example I authenticate the user before the upgrade to websocket. After the upgrade, I only have a pid without any other information.

So we can at least pass #Arg on the open callback, or something more open similar to gen_*:start_link args.


IIRC the WS handshake request can include a cookie, if it's on the same domain of course. If that isn't already in Arg it could be good to also make that available.

So yeah, your new parameter makes sense for telling your backend about client context, and it's handy to be able to pass some arbitrary parameter all the way from out() as you suggested.

I'm not sure about whether compatibility should be maintained when adding such a paramter.


Now, callback modules can define some optional functions to keep an internal state between calls, like gen_* modules. See the issue #99 and the commit 29a7989 for details.


@capflam capflam closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.