I notice an instant messenger using javascript/http/xmlhttprequest rather than tcp/websocket to communicate.
such as http://w.qq.com/login.html
I monitored its communication way in chrome developer tool.
All are http requests. One request to server every minute.
The thing I confused is that if I send a message to the http client, it receives the message immediately.
As I know http client can not get message from others, it has to send request and get response.
Is there any way to make http client to get message from others without using tcp/socket or sending request and geting response?
Your comment welcome
I don't get all this asian hieroglyphs, but they probably use long-polling: client asks server for new data and server holds answer (don't send anything, and don't close connection) while data is not ready (new message came) or until huge timeout expired. As soon as connection closed, client process response and sends next long poll request. The more common term for "permanent" connect via http called Comet. As you can see, Comet can be implemented via many techniques. As for me, the most modern is ajax streaming. It requires modern browser of course, but worth it. It's not so hard to implement streaming by yourself, but I believe there are few js libs which do the job for you.
Upd:
Here is pretty good explanation with code source
and
here is one of many questions about streaming on SO (the answer in the bottom is most interesting I guess)
Related
I've seen how to make a post request from JavaScript to get data from the server, but how would I do this flipped. I want to trigger a function in the flask server that will then dynamically update the variable on the JavaScript side to display. Is there a way of doing this in a efficient manner that does not involve a periodic iteration. I'm using an api and I only want to the api to be called once to update.
There are three basic options for you:
Polling - With this method, you would periodically send a request to the server (maybe every 5 seconds for example) and ask for an update. The upside is that it is easy to implement. The downside is that many requests will be unnecessary. It sounds like this isn't a great option for you.
Long Polling - This method means you would open a request up with the server and leave the request open for a long period of time. When the server gets new information it will send a response and close the request - after which the client will immediately open up a new "long poll" request. This eliminates some of the unnecessary requests with regular polling, but it is a bit of a hack as HTTP was meant for a reasonably short request response cycle. Some PaaS providers only allow a 30 second window for this to occur for example.
Web Sockets - This is somewhat harder to setup, but ultimately is the best solution for real time server to client (and vice versa) communication. A socket connection is opened between the server and client and data is passed back and forth whenever either party would like to do so. Javascript has full web socket support now and Flask has some extensions that can help you get this working. There are even great third party managed solutions like Pusher.com that can give you a working concept very quickly.
I have a 3rd party service to implement, that provides restful API with long polling... they are serving live events, and displaying it as quick as possible is crucial.
Sadly that service does not provide push notifications, so we need to deal with what we have....
so one of the APIs has a long-polling functionality, so in theory the idea is, I query the API, establish an open channel for 30 seconds and wait for the changes... (and publish the changes on the FE)... and then timeout the connection, establish a new one and repeat the process.
Should be pretty straight forward....
But so far, I couldn't find anything in angular's docs about long polling... the only thing I found was polling in connection with rxJS... so setting an inteval on how often I query the API... (which in my case would be every 30s)... but nothing about on leaving the channel open and listen for the changes...
found this thred:
How to implement http long polling in Angular 2
but it is not talking about this problem.
I don't want to end up querying the API every second.
Any ideas?
I considered implementing signalR (which might not really help here), but it relies on jQuery... which I don't want to add to the bundle unless is 100% necessary!
I think you misunderstood the concept of long-pulling..
Long-pulling where the client polls the server requesting new information. The server holds the request open until new data is available. Once available, the server responds and sends the new information. When the client receives the new information, it immediately sends another request, and the operation is repeated. This effectively emulates a server push feature.
It you want to keep the connection alive you need to use webSoket.
WebSockets provide a persistent connection between a client and server that both parties can use to start sending data at any time. The client establishes a WebSocket connection through a process known as the WebSocket handshake. This process starts with the client sending a regular HTTP request to the server
But I didn't understood from your question why you can't send another fetch request when the long-pulling completes, something like:
myLongPullingFunc(){
this.http.get(longPullingURL)
.subscribe(res=>{
if(sholdFetchData){
useFetchedData(res);
this.myLongPullingFunc();
}else
doSomethingElse()
})
}
You can read more about long-pulling here and on webSokects here
I found an interesting library that allows DOM manipulation from the server, this allows much of the logic to be hidden from the browser, so all the browser gets to see is what happens when you check the box, it does not actually know what to do when you check the box.
Seeing that it responds so quickly, I took a look at the network activity, and found an item with HTTP 101 (switching protocols) and it says the connection is still open.
It seems there is a way in JavaScript to receive streaming data.
How can this be? The code is somewhat large and the googling I did indicated it would be called Comet, but there is much more information about the highly cross-browser "long polling", but that does not seem to be what is happening.
What is a (simple) example for how to achieve fast results like this?
The HTTP/1.1 101 response header is the Websocket protocol handshake.
I have found socket.io to be the best ready rolled library (both client and server), especially when working with JavaScript. Socket.io will drop to flash sockets if possible then last resort long polling in older browsers that do not support Websockets.
Long Polling is a push technology. Before web sockets(HTML 5), the web suffered from class client server problem. The server can not push until client requests. So it was not possible to push data to clients. Long Polling is one of the way to do it.
It works in the simple way. The client would make a request to server, the server if has anything new to server would serve immediately or would wait till new content comes. When ever a new content comes, the server would send the response. On receiving the response, the client would again re-issue a request to the server. There are other ways of implementing Push Technology. Read this : wiki
I've just started learning Node.js and was very interested in its real-time capabilities, especially with Socket.io. Since then, I've written a very basic script to connect to Twitter's streaming server and broadcast tweets to all connected clients.
To build that, I used http.createClient to connect to stream.twitter.com and added in the relevant response and data event handlers. Everything works quite well.
Obviously, Twitter's Streaming API pretty much outputs an infinitely loading webpage and what why using a data event handler works fairly well with it. However, is it possible to make other types of websites 'streamable'?
For example, if a client (browser) updates a website periodically using an XMLHTTPRequest, would it be possible to track the output of those requests using the HTTP API of Node.js? Or similar Node.js extension?
Thanks.
websites do not periodically use XMLHTTPRequest. Clients periodically send XMLHTTPRequests to an URL.
A simple call to http.request(options, callback) with the correct headers should emulate XHR's. Most of these servers will also accept normal POST or GET requests.
If you want node.js to connect to a server and simulate a browser then something like zombie would serve you well. It claims to support XMLHTTPRequest.
The best case for you would be to use web-sockets between your dashboard and node server. This way node will be notified immediately that something has updated at your dashboard ( I am assuming that you can modify your dashboard a bit to accept such connections, won't be difficult as long as you have access).
Then you can use long polling at client-end i.e. send a request to the node server and wait. Node will receive the request and then register an event to it. The moment it receives the updates from dashboard, it'll fire the event which will send the response to all the clients one by one waiting.
I would recommend take a look at http://github.com/andrewdavey/vogue . It does something similar but the functionality is ofcourse different.
I wanted to create a web chat. It was suggested that i use Php Socket Servers. I've made one and they function well with a telnet client.
What i find myself bamboozled by is how to get that data to the client via ajax (no page refreshes).
All I can come up with is calling a php file with ajax, getting the data and updating the page. But that will not work the other way around.
Or am i missing something?
How would you implement a 1 on 1 web chat?
One solution is long-polling. The client will open up an AJAX request to a script that will block and wait for data to come in. If no data comes in within a minute, it will return and the client will reopen the connection. If data comes in, then it will immediately return the data and the client will update its view.
For sending the data, just do a normal AJAX callback.
You've got the idea of client-initiated communication, which is fine for sending things from the client to the server.
As a consequence of the stateless nature of HTTP, there is no way to "push" data, unbidden, to the client.
The way you get around this is by always leaving a connection back to the server open. The request is pending, and when the server has something to say, it responds to the pending request. Whenever this happens, the client creates a new request to leave sitting until the next time server->client communication must happen.
Another way to implement near-real-time communication is through frequent polling. But I don't recommend this approach, really. Especially not for a chat program.