I'm trying to use them for the first time and wonder I'm headed to the right direction.
Here are my understandings,
socket.io is a wrapper around websocket, and falls back to sub-optimal solutions when websocket is not available.
Django channels can talk websocket as well.
(I think it converts django as a message queue like system. although this understanding or misunderstanding should affect this question)
So I'm trying to use Django channels on the server and socket.io-client on the client.
socket.io has api which looks like
socket.on(type, (payload)=> {})
Whereas Django channels has a form of
message.reply_channel.send({
"text": json
})
is the "text" type of socket.on(type)?
Can Django channels and socket.io-client talk to each other?
From the Socket.IO README:
Note: Socket.IO is not a WebSocket implementation. Although Socket.IO indeed uses WebSocket as a transport when possible, it adds some metadata to each packet: the packet type, the namespace and the ack id when a message acknowledgement is needed. That is why a WebSocket client will not be able to successfully connect to a Socket.IO server, and a Socket.IO client will not be able to connect to a WebSocket server (like ws://echo.websocket.org) either. Please see the protocol specification here.
So, you shouldn't expect Channels to work directly with Socket.IO. Global browser support for websockets is at 93%, which is probably high enough to just use the websocket API directly.
To quote the creator of django channels: https://github.com/django/channels/issues/1038
Channels doesn't support socket.io - it's a different protocol that isn't websockets or HTTP but layers on top of them. You'll have to use a socket.io server if you want to use it.
Related
I will be happy to get advice from more experienced developers about adding Web Sockets into my HTTP-based project.
That’s the thing. I have developed the REST API based service. Everything works well enough, but… In some special cases my server needs a long time to serve client requests. It may be from 1 minute to several hours (and even days)! I implement some not-so-good algorithm to address this issue:
Client sends HTTP request
Server replies about registering request
Client starts sending HTTP requests to get necessary data (if response does not have needed information the client sends another request and so on)
That is all in a nutshell.
And it seems to be a bad scenario and I am trying to integrate web sockets for adding duplex-channels in this architecture. I hope that my API will be able to send info about updated data as soon as possible without the necessity of many requests from the client.
But I am a bit confused in choosing one of two ways to use web socket (WS).
Variant A.
The server only tells the client via WS that data is ready. And the client gets data by standard request-response HTTP method from REST API.
Variant B.
The server sends all data to the client via WS without HTTP at all.
What variant is more suitable? Or maybe some other variants?
I do not want to remove HTTP at all. I just try to implement WS for a particular kind of end-points.
Variant A would be more suitable and easy to implement. You can send message to the client after the data is ready, and he can then send request for the data. It will be like a simple chat websocket, and will serve your purpose.
I am trying to use libvnc to write client application for VMware ESXi 6 vm's consoles.
From ESXi 6 VMware provides websocket for this purpose. They are also released basic HTML5 client for this.
ESXi websocket VNC uses connection path to authorize.
When HTML5 client trying to connect it making request like this:
wss://esxi_host_ip/ticket/secret_token
From my research I know that this method also works with noVNC Client
(https://github.com/kanaka/noVNC)
This client passes "path" parameter to RFB implementation.
From libvnc website I know that it support websockets but I don't know if it is supported on client side and if the answer is YES, how can I do that ?
Finally the answer is NO but simple hack is possible.
Connection to websocket vnc server from libvnc is not directly possible.
As solution for my problem I used custom made tcp to websocket proxy where I firstly negotiating websocket connection and then connecting standard tcp vnc client.
Is it possible with Qt to upgrade a HTTP connection that handles the normal HTTP requests to a Websocket with the same connection?
I'm thinking about something like this with Poco libraries, but all done in Qt similar to QtWebApp.
The simple answer is no and that is mostly because of specifics of the server side. And Qt just follows the protocol available and exposed by the server (HTTP/WebSocket) as mostly the client-side development framework and AFAIK won't be able to do the kind of transformation you want of going from HTTP to Websocket that are two different protocols. But of course, theoretically that can be done as long as both protocols able to use IP port 80. But that implies new unique sever and new unique client implementations.
We use both WebSocket and REST in our app. And WebSocket is for triggering the client by the server to do something. Client gets the "poke" from the server and starts normal JSON HTTP-based exchange with the server.
Somewhat relative link: https://softwareengineering.stackexchange.com/questions/276253/mixing-rest-and-websocket-in-the-same-api
I'm developing an iOS app that requires realtime dual-way server/client messaging.
I'm trying to use WebSocket++ to develop a WebSocket server app on an AWS EC2. Have to use C++ because that's the only language I know on the server side.
The problem is I'm a fresh guy on server side development. I have 2 very basic questions:
1, Do I need have to setup an HTTP server like apache/nginx in order to get websocket running?
That is, can websocket app live independently alone?
2, I have now setup an nginx server in case it is a must have, is there any resource that I can refer to to make nginx & websocket work together well?
No, you don't need a Web server, a (reverse) Web proxy or anything to have your C++ WebSocket server talk to WebSocket clients.
Nginx (as HAproxy) supports reverse proxying WebSocket. This can make sense in certain situations, like you want to terminate TLS at the proxy and forward plain WebSocket to your backend server, or you want to load-balance incoming WebSocket connections to multiple backend nodes. However, as said, this isn't required.
No you don't, websocket and socket for an HTTP server are two diffent things.
HTTP server is for the HTTP protocol while there is not protocol defined for websocket, you have to define it yourself typically by the mean of sending/receiving Json message (a stream of character which each side (the server and the client) knows how to read/write).
The goal of websocket is to offer to javascript through HTML5 an easy, light and quick way to communicate through a socket, without websocket you have to do that with web services and in that case you need a http server.
With websocket you can create an html file leveraging html tag and javascript, javascript use client side of websocket to communicate with a C++/websocket server program, and you do not need even a web server, in this scenario you have a "desktop web app" ! (here web term is only because you use html tags)
Same question, same answer, no again ;-)
Good luck, and welcome in the wonderful world of asio !
I have a mini computer that does not support websockets that I would like to receive push notifications from a server.
The issue is that after the client connects to the server, the server responds and then closes the connection. This makes it so the client has to continually reconnect to the server to get new information.
Is there a way using Django to allow the connection to be left open and then have the server publish data to the client?
Django is primarily a request/response framework and as such does not have support for real duplex communication.
Socket.IO is the de facto library that makes websocket-like functionality cross-browser (IE5.5+), using real websockets as a transport if the browser allows it, falling back to HTTP long-polling or whatever else if it doesn't. For various options on integrating Socket.IO with Django, read this.