I have re-written this description as the original was not clear at all, I think I can summarize this much easier with:
using node.js, is it possible to update the client side DOM without leaving the original connection open that created the page headed and body, and doing a response.write() with each new update ??
Effectively I am looking to update the page in the browser from node.js after the page has loaded and the connection closed ??
Thanks
The way I see it, this has nothing to do with whether you use node.js or PHP or whatever, if you want to modify the DOM on the client side, after the HTTP request finishes, these are your two options. Either you
use a combination of javascript's setTimeout() and requests to the XHR object to poll a JSON or HTML fragment (I won't go into AJAX polling here), or
use websockets. These are connections that stay open so you can pass messages back and forth while your page is running. Look it up.
Related
I have a C++ project for windows, using MiniBlink as embedded browser. (MiniBlink is a smaller Blink, which is close to chromium). I use this embedded browser to show responsive and nice looking dialogs with Quasar.js (wrapper for vue.js).
Problem:
Mostly a browser is just the passive backend. In my case, both the backend (project with embedded browser) and the frontend (dialog) are active and thus I need some communication. At the moment I use a local server to catch HTTP send from the frontend to the backend.
But is there a way to communicate from the backend to the frontend? At the moment I could only think about catching cookies or using a permanent loop in JS to send http queries to check for a possible response.
And is there no other way to send information to a backend? Everything is local, I dont need nor really want to send it into the network.
Thanks!
Idea 1: Use a local temp file to save on one side and read on other (can be also used both way)
Idea 2 (similar to question author solution): Local server with both side communication (GET/POST request into one side, text/json other way around)
Idea 3: Use launch parameter to pass though data directly into links for example: instead of using browserprocess.exe file.html, use browserprocess.exe file.html#showsomething
There are also other ways which like catching for example: checking window title of process with certain binary name from running tasks by other side; we didin't get good enough info about your background becouse you coud either use it in same process or other process, if thats same process you coud also just directly use variables both ways directly in code of miniblink and do action when they meet if statement
As CertainPerformance added as a comment, WebSockets might be the best way to go.
If one does not like to implement a websocket server, because a http server is already running, long polling requests might be the best workaround to simulate this behaviour.
Long polling: The client sends a request, which stays open as long as possible. If the server needs to communicate, it can use the open request to send its own "request" via response. It is a bit hacky, but essentially the idea behind websockets.
Mozilla has a nice article to help with websockets:
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers
If you (like me) use vuejs or quasar, you might want have a look at vue-native-websocket.
https://github.com/nathantsoi/vue-native-websocket
Good luck
I'm currently experimenting with WebSockets in a bid to reduce / remove the need for constant AJAX requests in a potentially low bandwidth environment. All devices are WebSocket compliant so there's no issue there, and I'm trying to keep it to native PHP WebSockets, no node.js or other frameworks / libraries (Which so far has been fine).
What I'm looking to do is to decide how to go about notifying connected clients about an update to a database by another Client. The use case in question is a person pressing a button on their device, which then alerts that persons manager(s) to that press. So the two options I have though of are as follows:
1. Looping a Database Query (PHP)
My first thought was to insert a query into the WebSocket server that is effectively saying "Has the alert field changed? If so, notify the manager(s)". Whilst this is the most straightforward and sensible approach (That I can think of), it seems wasteful to have a PHP script designed to reduce strain on the server, that is now running a query every second, however, at least this would ensure that when a Database update is detected, the update is sent.
2. Sending a notification from the Client
Another thought I had, was that when the client updates the Database, they could in fact send a WebSocket notification themself. This has the advantage of reducing any intensive and looped queries, but also means that I'd need to have a WebSocket message being sent every time I want to change any data, such as:
$.post("AttemptDatabaseUpdate.php", {Data}).function(Result) // Don't worry about the semantics of this, it's not actual code
{
if(Result == "Successful")
{
SendWebSocketNotification(OtherData);
}
}
Maybe this is the best option, as it is the most efficient, but I worry that there is a chance the connection may drop between updating the Database, and sending the WebSocket notification, which may create a need for a fallback check in the PHP file, much like the one in the first solution, albeit at a longer interval (Say every 30 seconds).
3. MySQL Trigger?
This is purely a guess, but perhaps another option is to create a MySQL trigger, which can somehow notify the server.php file directly? I've no idea how this would work, and would hazard a guess that this may end up with the same or similar Query requirements as solution #1, but it's just a though...
Thank you in advance for your help :)
EDIT: Solution possibility 4
Another thought has just popped into my head in fact, whereby the PHP file used to update the database could in fact have a WebSocket message built into it. So that when the PHP file updates the database, the WebSocket server is notified via PHP, is this possible?
If you use websockets, you should use notifications from client. That's one of their main use cases.
If you're worried about inconsistencies due to connection dropping or something changing in-between, you could implement a system similar to HTTP ETags, where client would send a hash code that you can respond on server side if there is a conflict in updating.
Update: I guess I understood your initial issue a bit wrong. If I understand your use case correctly: you are sending database updates from a client and after that all connected clients need to be updated. In that case, I think server should send the update messages after DB updates have been done, so I agree with solution 4. I am assuming here that your websocket server is the same server running PHP and doing the DB updates.
However, depending on your use case, client should still send a hash value on the next request identifying its "view of the world", so you would not be doing identical updates multiple times if a connection gets broken.
Update 2: so it was now understood that you indeed use a separate, standalone websocket server. Basically you have two different web servers on the server side and are having an issue on how to communicate between the two. This is a real issue, and I'd recommend only using one server at a time - either take a look at using Apache websocket support (experimental and not really recommended) or migrating your php scripts to the websocket instance.
Neither PHP or Apache was really build with websockets in mind. It is quite easy to set up a standalone websocket server using only PHP, but it might not be so easy then to migrate the rest of the PHP stack to it if the code is relying on Apache/web server on. Apache websocket support also is hardly optimal. For a real websocket solution, unfortunately, best practice would be using a technology that is built for it from the ground up.
The better answer is to send notification through Server side when database is updated by PHP script, so that script have to add options of web sockets to directly send notification to all web socket clients registered.
User send content->Php script process content and save data according to true condition->check database is updated by checking return of mysql_query/other alternative->if true than use web-socket and send notification to all users
now this is more easy/handy/bandwidth saver.
This is a followup question to the one here
Here's briefly what I am trying to do. The File server creates a text file to indicate an end of the process. On a webpage on the Web Server, I loop every x seconds and make an ajax request to find out if the test file exists (ajax request to http://fileserver/files/UserFile.txt)
I've tried the following approaches so far:
Trigger a web method from the client side that creates a HttpContext object to verify if the text file exists. But this is too strenous on the server and I started getting all kinds of exceptions in the Event Viewer.
YQL works great but unfortunately it's too slow. The user waits atleast twice the amount of time.
I am looking for a solution that doesn't involve the server side. Somehow, I'd like to use JQuery to verify the existence of a text file on the fileserver.
Any thoughts?
You should be able to use JSONP and JQuery.ajax() to do cross-domain request work. Play with the jsonp and jsonpCallback attributes. Alternatively, you can use JQuery.getJSON().
Serving a single file from the filesystem is the most simple operation a web server can do. If that is already too much, then all other solutions will be worse. Find out why the server takes so long to serve a simple file and fix that.
Note: I'm assuming that the file is small since you say "test file". If it's a big file, the server will actually send it to the client which will need a lot of resources.
What you can try is to add an ASP page to the web site which runs code on the server that checks whether the file is there and just returns a tiny piece of HTML which you can add to the page with jQuery.load().
I may be miles off base here but... could you not create ONE asynchronous (!) Ajax client request with a HUMONGOUS timeout. Fire it, and wait. You would be invoking some server script that checks every so often, in a loop on the server (using sleep in between), whether the file exists. And not replying to the Ajax request until the file finally shows. The server script then replies and exits.
EDIT: Depending on the server-side scripting framework used, you may even get some OS support. You may be able to sleep on a status change in the directory...
In my application, the client is a Javascript set of functions in the browser, and it does some work - for example, playing a clip.
It uses XmlHttpRequest to talk to the server.
However, the server is allowed to abruptly close the connection since there is no other way it seems, to interrupt the client.
Can the client detect, while it is playing the clip, that the connection was closed, and so print a message and erase the page?
Any help appreciated.
thanks,
Anil
If the clip is streamed to the client, you could just stop serving it.
However, it seems like the clip is being downloaded and then played through the browser. In this instance it's probably best to use a watchdog approach as described by CookieOfFortune: Poll the server regularly (once a second or so) and get it to respond with tiny message of confirmation. When the connection is closed, get the server to respond with a negative messgage.
Unfortunately, without using a comet-like system, it's very hard to get the server to 'send' a message indicating session closure.
Bear in mind though, that as soon as the client has downloaded a clip they will be able to play it in full if they want to. Unfortunately there's no way to stop this besides switching to a streaming approach. If securing your content is a priority, I'd suggest making this change.
You can probably poll the XmlHttpRequest object, so just try to send a heartbeat every once in a while to see if the connection is closed. Otherwise, the server would have to send some signal to tell the client it is going to close the connection.
It does seem that the server cannot notify the client that the connection is closed; however the polling method suggested is not as efficient as a notification would have been.
I solved it by specifying that at the NEXT Get request, the client would be told that its session is invalid.
This was implemented by URL rewriting - appending "jsessionid=[id]" on each request sent by the Javascript functions. the servlet stores the current session id.
I am just getting started creating an AJAX application using server side push. I am using Grizzly Comet on Glassfish V2. Almost all the sample applications use IFrames for updating content on the client side. I want to stick to using JavaScript only. Are there any such sample applications (preferably ones that do not use a JavaScript library)?
The point about the push is that the HTTP request never ends. Not all client implementations handle that correctly. As I see it, it's possible to do it with pure javascript in Firefox with its extensive API, but the XMLHTTPRequest object would timeout and would not be able to stream you the content.
IFrame is good, you could also try the object tag if its about standard compliance.
Before XMLHTTPRequest and Ajax had no name, we used to get data from the servers through IFrames.
This is how I figured out how to do a push with just javascript and php.
Have javascript do an initial call and load content into a div.
Then have the javascript call back to the php and have the php sleep until it see there is a new update.
Then send out the data to everyone and call back to php and sleep again.
This allows for long polling and fewer calls back to back. I personally put a time of 5 mins to 30 mins on the php script.