I am using libwebsockets C library for writing a websocket server. According to library documentation, it is mentioned that to close websocket connection from server side we need return -1 in callback. When I did that websocket connection is getting closed, but it is not sending any reason.
I want to send Normal Close as the reason from closing websocket connection. Is there any way to achive this libwebsockets. I have seen libwebsockets library has "enum lws_close_status" but there are no api's to use that one.
As of now there is now API to send a close reason to client.
Find below github issue for more info.
https://github.com/warmcat/libwebsockets/issues/196
Edit:
This issue has been resolved. And now new api is provided to set the close reason.
Commit https://github.com/warmcat/libwebsockets/commit/1fb95e8084bc7b27e72bf199ba422efdfbee360b
It might come in libwebsockets 1.7 release.
Related
I'm using the spring framework's spring-graphql library to create a graphql client, as per the docs. When connecting to the server using a websocket for subscriptions, everything works fine for 5 minutes but then the websocket times out and disconnects. It turns out the server requires the client to send a ping message to keep the websocket alive. This is a graphql ping message as specified in the graphql-ws protocol
I've checked in the docs and had a dig around in the code but can't see any way to send this ping message via the spring graphql client. Apollo client has similar functionality to what I'm after via a "keepalive" option in the graplq-ws ClientOptions. Is there any equivalent I can use via spring or alternative way to solve this?
I couldn't find any way to do this so raised an issue on github, and subsequently a PR with some changes to add basic support for sending pings.
See https://github.com/spring-projects/spring-graphql/pull/608
and https://github.com/spring-projects/spring-graphql/issues/605
I'm having a problem using websockets in my backend. I have to re-write some old with golang and old developer using websocket while one client tracking other client's location.
both client connecting websocket with given url
"\(URLConstants.webSocketURL)?token=\(token)&jobId=\(jobId)"
So I thought both client connecting websocket with her/his own token and I need to reflect user's message to other user. I can open two sockets with given url.
It's the first time that I'm using websocket so I'm not sure I'm asking the right question.
You need to send the information to the existing sessions that you stored from opened connection and distribute the information to other users.
Try to go through this solution to get some inspiration https://github.com/suricatatalk/core/blob/master/core.go.
I have set up lighttpd with mod_websocket as discussed in Dom Bramley's blog entry (except that I am using a BeagleBone Black with Debian Wheezy instead of an rPi.)
https://www.ibm.com/developerworks/community/blogs/B-Fool/entry/setting_up_an_mqtt_websocket_gateway_for_raspberry_pi?lang=en
[During the lighttpd/mod_websocket build process I was asked if I wanted to patch the server and I said yes.]
I have the mosquito MQTT broker running on the same host and publishing on various topics.
When I try to connect to the broker with a browser client via the web socket, I can see that everything works okay in terms of the http upgrade to websocket and forwarding the connection request to mosquitto. Mosquitto gets the connection request and accepts it. However, the response that gets back to the browser does not include the Sec-Websocket-Protocol header echoing the subproto specifier mqttv3.1 that was in the original upgrade request. The client correctly rejects this answer and the connection is shut down.
The javascript error from mqttws31.js:912 is "Sent non-empty Sec-Websocket-Protocol header but no response is received." With Wireshark, I can see that this is true; the 101 Switching Protocols response has headers Upgrade, Connection, and Sec-Websocket-Accept, but nothing else.
My mod_websocket config file defines host, port, type, and subproto the same as Dom's example, and I can see from various debug statements that the request gets all the way to Mosquitto correctly.
Can anyone suggest how to get the Websocket-Protocol header to be included in the response? It must work, Dom wrote a blog post describing how he did it!
I think recent versions of mod_websocket broke/removed subprotocol support, but can't confirm it right now. You could try an earlier version, or use a dedicated websocket to tcp gateway like WSS
https://github.com/stylpen/WSS/
The mod_websocket author (Norio Kobota) quickly and effectively resolved this issue for me by making an update to mod_websocket. The fix is currently in a development branch, and available on github. Our discussion is part of the thread for mod_websocket issue 28.
Briefly, the use case that I have (pre-written client library and existing TCP backend) is much less flexible than a roll-your-own client and server combination with respect to connect-time protocol negotiation. However, in my case I don't really need any flexibility or negotiation with the backend, and so mod_websocket can just echo the configuration it has been given without having to dive into the details of the subprotocol.
The updated mod_websocket echoes the subproto entry from its config file during websocket handshake which satisfies the MQTT client library.
So now I have two solutions for adapters between websocket clients and TCP backends! Thanks all for your help.
Doug Johnson
I'm trying to create a fairly simple WebSocket server using Netty 4.0.8. I have the basic handshake set up and working. But messages sent from a separate thread don't seem to be coming through to the client.
The way the client/server interaction works is that the client initiates the connection and then sends an initial message ("hello") over the WebSocket. The server responds immediately. This message comes through and is visible in the Chrome Dev Tools. After this message is written, I store the Channel in a ChannelGroup. This ChannelGroup is initialized like this:
this.broadcastGroup = new NioEventLoopGroup();
this.group = new DefaultChannelGroup("websocket", broadcastGroup.next());
and then the Channel is added like this:
group.add(ctx.channel());
In a separate thread (created outside of Netty), I do:
group.write(new TextWebSocketFrame("text"));
However, this message never appears in the Chrome Dev Tools.
I've tried debugging and I can see that when group.write() is called, the original Channel is in the group, but that's as far as I can get.
Check the ChannelFuture that was returned.. Most likely the ChannelFuture for the write was failed. Maybe you wrote it before the handshake was complete ?
Nevermind. Turns out the issue was that I neglected to call group.flush()
I'm trying to write a server for a webSocket connection. I've read the spec (76, not 75) carefully. I'm using minefield as the browser.
When I try to create a WebSocket from javascript in the browser:
var ws = new WebSocket("ws://localhost:8766/hoho");
The browser responds with
"Firefox can't establish a connection to the server at ws://localhost:8766/hoho."
My server is getting a valid client handshake request, it sends back the response and then boom.
I've run every example handshake example I can find through my server and I match the given responses exactly in every instance. I'm pretty confident that the return byte stream is correct. I don't need help debugging my code, it's doing what I mean it to do. I need help debugging my use of the handshake protocol since when I give minefield what I think is a correct response it laughs at me.
My question is this: How can I debug this thing? I can think of two possibilities.
Is there any way to get minefield to tell me WHY it's rejecting my handshake?
Is there a working, public, webSocket server service on the web? If there is, I can proxy it, watch the byte streams in both direction and figure out where mine is different.
Does anyone have any ideas in these directions or any other ideas?
Thanks for any help.
I'm in the process of debugging a similar situation, and the tool I'm relying on most is netcat, with some additional use of openssl. Shut down your websocket server and run nc -l 8766. That lets you record exactly what headers are being sent. Turn the websocket server back on and use nc 8766 to paste in those same headers and see the result. openssl s_client -connect localhost:443 will let you make the request with ssl, if that is in your mix.
From there, make sure the responses conform completely to the websocket handshake protocol. For instance, my problem right now is that my responses have Connection: close, which is no good.
About the 2nd possibility.
Yes, there is a websocket server out there.
the jWebSocket demo server at http://jwebsocket.org/demos/chat/chat.htm
hope this helps
Added: Echo socket server at: http://www.websocket.org/echo.html
Here's a jsfiddle that I made from http://www.websocket.org echo websocket server which works in Chrome but not in Firefox 6: http://jsfiddle.net/awDLc/
It is adjusted to use MozWebSocket rather than WebSocket, but perhaps that isn't enough?