Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm designing a web API that will give an opprtunity for clients(other apps) to push some work request, receive immediately some id of that work request and later receive the result of that work request.
What is the typical approach for such kind of interactions?
As providing the result of work request reminds me server push interaction I thought about SSE(server sent events) and webscoket technologies, inclinig to websockets(as client may use the same connection for all kind of requets and receive all kinds of response). Is it a good choice for my goal? and how this can be scaled?
The question is about whether websocket technology suits for the described approach of api design and if not I'm wondering what is a better approach. Is it a good choice for my goal?
A webSocket connection is very well suited for receiving results back at some indeterminate time in the future and it would be a recommended way to do this.
Other requests from the client to server can either be ajax calls or sent as webSocket messages, mostly depending upon whether there are other reasons to make the requests as ajax calls or not. If you already have an established webSocket connection, then it is a convenient, easy and fast way to communicate with the server.
Taking the individual parts of what you doing:
Pushing some work request (from client to server).
This can be done equally well via Ajax or webSocket. If there was no other reason to have an already established webSocket connection, then this would traditionally be an Ajax call.
receive immediately some id of that work request
This is actually a little easier to do with an Ajax request because Ajax is a request/response protocol so if you send the work request via Ajax, it would be trivial to get the ID back as the response to that Ajax request. You could also do it via webSocket, but webSocket is just a messaging protocol. When sending the work request to the server, you could send it via a webSocket (as mentioned previously). And, the server could then immediately send back the work ID, but the client would have to develop some way to correlate the work ID coming back with the previously sent request since those two messages would not have any natural connection to one another. One way that correlation could be done is to have the client generate a temporary ID or hash value when sending the initial request (it can literally be anything that is unique for that client such as a timestamp) and then the server would send that same temporary ID back when it sends the work ID. All this is trivial with a request/response protocol like HTTP/Ajax.
later receive the result of that work request
HTTP Polling, webSocket or SSE could all be used. Polling is obviously not particularly efficient. I know a webSocket would work perfectly for this and it would provide an open conduit for any other items the server wants to send to the client in a push fashion. SSE can also be used to solve this problem (pushing data to a client) though I don't personally have any experience with it.
Related
Consider we have an HTTP server and there are many concurrent clients making HTTP requests to this server.
The responses are adequately big to be considered.
User may send requests on the trot, with different request bodies. Once a new request has been made, former requests made by same user become obsolete.
In this type of situation, looking from client aspect, that may not be an issue. However, in server-side, it will make considerable amount of CPU time steal. If there is no way to do further processing relied upon former requests that came from same users, what to do? Here are some workarounds I thought:
to make a new HTTP request from client in order to cancel the process in server-side (via different port)
checking client if incoming request is a further request (over IPv4 or MAC address, is there a popular way to conduct this?)
That being said, please let the task being done by server upon HTTP requests is nonatomic (otherwise I think it would be a maze, because as I know a block-closure passed to some dispatch authority will be executed, ultimately).
This was actually a request-response pattern question because it is not limited to use HTTP. Sadly, there was no tag named request-response.
Thank you.
How Facebook, Google plus or other informations web site, constantly retrieves information from the stream?
I suppose there is an asynchronous recovery , but how he gets constantly? It's like an infinite loop?
Which technology is used ?
There are a few different approaches to displaying updates in near-real time on the web. Here are some of the most common ones:
Short polling
The simplest approach to the problem is to continuously poll the server on a short interval (hence the name). This means that every few seconds, client-side code sends an asynchronous request to the server and displays the result. The downside to this approach is that if updates happen less frequently than the server is queried, the client is doing a lot of work for little payoff. There may also be a slight delay between when the event happens on the server and when the client receives it, based on the polling frequency.
Long polling
The next evolutionary step from short polling is what's known as long polling, where the client-side JavaScript fires off an asynchronous request to the server as soon as the page loads. The server only responds to the request when an update is made, and once the response reaches the client, another request is fired off immediately. The key part of this approach is that the asynchronous request can wait for the server for a long time.
Long polling saves bandwidth and computation time, since the response is only handled when the server has something that changed. It does require more complex server-side logic, but it does allow for near-instant updates on the client side.
This question has a decent sample: How do I implement basic "Long Polling"?
WebSockets
WebSockets are a relatively new technology, and allow for two-way communication in a way that's similar to standard network sockets. The server or client can send messages across the socket that trigger events on the other side of the connection. As nice as this is, browser support isn't as widespread enough to make it a dependable solution.
For the current WebSocket specification, take a look at RFC 6455.
Can anyone let me know how SignalR works internally in a high level way?
I am guessing it is flushing the data using Response.Flush and at client side it is sending Ajax requests at certain intervals. Is it correct?
No, SignalR is an abstraction over a connection. It gives you two programming models over that connection (hubs and persistent connections). SignalR has a concept of transports, each transport decides how data is sent/received and how it connects and disconnects.
SignalR has a few built in transports:
WebSockets
Server Sent Events
Forever Frame
Long polling
SignalR tries to choose the "best" connection supported by server and client (you can also force it to use a specific transport).
That's the high level. If you want to see how each transport is implemented, you can look at the source code.
There's also client code for each transport:
https://github.com/SignalR/SignalR/tree/master/src/Microsoft.AspNet.SignalR.Client.JS
If you're asking about how the long polling transport works in particular:
It sends an ajax request to the server that's waiting asynchronously for a signal to respond. When there is a signal or the request times out, it returns from the server and sends another request and the process continues. (I left some details out about how the client it keeps track of what it saw so it doesn't miss messages)
Hopefully that answers most of your question.
#davidfowl has already answered the major portion. However, to provide some more details regarding the difference in behavior of transports, specifically between WebSocket and other transports; below are some points.
WebSocket is the only transport that establishes a true persistent, two-way connection between client and server. However, WebSocket is supported only by IIS 8 or above, and the latest versions of Internet Explorer, Google Chrome and Mozilla Firefox.
While Server Sent Events, Forever Frame and Long polling, all three follow a one-way communication, and are supported by most of the browsers.
I have a desktop client application that is talking to a server application through a REST API using simple HTTP posts. I currently have the client polling every X minutes, but I would like the data to be refreshed more frequently. Is it possible to have the server notify the client of any new data, or is that outside the scope of what an HTTP server is meant to do? Any thoughts on the best way to approach this would be much appreciated. Thanks!
You may want to check the accepted answer to the following Stack Overflow post, which describes with a very basic example how to implement Long Polling using php on the server-side:
Simple “Long Polling” example code
When using Long Polling, your client application starts a request to the HTTP server, with an infinite timeout (or a very long one). Now as soon as new data is available, the server will find an active connection ready, so it can push the data immediately. In traditional polling, you would have to wait until the application initiates a new poll, plus the network latency to reach the server before new data is sent.
Then when the data is sent, the connection is closed, but your application should open a new one immediately in order to have a constantly open connection to the server. Actually there will be a very small gap where there will not be an active connection, but this is often negligible in many applications.
If you hold the HTTP connection open on the server side then you can send data whenever there's an update, followed by flushing the connection to actually send the data. This may cause issues with the TCP/IP stack if tens of thousands of connections are required though.
I have created a simple chat server that is driven by client polling. Clients send requests for data every few seconds, and get handed any new messages as well as information about whether their peer is still connected.
Since the client is running on a mobile platform (iPhone), I've been looking for ways of getting rid of the polling, which quickly drains the battery. I've read that it's possible to keep an http connection open indefinitely, but haven't understood how to utilize this technique in practice. I'm also wondering whether such connections are stable enough to use in a mobile setting.
The ideal scenario would be that the server only sends data to clients when an event that affects them has occurred (such as a peer posting a message or going off line).
Is it advisable to try to accomplish this over http, or would I have to write my own protocol over tcp? How hard would it be to customize xmpp to my need (my chat server has some specialized features that I would have to easily implement).
How about push technology? see http://en.wikipedia.org/wiki/Comet_(programming)
I think you're describing XMPP over BOSH.
http://xmpp.org/extensions/xep-0206.html
I've used this http-binding method between a chat server and javascript client on non-mobile devices. It worked well for me.
You might like to check out this project which uses a variety of techniques including Comet. Release details are here, here's a snippet from that page
It’s my distinct pleasure to be able
to announce the first public showing
of a project that I’ve been working on
in my spare time in the last month or
two, a new Web Based IRC chat
application.
This project brings together a lot of
new technologies which had to be
developed to make this a feasible,
scalable and efficient.
Some of the underlying tools build to
make this posible that i consider
’stable enough’ are already released,
such as the php Socket Daemon library
i wrote to be able to deal with
hundreds up to many thousands of
“Comet” http connections, and an equal
amount of IRC client connections.
I just found this article myself, which describes the following technique (which I referred to in the question):
... have the client make an HTTP request
and have the server hold the request
on the queue until there is a message
to push. if the TCP/IP connection is
lost or times-out, the client will
make a new HTTP request, and the delay
will only be the round trip time for a
request/response pair . . . this model
effectively requires two TCP/IP
connections for HTTP, client to
server, though none permanent and
hence mobile friendly
I think this is nearly impossible and dangerous. The internet works stateless and connectionless meaning that the connection between client and server is always handled as unreliable. And this is not for fun.
By trying to get a stateful connection you are introducing new issues. Especially from a 3g application. What if the connection breaks? You have no control over the server and cannot push.
I think it would even be easier to send sms/text messages and have an application that handles that.