You said "Once the “socket” is created it may stay in use for a long time". Do you mean that the same socket may send both an HTTP and many WebSocket messages containing JSON? Will it work if you use different sockets? I.e. make one connection and send HTTP
and then close that connection. Then make another connection and send WebSocket messages containing JSON. Is it ok that those are two different connections? If so then you could
use curl for the HTTP connection and websocket++ for the JSON.
It is OK if both connections go to the same server since a single web server can support both HTTP and WebSocket connections using an upgrade as described here:
The opening handshake is intended to be compatible with HTTP-based
server-side software and intermediaries, so that a single port can be
used by both HTTP clients talking to that server and WebSocket
clients talking to that server. To this end, the WebSocket client's
handshake is an HTTP Upgrade request:
If the HTTP and WebSocket messages are required to be on the same connection, then I'm not sure if the WebSocket protocol allows that. Maybe it does since the second message on the connection will be a WebSocket message which the server might
consider to be an upgrade as described above.
As for whether you can use WebSocket++ to do this, I don't know. Websocket++ can be used to create a server that
receives both HTTP and WebSocket client connections but I don't know if WebSocket++ can
send HTTP messages.
Maybe you could instead send an HTTP message using the standard TCP API (not websocket++) and then give the socket file descriptor you used to send that HTTP message to the WebSocket++ libary and then maybe WebSocket++ could take over that file descriptor and
start sending WebSocket messages. But I don't recall seeing a way to do this in the WebSocket++ documentation. I think it would be possible if you write your own transport for WebSocket++ and there are some examples of alternate transports in the WebSocket++
release, but I think that would be difficult.