How to communicate both ways between embedded browser and webside - javascript

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

Related

Is there any way to send http requests from JS by pushing button, to a C++

I am currently designing a GUI for a piece of hardware. We want the GUI to be able to be accessed over a browser. The browser would be displaying a map generated from C++ code, but I also need to send some params to the code that generates the map from buttons on the JS front end? Is there anyway to accomplish this. I have done a little research so far and know about web sockets and AJAX, but I am not entirely sure it is what I am looking for. In an ideal world I would be able to just send UDP packets, but my research tells me that is not possible, not is TCP. Is this correct?
Thank's in advance for any help!
Your C++ code could setup a server that listens for requests. You could use libhttpserver, for example. Then, in your JavaScript code, you can use XMLHttpRequest or the Fetch API (for newer browsers) to make an HTTP request to the server, which would then return a new static page (with the generated map embedded into the page).

Need multiple push from server using same connection

I am trying to implement a simple UI which shall be showing the logs written in my server console. Have searched but couldn't find a solution which satisfies my requirement.
As per my design, I have a java program using Apache common-io api for tailing log file. It helps me to reduce memory overhead, I do not want to keep large chunks in memory.
So when client makes a request, server shall start reading file and send the read data incrementally and shall keep showing until client stops receiving. I do not wish to send multiple request because that would make application read file again and again adding to which I would need to maintain a state/offset (possible solution but avoiding it).
I tried to check for JAX-RS using Asynchronous Response but that doesn't seem to help. I am not sure if HTTP/2 is gonna help.
Please help me understand how this can be achieved, and if I would need to implement socket programming at client and server side or if there is any such protocol which can be used. I am open to modify tech stack.
Thanks
You can use any protocol that supports long lasting streaming connections (which there are many).
If you're already using JAX-RS, then StreamingOutput might be what you want.
After bit of more searching I finally found a bunch of ways of achieving what I mentioned. Before I would like to explain how it cannot be achieved using HTTP (Rest specifically).
HTTP Way: There are few ways in HTTP and/or HTTP2 where you can create a long lasting connection using long-polling in both versions or using multiplexing property present in http2. In both cases the underlying protocol in TCP so there not much difference. However, in HTTP/HTTP2 transactions occur in a fashion where once server receives a request and sends response back, it doesn't expect client to receive response again neither client expects to receive one. So one complete cycle includes a pair of request and response. Hence, if you try to send another response you cannot do that because neither client nor server would be able to receive or send that respectively. There are many resources in Google for more in-depth information.This has a good explanation and references
So I tried to check if I can use some socket coding in order to keep the connection alive and transmit data. Luckily I stumbled upon another way to achieve that.
Two of which I felt make more sense for my requirement are as follows. I would not try to explain them just to avoid providing wrong information here since I myself am trying to get more insight.
1. Server-Side Events(SSE)
2. WebSockets
This will give a fare idea about them.

Javascript send string to console application

I want to execute some javascript that will send a string of text to a c++/java console application running on the same machine as the web browser
What javascript should I execute? and how should I receive the string?
As far as I know, there are two ways to transmit data to somewhere else using JavaScript. The first is using an XMLHttpRequest, the second is using a WebSocket. In both cases, the JavaScript code will establish a connection to another program, which in this case you want to be your C++/Java program.
In the first case, if you want to communicate using an XMLHttpRequest (or other libraries that use this, such as jQuery's get or post), you'd need to make sure that your C++/Java application starts a small webserver. This way, the JavaScript code can establish a connection to it and send data. I'm sure there are C++/Java libraries which you can use for this, but even if you can't it should be fairly simple to get something to work with just plain socket code. The text-based HTTP protocol that you need for this is not that difficult.
In the second case, you'd need to make sure that a WebSocket server is started in your C++/Java application. Your JavaScript code then can connect to this server and just send its data. I'm not that familiar with the WebSocket protocol but I suspect that it's slightly less trivial, so using a library for this would be a good choice.

Call ajax when value is inserted on database [duplicate]

Of course I am aware of Ajax, but the problem with Ajax is that the browser should poll the server frequently to find whether there is new data. This increases server load.
Is there any better method (even using Ajax) other than polling the server frequently?
Yes, what you're looking for is COMET http://en.wikipedia.org/wiki/Comet_(programming). Other good Google terms to search for are AJAX-push and reverse-ajax.
Yes, it's called Reverse Ajax or Comet. Comet is basically an umbrella term for different ways of opening long-lived HTTP requests in order to push data in real-time to a web browser. I'd recommend StreamHub Push Server, they have some cool demos and it's much easier to get started with than any of the other servers. Check out the Getting Started with Comet and StreamHub Tutorial for a quick intro. You can use the Community Edition which is available to download for free but is limited to 20 concurrent users. The commercial version is well worth it for the support alone plus you get SSL and Desktop .NET & Java client adapters. Help is available via the Google Group, there's a good bunch of tutorials on the net and there's a GWT Comet adapter too.
Nowadays you should use WebSockets.
This is 2011 standard that allows to initiate connections with HTTP and then upgrade them to two-directional client-server message-based communication.
You can easily initiate the connection from javascript:
var ws = new WebSocket("ws://your.domain.com/somePathIfYouNeed?args=any");
ws.onmessage = function (evt)
{
var message = evt.data;
//decode message (with JSON or something) and do the needed
};
The sever-side handling depend on your tenchnology stack.
Look into Comet (a spoof on the fact that Ajax is a cleaning agent and so is Comet) which is basically "reverse Ajax." Be aware that this requires a long-lived server connection for each user to receive notifications so be aware of the performance implications when writing your app.
http://en.wikipedia.org/wiki/Comet_(programming)
Comet is definitely what you want. Depending on your language/framework requirements, there are different server libraries available. For example, WebSync is an IIS-integrated comet server for ASP.NET/C#/IIS developers, and there are a bunch of other standalone servers as well if you need tighter integration with other languages.
I would strongly suggest to invest some time on Comet, but I dont know an actual implementation or library you could use.
For an sort of "callcenter control panel" of a web app that involved updating agent and call-queue status for a live Callcenter we developed an in-house solution that works, but is far away from a library you could use.
What we did was to implement a small service on the server that talks to the phone-system, waits for new events and maintains a photograph of the situation. This service provides a small webserver.
Our web-clients connects over HTTP to this webserver and ask for the last photo (coded in XML), displays it and then goes again, asking for the new photo. The webserver at this point can:
Return the new photo, if there is one
Block the client for some seconds (30 in our setup) waiting for some event to ocurr and change the photograph. If no event was generated at that point, it returns the same photo, only to allow the connection to stay alive and not timeout the client.
This way, when clients polls, it get a response in 0 to 30 seconds max. If a new event was already generated it gets it immediately), otherwise it blocks until new event is generated.
It's basically polling, but it somewhat smart polling to not overheat the webserver. If Comet is not your answer, I'm sure this could be implemented using the same idea but using more extensively AJAX or coding in JSON for better results. This was designed pre-AJAX era, so there are lots of room for improvement.
If someone can provide a actual lightweight implementation of this, great!
An interesting alternative to Comet is to use sockets in Flash.
Yet another, standard, way is SSE (Server-Sent Events, also known as EventSource, after the JavaScript object).
Comet was actually coined by Alex Russell from Dojo Toolkit ( http://www.dojotoolkit.org ). Here is a link to more infomration http://cometdproject.dojotoolkit.org/
There are other methods. Not sure if they are "better" in your situation. You could have a Java applet that connects to the server on page load and waits for stuff to be sent by the server. It would be a quite a bit slower on start-up, but would allow the browser to receive data from the server on an infrequent basis, without polling.
You can use a Flash/Flex application on the client with BlazeDS or LiveCycle on the server side. Data can be pushed to the client using an RTMP connection. Be aware that RTMP uses a non standard port. But you can easily fall back to polling if the port is blocked.
It's possible to achive what you're aiming at through the use of persistent http connections.
Check out the Comet article over at wikipedia, that's a good place to start.
You're not providing much info but if you're looking at building some kind of event-driven site (a'la digg spy) or something along the lines of that you'll probably be looking at implementing a hidden IFRAME that connects to a url where the connection never closes and then you'll push script-tags from the server to the client in order to perform the updates.
Might be worth checking out Meteor Server which is a web server designed for COMET. Nice demo and it also is used by twitterfall.
Once a connection is opened to the server it can be kept open and the server can Push content a long while ago I did with using multipart/x-mixed-replace but this didn't work in IE.
I think you can do clever stuff with polling that makes it work more like push by not sending content unchanged headers but leaving the connection open but I've never done this.
You could try out our Comet Component - though it's extremely experimental...!
please check this library https://github.com/SignalR/SignalR to know how to push data to clients dynamically as it becomes available
You can also look into Java Pushlets if you are using jsp pages.
Might want to look at ReverseHTTP also.

Suppressing browser's authentication dialog

I apologize that there is a similar question already but I'd like to ask it more broadly.
Is there any way at all to determine on the client side of a web application if requesting a resource will return a 401 status code and cause the browser to display an ugly authentication dialog?
Or, is there any way at all to load an mp3 audio resource in flash which fails invisibly in the case of a 401 status code rather than letting the browser show an ugly dialog?
The Adobe Air run-time will suppress the authentication if I set the "authenticate" property of the URLRequest object but this property is not in the Flash run-time. Any solution which works on the client will do. An XMLHttpRequest is not likely to work as the resources in questions will be at different domains.
It is important to fail invisibly because the application will have a list of many audio resources to try and it makes no sense to bother the user to try and authenticate for one when there are many others available. It is important that the solution work on the client because the mp3's in question come from various servers outside my control.
I'm having the same problem with the twitter api - any protected user requires the client to authenticate.
The only solution that I could come up with was to load the pages serverside and return a list of the urls with their http response code.
"Is there any way at all to determine on the client side of a web application if requesting a resource will return a 401 status code and cause the browser to display an ugly authentication dialog?"
No, not in general. The 401 response is the only standard way for the server to indicate that authentication is necessary.
Just wrap your access to the resource that might potentially require authentication to an Ajax call. You can catch the response code, and use javascript to do whatever you want (ie. play that sound). If the response code is however alright, then use javascript to forward user to the resource.
Most likely this approach will generate slightly more load on server (you might have to resort to loading the same resource several times in some circumstances), but it should work. Any good tutorial about how to use XMLHttpRequest should contain all you need. Take a look at for instance http://www.xul.fr/en-xml-ajax.html
If you are using URLRequest to get the files, then you are running across more than just elegant error handling, you are running into a fundamental difference in the Flash and AIR run-times.
If using the URLRequest object to retrieve files you are going to get a security error from Flash on every request to every server that has not set a policy file to allow these sort of requests. AIR allows these requests since it basically IS the client. This makes sense since it's the difference between installing an application and visiting a web page.
I hate to provide the non-answer, but if you can't make a server-side call, and you are hitting a range of "not-known" servers, it's going to be a tough road to hoe.
But maybe I misunderstand, are you just trying to Link to the files and prevent the user from getting bad links, or are you trying to actually load the files?

Categories