Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 13 days ago.
Improve this question
I have a react web app which generates solutions for rubik's cubes. When the user makes a query on my site, it starts a long computation process (anywhere from 1 second - 240 seconds). Every time a solution is found, the state is changed and the user can see the new solution.
However, this app often crashes on mobile for large queries, I believe the browser is demanding too much memory and kills my page. Because of this, I want to add a node.js backend to handle the computation.
I would like for the following functionality:
When the user makes a query request, it sends that to the backend which can start computing. Every so often, the frontend can update to show the current tally of solutions.
If the user prematurely wants to cancel the process, they can do so, also killing the backend thread.
How can I set this up? I know I can very easily make HTTP requests to my backend and receive a response when it is done. However, I'm not sure how to accomplish the dynamic updating as well as how to cancel a running thread. I have heard of long polling but I'm not sure if this is the right tool for the job, or if there is a better method.
I would also like this app to support multiple people trying to use it at the same time, and I'm not sure if I need to consider that in the equation as well.
Any help is appreciated!
However, I'm not sure how to accomplish the dynamic updating. I have heard of long polling but I'm not sure if this is the right tool for the job, or if there is a better method.
Three main options:
A webSocket or socket.io connection from client to server and the server can then send updates.
Server-sent events (SSE is another way for the server to send updates to the client)
Client polls the http server on some time interval to get a regular progress report.
as well as how to cancel a running thread
If by "thread" here, you mean a WorkerThread in nodejs, then there are a couple of options:
From your main nodejs process, you can send the thread a message tell it to exit. You would have to program whatever processing you're doing in the thread to be able to respond to incoming messagessto that it will receive that message from the parent and be able to act on it. A solution like this allows for an orderly shut-down by the thread (it can release any resources it may have opened).
You can call worker.terminate() from the parent to proactively just kill the thread.
Either of these options can be triggered by the client sending a particular http request to your server that identifies some sort of ID so the server's main thread can tell which workerThread it should stop.
I would also like this app to support multiple people trying to use it at the same time, and I'm not sure if I need to consider that in the equation as well.
This means you'll have to program your nodejs server such that each one of these client/thread combinations has some sort of ID such that you can associate one with the other and can have more than one pair in operation at once.
Related
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 2 years ago.
Improve this question
This question is more about looking for an idea, rather than an implementation or technical solution. I'd like to hear how you would solve this kind of problem (or task).
I have an application build with Javascript using React & Meteor. At the moment every time a client does something there is a Meteor Call to our server which will write Data to MongoDB and every other client will notice this change (and will respond in some way). This is working fine atm.
Now i want to add a new feature which allows two clients to communicate with each other (LAN only - atleast in the first version). So as an example: I have a room with 4 clients - A, B, C and D and i want to match two of them, e.g. A & C. This connection should only exists between those two clients and i want to minimize traffic to my server and meteor calls. (My server should not be involved in this communication at all, besides maybe saving some data every few minutes, but all in all it should work without my server) and it should be possible to open up more than one communication, if A & C are working together B & D should be able to do the same, the data which is transmitted - at this time - is JSON.
Further thoughts: A presses a Button in my webapplication which is a React Component. The React Component than establishes a connection to another person who is also looking for a partner (in the case above C) - Some sort of document/page opens up and both can work on the same document in real time or near real time. In worst case: The communication should be able to work without a connection to my Server (or Internet connection in general), but it doesn't have to.
I first thought about using sockets (SocketIO or something along that line), e.g. A creates a server when he wants to work with C and C connects to A, but this comes with some problems in JS
and i am not sure if its really a good way to approach this.
I'd like to hear some other ideas, perhaps im running in a completely wrong direction.
Use the WebRTC API.
Although often associated with real time audio/video communication, it can also be used for peer-to-peer communication with arbitrary data.
As far as I know this is, as of this writing, the only client-side web-native peer-to-peer API available which is widely implemented by major browser vendors.
This question already has answers here:
Is there a real server push over http?
(7 answers)
Closed 3 years ago.
I am currently making a simple clock in and out system for staff. The warehouse has a TV with a list of names on the right of people who have not signed in, and a list of names on the left of those who are signed in. When they clock in on the scanning device downstairs I need the TV/dashboard upstairs to update and move their name onto the appropriate side.
I have made the function that logs the details into the database. And I know I could use code such:
<meta http-equiv="refresh" content="3;url=thecurrentpagesurl" />
And doing that would refresh the page run a function that checks for changes and updates the display accordingly, however I was wondering if there was a way of "listening" for a change without having to spam the server to often. Ideally I want the dashboard to update in real time.
Using meta refresh I can refresh the page use a function to check for db changes and update the html on the dashboard accordingly. Is there a less resource intensive or more efficient way of doing this?
(I'm not a JavaScript expert but I have enough understanding to use some at a basic level).
Edit
This question has asked before and I have looked at the other answers which is why I came to the conclusion about the meta refresh aspect, but what I wanted to know if there was a more efficient way of doing it given my specific set up.
In your described environment your current approach is not bad.
Here are some ideas/options on which you can read up and improve your application if needed:
Use Ajax and just refresh the content of your lists. You can combine this with neat animations. But this is still not real-time. This is especially easy when using jQuery or similar libraries.
You could use Ajax with longpolling, This means that the Ajax-Request will be hold open on the server-side until any change is happening (or a possible timeout). When a request got an response just open another ajax request with longpolling and wait for more changes. This is not realtime, but it gets really close to it. In some environments this can stress the server since each open request will occupy resources or block sockets/threads etc.
Another more modern version is to use the Websockets. This is the most complex approach, but the communication is in realtime. The Browser-view and Server are establishing a tcp connection and keeping that open to communicate over it. There are also some good open-source libraries for Websockets.
In your described situation i would go with your current solution and also take look into the first two ideas. They are not that complex and can give the feel of "realtime" updates.
I decided to run the refresh at set times, so what I did was use php date function to calculate the time, if the time is between 7-9 (the earliest staff clock in) or 5-7 (the latest anyone clocks out) it will run the meta refresh that way it doesnt check all day while everyones at work singed in. Thanks again !
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 8 years ago.
Improve this question
This came up during a discussion on another spine.js question:
Since, this is significantly distinct from that question, I am upholding the "one question per post" policy of SO, by branching this off as a new question.
#numbers1311407 mentioned that
spinejs will queue the requests and submit them serially, each consecutive request being made only after its predecessor completes.
But that seems so wrong ! Why should Spine assume so much control and sequentialize all POSTS (for example) from a client ? What if the POSTS are on related URIs ? Even if Spine tries achieve some sanity by sequentializing all POSTs for each client, it still has no way of preventing concurrent and conflicting POSTS happening from different clients. So, why bother ?
But that seems so wrong !
It makes sense when you consider the design goal of spine, the realization of what MacCaw calls an "Asynchronous UI" (the title of the blog post you linked to in your related question). This paradigm attempts to eliminate all traces of the traditional request/response pattern from the user experience. No more "loading" graphics; instantly responsive user interaction.
This paradigm expects a different approach to development. Persisting to the server becomes more of a background thread that, under normal circumstances, should never fail.
This means that under normal circumstances your app logic should not be dependent on, or care about, the order or scheduling of requests by spine.
If your app is highly dependent on server responses, then spine might be the wrong library.
Why should Spine assume so much control and sequentialize all POSTS (for example) from a client ?
Because of spine's non-blocking design philosophy, your app relinquishes the flow control that you might have in another lib like Backbone, wherein you might do something like disable a "submit" button while a request is being made, or otherwise prevent users from spamming the server with non-idempotent requests.
Spine's Model#save, for example, returns immediately and as far as the client is concerned, has already happened before the server even gets the request. This means that spinejs needs to collect and handle requests in the order that they come to ensure that they are handled properly. Consider a user jamming on a "Save" button for a new record. The first click will send a POST, the second, a PUT. But the button spamming user does not know or care about this. Spine needs to ensure that the POST completes successfully before the PUT is sent, or there will be problems in the client.
Combine the order sensitivity of non-blocking UI input with the first point, that your app shouldn't concern itself overmuch with the persistence layer, and you can begin to see why spinejs serializes requests.
Even if Spine tries achieve some sanity by sequentializing all POSTs for each client, it still has no way of preventing concurrent and conflicting POSTS happening from different clients. So, why bother ?
Because the point of the solution is to give a consistent, somewhat user-error-proof UI experience to a single client. E.g. if a client creates, then updates, then deletes a record, spine should ensure that all these requests make it to the server successfully and in the proper order. Handling conflicting posts between clients is a separate issue, and not the point of the request queue.
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 2 years ago.
Improve this question
I am running some tests with WebSockets.
For the test I used the Alchemy-Websockets .NET based server.
The web application open several windows and it used to monitor different services and systems.
I am especially interested in high load situation where the server has to sends a lot
of events to the client, to reflect real time updates. I want the GUI to be fully responsive and present the data in a grid and a chart in a real time user experience.
I created the WebSocket in the main window thread, and on every incoming message I added an entry to an array that the grid is using to display (SlickGrid). To make the GUI work fine I added an setInterval of 20ms to render the grid updates, everything is working fine, very fast.
The question is whether moving the WebSocket to a worker thread is desirable or recommended. Reading about Worker threads I saw in the use cases a recommendation to handle I/O in a thread.
I think this make sense only if it is blocking.
As far as I know WebSocket is asynchronous and does not block. I read somewhere that
it is implemented in a thread internally by the browser, which makes sense.
I consider moving the WebSocket into a worker, allowing the worker to buffer or aggregate some data before moving it to the main window, In case of high event rate I see the following approaches:
The main window thread polls the worker periodically (every 20ms or so) and get the required data.
The worker sends larger chunks of data periodically.
Every time the web socket receive data, send it to the main thread - but I think it introduce the same inherent problems. (This is where I began testing, I created an infinite loop in a worker thread
and on every step I sent a message to the main thread, the GUI froze
which makes sense).
Leaving the WebSocket on the main thread is also not ideal. In case of a high load from the server, the GUI will not prioritize the WebSocket incoming message events.
Gathering data in the worker thread, seems I might miss the real time updates during high loads, since the worker is buffering.
Another issue with worker threads seem to be the data duplication, which can be solved by the newer transferable objects, not sure how well it is supported on all browsers yet.
Why not hosting the WebSocket on the main window?
So what is the best practice?
There are only two reasons to move WebSocket to Worker.
JSON.parse is blocking operation and can cause FPS loss in case of big data. Data cloning from worker adds ~1% overhead, but 99% of parsing is done in background thread.
Using SharedWorker to maintain only one connection with server.
DOM manipulation and probably drawing on canvas affects websocket packages too. I measure around 0.2ms average latency on localhost, but using the same thread I have 4-9ms spikes in regular intervals. If I don't update the DOM that frequent or move the websocket to a worker they disappear. Chrome is affected the most, Firefox is better from this perspective currently. For online gaming this can mean some sort of lag or stuttering. For me it just affects TCP latency testing somewhat. I need to increase the message sending frequency from 1ms to 100ms to get a clean chart.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am looking for real-world scenarious for using Web Workers API.
John Resig (of jQuery fame) has a bunch of interesting examples of using web workers here - games, graphics, crypto.
Another use is Web I/O - in other words, polling URLs in background. That way you don't block the UI waiting for polling results.
Another practical use: in Bespin, they’re using Web Workers to do the syntax highlighting, which you wouldn’t want to block your code editing whilst you’re using the app.
From Mozilla: One way workers are useful is to allow your code to perform processor-intensive calculations without blocking the user interface thread.
As a practical example, think of an app which has a large table of #s (this is real world, BTW - taken from an app I programmed ~2 years ago). You can change one # in a table via input field and a bunch of other numbers in different columns get re-computed in a fairly intensive process.
The old workflow was: Change the #. Go get coffee while JavaScript crunches through changes to other numbers and the web page is unresponsive for 3 minutes - after I optimized it to hell and back. Get Back with coffee. Change a second #. Repeat many times. Click SAVE button.
The new workflow with the workers could be: Change the #. Get a status message that something is being recomputed but you can change other #s. Change more #s. When done changing, wait till status changes to "all calculations complete, you can now review the final #s and save".
I have used them for sending larger amounts of data from the browser to server. Obviously, you can do this with regular AJAX calls, but if this takes up one of the precious connections per hostname. Also, if the user does a page transition during this process (e.g clicks a link), your JavaScript objects from the previous page go away and you can't process callbacks. When a web worker is used, this activity happens out of band, so you have a better guarantee that it will complete.
Another Use case:
Compressing/De-compressing files in the background, if you have a lot of images and other media files that are exchanged from the server in compressed format.