Im using my GAE application on my phone. I face a problem in getting the disconnect notification to /_ah/channel/disconnected in channels api even if i manually close the socket by socket.close() function. the post occurs after a delay of say one minute. Does anyone know the way to speed things up? In my case socket.close() doesnt produce the channel disconnect notification(only in phone though.. it works perfectly from a laptop)!
The amount of time it takes the Channel API front-end servers to "realize" that a channel is disconnected is contingent on browser implementation.
On well-behaved browsers, we catch the beforeunload event and post a message to our front-end that says, "this client is going away." On other browsers, we may not get the event (or we may not be able to listen to it for various implementation reasons, like the browser sends it too often (FFFUUUU IE)) or once we get the event the XHR we send may get swallowed. In those cases, the frontend server realizes the client is gone because it fails to receive a heartbeat -- this is what's happening on your phone. (out of curiousity, what phone?)
Your case is interesting because you're explicitly calling onclose. The only thing this does is dispose the iframe that has the Channel FE code -- in other words, onclose just behaves as if the whole browser window was closed; it doesn't take advantage of the fact that the browser is still in a good state and could wait to close until a message is sent.
So I recommend two things: add a custom handler to your code (that does the same thing as your /_ah/disconnect handler) so you can just make an XHR when you know you're manually closing the channel. This is kludgy but functional. The bummer about this is you'll need to explicitly know your client id in your javascript code.
Second, add an issue to our issue tracker (http://code.google.com/p/googleappengine/issues/list) to request better disconnect notification when onclose is called explicitly.
Hope that helps; sorry there's not an easy answer right now.
Related
I am using Server Sent Events for my small chat application, and I am storing a list of sent events on my server, along with passing an id field with SSE message.
Server Sent Events apparently has a concept of automatic reconnection, but I cannot seem to find a single instance where this actually occurs in practice.
For example, if you are on Android and tab out of the application, wait 30 seconds, and then tab back in, then the connection is broken. But the onerror event never occurs, and the readyState stays OPEN. So the only option to handle this situation seems to poll for heartbeats and do a manual reconnection by re-initializing the EventSource object if curr_time - last_heartbeat > heartbeat_interval
Another instance of disconnection is when you for example disable WiFI and then re-enable it. However, when this occurs, Android Chrome just automatically refreshes the page, so reconnection doesn't occur here either (instead it's just refresh which causes a disconnect and then a fresh connection).
So, am I missing something? SSE is touted as being very robust for its automatic reconnection ability, but I cannot find a single case where it actually performs a reconnection. What instances are there where a reconnection can actually occur, such that I can test this behavior?
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 am working with socket.io and node.js. I'm am having problems tracking which users are online because of the few seconds delay before socket IO recognises an XHR-Polling client has disconnected.
If an XHR-Polling client refreshes the page their new connection message seems to precede their disconnection message. This causes confusion when trying to track which users are online.
One solution could be to detect the transport method on the serverside and delay the connection for XHR-Polling clients to ensure that the disconnection functions have been run first.
Has anyone had any experience of this?
The main problem with presence, as #davin and #jcolebrand point out in the comments, is that connections alone can't be relied upon. Network devices can hold on to connections after a user has navigated away from a page. So, you need something else in place to confirm a users presence.
This is something we've added support for in Pusher and we do this using something called Presence Channels.
We manage this using a unique user id, which you (the developer) have to supply when a user connects, in combination with a unique socket id which identifies the connection. Since this unique user id can only occur once within a presence member list it means that that user will only be listed once - even if they have multiple connections open, and thus multiple socket connections.
The same idea can be applied to HTTP connections.
The general approach for this is to use the session to uniquely identify the user. In that way even if they are just a "Guest" you can still identify them as long as they are allowing the use of cookies.
So, the number of users on your system should only ever max at the number of active sessions you have running on your server.
Hope this helps. Let me know if you'd like anything clarified.
I'm developping a chat support solution and the attendent have to know when a client connect. With websocket works fine, but with whr-pooling, sometimes the attendent just disconnect (with 5 seconds in some cases). Sometimes dont heppend. What I do: I just enter the page and wait looking the terminal app.
I'm using nodejs, nowjs
What version of socket.io are you using? I encountered this issue and solved it on this post. It turns out there was a bug introduced in socket.io 0.9.5 on the request sent when the beforeunload event was triggered that prevented the proper disconnection.
I've recently taken over a project that uses COMET to perform some collaborative work and handle a simple chat room. The guys who originally wrote this thing made up some classes on top of STOMP and Oribited to handle all the actual chatting and messaging and logging.
The problem is that if a user closes the window or navigates to a different page or terminates the connection for whatever other reason, it takes a while for all the other users to see that he has logged off. The other users have to wait for the timestamp of the exited-user's last ping to exceed a certain duration before it registers that the user is no longer connected to the system.
The solution that I can think of requires sending out a notification in the onuload event that the user has left, so that it would notify all the other users without having to wait for a timeout. The problem with this is that since onunload will immediately terminate the connection before it's completed. From what I understand this is a problem with AJAX as well.
Now, I also have read that a Synchronous request in unload will delay the window-close/navigation until the request has finished.
So, my questions is this: does anyone know of a way to temporarily make the comet request synchronous in selected instances so it has time to finish the request before terminating? Or is there another way to solve this problem that I'm not thinking of? Thanks for your help.
Oh, also, onbeforeunload won't work because if it sends the request and the user selects "No, I want to stay on this page" it will have already have notified the other users that he has exited the chat.
tl;dr: Need a way to successfully fire a COMET request in the Unload event. We're using STOMP and Orbited for the COMET stuff.
The 'onbeforeunload' function produces a yes-no dialog only if some value is returned from it. So what you have to do is to use a SYNCHRONOUS XMLHttpRequest (AJAX) request inside the onbeforeunload function without returning anything. And you have to set the asynchronous flag of the request to false as seen in the AJAX GET request shown below:-
AJAXObject.open("GET", 'http://yourdomain/logout?somevar=something', false);
AJAXObject.send(null);
It will prevent the browser from closing until request completes and as I remember, Opera doesn't support 'onbeforeunload', so it won't work for Opera. But it works fine on IE,FF,Chrome.
If you are using comet, then you should control the server. The idea with comet is that it is not constant polling of the server. Every client should have a constant open connection to the server. As such, when the connection closes, the server should be able to send out a notification to the other clients.
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.