There is a WebSocket already, but it seems a javascript library. So, is any library of native socket communication built in cocos2d-x? Or any reliable alternative library is suggested?
I am currently using Websocket for C++. For my server, I use Python with Tornado. So far it has been working well for me.
I’m surprised that you can use Websocket with C++. Isn’t that a java script’s library?
I think he is referring to Websocketpp/Websocket++:
Websocket is a protocol (in fact its an extension to the HTTP protocol), so not exclusive to javascript or browsers.
There is an implementation of a Websocket client in cocos2d-x, see network/WebSocket/WebSocket.h, or the documentation http://www.cocos2d-x.org/reference/native-cpp/V3.9/d0/dab/classcocos2d_1_1network_1_1_web_socket.html
This uses libwebsockets C lib under the hood.
Note. One limitation which may or may not impact you is that the libwebsockets dependency used by cocos2d-x is currently being compiled without SSL support.
It’s great if SSL support is added to libwebsocket.
See this related issue, I’ve managed to get half way there with SSL support - https://github.com/cocos2d/cocos2d-x/issues/14517#issuecomment-161162753
But agree, would be great for this to be fully supported as standard.
1 Like
Thanks you all kindly providing those information.
So, it seems that we can directly use Websocket to simply send/receive packets to each other?
We want to implement the linkage specification about 2+ client, just like peer to peer data exchange(not file).
If you intend to use Websocket to implement a P2P data exchange between 2 devices, then one of the devices will need to be a server and the other device needs to know the ip address of the device in order to connect. However, as far as I know, you cannot open the Websocket as a listener in cocos2d-X. (I might be wrong, correct me if I am).
What I can suggest is that you can implement a separate server and use the server as a proxy to connect the 2 devices. Nonetheless, it will require your devices to connect to the internet. If you want to establish the P2P connection without internet, you might want to consider other options.
You can use standalone Asio: https://think-async.com/Asio/AsioStandalone
That’s not true:
1.7. Relationship to TCP and HTTP
This section is non-normative.
The WebSocket Protocol is an independent TCP-based protocol. Its
only relationship to HTTP is that its handshake is interpreted by
HTTP servers as an Upgrade request.
By default, the WebSocket Protocol uses port 80 for regular WebSocket
connections and port 443 for WebSocket connections tunneled over
Transport Layer Security (TLS) [RFC2818].
You could just use WebSocket++/Websocketpp. It supports TLS.
http://www.zaphoyd.com/websocketpp
Yes, that’s the purpose of the WebSocket protocol. Unlike HTTP it provides full-duplex communication and streams of messages.
1 Like
Yes, good pick up, I’m not going to argue with the RFC 
But, in all practicality, when you try and use websockets to connect devices and servers over mobile networks you quickly realise how coupled the protocol is to HTTP with its piggybacking on port 80. I’ve seen multiple examples of mobile networks (T-Mobile in the UK for example) who’s transparent HTTP proxies will interfere with websocket traffic and prevent connection. The workaround is to use TLS to prevent any intermediaries messing with the payload, and this is the main reason why I’d like to see the websocket implementation in cocos2d-x supporting TLS.
Yes, there are other websocket libraries that could be integrated, but then why have these networking APIs provided by the cocos2d-x framework at all? In my current game I’m using the SocketIO client which uses the Websocket client internally, so I’d have to also write an alternative SIO client.
I’d happily contribute to getting this working if there was appetite in the community to do so. As I said in my github issue comment, I got as far as compiling libwebsockets from source with SSL enabled but am not sure how to configure local trusted certificate path in a generic cross platform way (at least I think thats why it rejects the server certificate even though valid…).
@iQD if you have experience working with Websocket++ do you think this would be a better option than libwebsockets for the cocos2d-x Websocket client to use?
That’s only the handshake. It was designed to support http services/clients to initiate a HTTP connection as well. After the handshake, it switches to an independent binary, full-duplex, message stream based protocol. The protocol is not coupled in any way to the HTTP and there is no piggybacking. Port 80/443 is only used because of the handshake, as the standard ports for webservices is 80/443. That’s the only reason it was chosen.
Yeah, because they expect HTTP traffic on port 80 and because of lazy configuration. There are some providers, that block various stuff. Just don’t use port 80 for WebSocket 
There is no payload in the handshake. Once it is switched to WebSocket, the data is the payload, but this is not HTTP.
The handshake resembles HTTP so that servers can handle HTTP connections as well as WebSocket connections on the same port. Once the connection is established, communication switches to a bidirectional binary protocol that does not conform to the HTTP protocol.
You can use any port you like. The Websocket protocol is not bound to any fixed ports, like any protocol. It’s just something the sysadmin decides.
To provide basic functions to send and receive data over a socket. It’s all but a full fledged networking engine.
Why would you need to write an alternative SIO client, if you are already using one?
That’s great, but it depends on what the users need/want. Some users just need a basic API, some need more features. Implementing a performant and feature-rich networking engine is a lot of work.
I would suggest you concentrate on TLS, not SSL. SSL is pretty old and has some security issues.
It also depends, which SSL/TLS engine you want to use.
You would have to provide the common CAs with your lib, provide your own local root CA or create your CA on the fly. The CAs are just read in from a standard location, which can be configured or is the same throughout all provided platforms. It’s also nice to have the option to ignore SSL/TLS errors and to specify the cert verification depth.
I only digged through the API, examples and docs. It’s a pretty straightforward API with callback handlers, just like the approach in cocos2d-x.
I’m not using WebSockets++(or WebSockets itself), but RakNet, as I need features like NAT punch-through, message encryption, RPC, reliable UDP and other features RakNet is offering.
If I had to choose between using Websocket++ or libwebsockets, I would go with the former. It fully supports RFC6455, has a nice feature list, is header only, cross-platform, is under the BSD license and it passed the Autobahn testsuite
Oh, and there is of course the Autobahn WebSocket/WAMP lib:
http://autobahn.ws/cpp/
Not always an option, e.g. if using a PaaS like Heroku, but I guess one could say ‘then dont use Heroku’…and so on
I think the important fact here for the benefit of this discussion is that it doesn’t work. Lets not get caught up in semantics eh.
Because it is tightly coupled to the Websocket client, and the suggestion on this thread if I’ve understood correctly is to use an alternative websocket client that supports TLS.
Agreed. The steps to compile libwebsockets involves setting a ‘LWS_WITH_SSL’ flag and linking the ‘libssl’ library (for default openssl engine), hence the use of the ‘SSL’ acronym even though we are talking TLS. The world is horribly imprecise sometimes.
This doesn’t appear to happen by default and from a little digging it doesn’t look to be standard across platforms (or even Android OS versions).
WebSockets++ has the same dependency on libssl, so I suspect the same integration problem regardless of which is used.
Anyone with specific experience on how to configure libwebsockets or libssl to use the operating system’s pre-installed trusted certificates, please chime in.
Cheers
Exactly
Sure but it’s not a WebSocket issue, but a PaaS/Server/Proxy issue.
The cocos2d-x implementation or your implementation?
SIOClient/SocketIO is not dependent on WebSocket.
Those are totally independent.
As a reference:
Did you modify it/create your own? Because it’s not the case with the cocos2d-x implementation.
SIOClient/SocketIO is not using WebSocket.
WebSocket is just a wrapper of the libwebsockets-protocol. There is also no WebSocketClient.
Can you link to where you read/found this?
You would have to use the KeyStore API to get the certs:
http://blog.antoine.li/2010/10/22/android-trusting-ssl-certificates/
Sure -
Ahhhh, my bad! I’m really sorry!
I was just searching through the header files, but unfortunately it’s included in the source. 
So the SocketIO implementation only supports WebSocket without any of the fallback transports?
Unfortunately this is not mentioned in the docs.
Ah well, maybe does not even make sense using another transport than WebSocket.
Allrighty then.
Regarding system wide certs. I would suggest doing cert pinning and/or using self signed certs. System wide certs won’t give you any benefit, except when you are implementing a webbrowser.