I am currently using a Kandy WebRTC library to make WebRTC based audio calls. As this JavaScript library internally using the WebSocket the problem I am facing is to keep the session alive if the user refreshes the page.
For example, when a user A connects via Kandy library and makes a call to user B and during the call if the user refreshes the page the connection lost at user A but user B is still on call as it is not properly ended by user A. The hurdle is Kandy library does not provide a way to re-connect to an ongoing call.
Hence, I want to know is there anything that we could do on a client-side to manage this refresh page issue. One of the approaches that came into my mind is to shift the JavaScript Client + Kandy logic to the Node.js server and access the make call and receive calls using HTTP services. But I am really not sure how the audio would work in this case because this Kandy library requires the rendering media or <audio> tag to establish the media channel.
Here is the Codepen link just to understand the code, due to security reason I won't be able to provide the credentials but you can have the jest of code that we have used for the sample.
Check the kandy.media.renderTracks(call.remoteTracks, "#remote-container") which requires the div tag <div id="remote-container"></div> to render the media.
That seems like a bug in the Kandy SDK. Typically the signalling server (in this case a websocket) can detect if a client that is in a call closes the websocket and notify the other end of the call.
Using window.onbeforeunload to send a clientside "bye" might help too.
Related
I’m trying to monitor which service workers are active (ie, which users have their browsers open). I came up with a solution that sends a simple ping through the web push API, and that would trigger the service worker to send a ping request to my server. But I’m finding that if I don’t display a notification to the user, I get an alert from Chrome.
This site has been updated in the background
Am I doing something wrong, or is there another way to solve this problem?
No, you're not doing anything wrong. This is by design.
It is not possible to contact the Service Worker in the background using the Web Push APIs and have the system not tell the user. You're describing a passive tracking system where you track the user even though the user is not using the product, and that has been restricted by SW design. When you use Web Push you should show your own notification (the API is for notifications) and if you don't, that's what the browser does.
I understand that it would be super nice to be able to contact the SW from the server and have it run some little errands but unfortunately that would make it possible to carry on some mischief too. You also cannot eg. leave open a WebSocket (not available in the SW) or schedule tasks in the future to have it ping (not guaranteed to run).
i have developing a website that user can chat with other user if they are online . if one user send a message will notify that receiver on their screen , these checking process are happen in background process , i have an option of using
setinterval method and javascript self execution method
but i am looking much faster background process methods which will check every seconds if message or notification arrived .
could any one give suggestion for this.
You can use HTML5 websockets.
WebSockets is an advanced technology that makes it possible to open an interactive communication session between the user's browser and a server. With this API(JS functions), you can send messages to a server and receive event-driven responses without having to poll the server for a reply.
below is good link to start
http://www.sanwebe.com/2013/05/chat-using-websocket-php-socket
I think the best match for your needs will be http://elephant.io
Elephant.io provides a socket.io client fully written in PHP that should be usable everywhere in your project.
Take a look at the Thruway Project. It's a PHP websocket implementation using the WAMP protocol, which gives you Publish and Subscribe abilities (you can use that for your chat application) as well as RPC.
A good place to start would to take a look at this chat demo (source code) and then use Thruway as the WAMP router.
I'm one of the developers of the thruway project, so if you run into any issues or have any questions, feel free to ask.
I have a web application which does downloads of some reports in differents pages in my app, I retrieves the report's data from an external API, I am using AJAX call to get this data. As expected, if the user change the page while the report is being generated the user will not be able to download it, the HTTP request is supposed to be canceled.
There are some solutions in my mind for this problem:
I can open a popup to request the report and keep it open;
I can leave the whole app inside an IFRAME and request the report out of the page;
Or I can change the way how to download the reports doing a queue(Just an idea, does not matter now)...
Is there an alternative way to do that?
Would be possible to keep the HTTP request even when the user change the page?
My scenario is in front-end side(javascript) I don't have access to any back-end. But if there is no way in front-end side, I would like to hear from you any idea.
use onbeforeunload to warn the user that if he navigates away from the page the download will be cancelled
ASP.NET SignalR
ASP.NET SignalR is a new library for ASP.NET developers that makes it incredibly simple to add real-time web functionality to your applications. What is "real-time web" functionality? It's the ability to have your server-side code push content to the connected clients as it happens, in real-time.
You may have heard of WebSockets, a new HTML5 API that enables bi-directional communication between the browser and server. SignalR will use WebSockets under the covers when it's available, and gracefully fallback to other techniques and technologies when it isn't, while your application code stays the same.
SignalR also provides a very simple, high-level API for doing server to client RPC (call JavaScript functions in your clients' browsers from server-side .NET code) in your ASP.NET application, as well as adding useful hooks for connection management, e.g. connect/disconnect events, grouping connections, authorization.
http://signalr.net/
This was the solution my team found out. It's working fine. Our case is only for ASP.NET. But as the own text says, "You may have heard of WebSockets, a new HTML5 API that enables bi-directional...". So, now we can do that.
I'm looking into implementing a web page to show the user's news feed with real-time updates, without using simple polling to the facebook servers.
after browsing through similar questions:
How to implement facebook line notification?
How does facebook, gmail send the real time notification?
Facebook notification system: Is it polling?
As I understand - long polling (see Comet model) is the most preferable way for me to achieve "push"-like events for when a new post is added to a user's feed.
I'm using javascript, on IE browser (6 and above), and the page is actually stored locally, and not on a server.
I'm aware of the real-time updates subscription graph API, but as I mentioned, my page will run locally, not on a server (not even localhost), that's why long polling seems so attractive at the moment.
My question is - does anyone know if and how long polling (or any other Comet model alternative) is available to use via the Facebook API? or maybe any other suggestions?
Thanks.
I think the only long polling available is for the chat API. Otherwise you're stuck with either real-time updates or using a javascript timer to poll.
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.