How can I check on the web if someone is visiting a page with a 3G mobile connection (so no WiFi)?
This because I want to show a video when someone has a normaal speed internet connection on his phone (with WiFi). If someone has a slow (not WiFi) internet connection on his phone at that moment, I want to show a photo instead. So the user doesn't have to download the 30MB video file with his try connection, and destroying his bandwidth limit of his provider.
I prefer a client-side solution with jQuery/Javascript or server-based with PHP if possible.
Found an interesting approach to estimate the connection speed with PHP : http://www.emanueleferonato.com/2006/05/31/determine-connection-speed-with-php/
The estimated speed will depend on the connectivity with the server so it is not so accurate but may give you a great idea. You could display the photo whenever the result is lower than a certain value.
Related
My app is built in Angular (2+) and NodeJS. One of the pages is basically a dashboard that shows current tasks of a company, where this dashboard is shown all day on a TV to the companies staff.
Rarely is it refreshed or reloaded manually.
Tasks are updated every 5-10 mins by a staff member from another computer.
Tasks on dashboard need to be updated asap after any task is updated.
App should limit data transfer when updating dashboard, after task update.
I initially tried websockets but had a problem with connection reliability as sometimes the board would never get updated because the websocket would lose its connection. I could never figure this problem out and read that websockets can be unreliable.
Currently I'm just running an http call every 15 seconds to retrieve a new set of data from the backend. But this can be costly with data transfer as the app scales.
I've just recently heard about SSE but know nothing about it.
At the moment my next plan is to set up a "last updated" status check where I still run an http call every 15 seconds, passing a "last updated" time from the frontend and comparing that to the backends "last updated" time (which is updated whenever a task is changed) and only returning data if the frontend's time is outdated, to reduce data transfer.
Does that sounds like a good idea, or should I try websockets again, or SSE?
I initially tried websockets but had a problem with connection reliability as sometimes the board would never get updated because the websocket would lose its connection.
Handle the event for when the connection is lost and reconnect it.
I could never figure this problem out and read that websockets can be unreliable.
Don't let some random nonsense you read on the internet keep you from owning the problem and figuring it out. Web Sockets are reliable as anything else. And, like anything else, they can get disconnected. And, like many of the newer APIs, they leave re-connection logic up to you... the app developer. If you simply don't want to deal with it, there are many packages on NPM for auto-reconnecting Web Sockets which do exactly I suggested. They handle the events for disconnection, and immediately reconnect.
Currently I'm just running an http call every 15 seconds to retrieve a new set of data from the backend. But this can be costly with data transfer as the app scales.
It can be, yes.
I've just recently heard about SSE but know nothing about it.
From what little we know about your problem, SSE sounds like the right way to go. SSE is best for:
Evented data
Data that can be somehow serialized to text (JSON is fine, but don't base64 encode large binary streams as you'll make them too big)
Unidirectional messages, from server to client
Most implementations will reconnect for you, and it even supports a method of picking up where it left off, if a disconnection actually occurs.
If you need to push only data from the server to the client, it may worth having a look at Server-Sent Events.
You can have a look at this article (https://streamdata.io/blog/push-sse-vs-websockets/) and this video (https://www.youtube.com/watch?v=NDDp7BiSad4) to get an insight about this technology and whether it could fit your needs. They summarize pros & cons of both SSE and WebSockets.
I was wondering if gmail(Google mail in general) has any limits for number of simultaneous connections that can be open from a single server for different accounts?
The use case is that, I'm trying to write a email engine from backend. I would like to connect to different email accounts from a single server.
I tried to look around on web for this, but couldn't find anything related to this. All I found was the limit on number of connections that can be open for an account(which is 15).
Anybody have any idea on the limit for number of connections that can be open from a server? Is there any such limit at all?
The number of connections allowed to an IMAP server directly is going to be in the billions. I don't think that Google is going to do any checking to see if your server is sending to many.
The fifteen limit per account kind of makes scene. However you need to consider how many email systems run on servers these days. Its going to be normal that a lot of incoming request come from the same server however are directed to different accounts.
This is just my opinion i don't think your going to find any documentation on Googles side telling you that you can spam there server as much as you want.
My team is building a client/server application using thrift over rpc/tcp, we have one requirement from our stakeholder that we find very complicated in thrift. Every time a client opens a connection, we need to log the ip of that connection, it dose not matter if the client calls anything, the log have to be there. So my question is, how do i do that, as fare as i can see, the options are very limited. I found an event called TServerEventHandler, but i don't get the right information there as i see it, can anyone point me in the right direction if there is one??
I have a production app that uses socket.io (node.js back-end)to distribute messages to all the logged in clients. Many of my users are experiencing disconnections from the socket.io server. The normal use case for a client is to keep the web app open the entire working day. Most of the time on the app in a work day time is spent idle, but the app is still open - until the socket.io connection is lost and then the app kicks them out.
Is there any way I can make the connection more reliable so my users are not constantly losing their connection to the socket.io server?
It appears that all we can do here is give you some debugging advice so that you might learn more about what is causing the problem. So, here's a list of things to look into.
Make sure that socket.io is configured for automatic reconnect. In the latest versions of socket.io, auto-reconnect defaults to on, but you may need to verify that no piece of code is turning it off.
Make sure the client is not going to sleep such that all network connections will become inactive get disconnected.
In a working client (before it has disconnected), use the Chrome debugger, Network tab, webSockets sub-tab to verify that you can see regular ping messages going between client and server. You will have to open the debug window, get to the network tab and then refresh your web page with that debug window open to start to see the network activity. You should see a funky looking URL that has ?EIO=3&transport=websocket&sid=xxxxxxxxxxxx in it. Click on that. Then click on the "Frames" sub-tag. At that point, you can watch individual websocket packets being sent. You should see tiny packets with length 1 every once in a while (these are the ping and pong keep-alive packets). There's a sample screen shot below that shows what you're looking for. If you aren't seeing these keep-alive packets, then you need to resolve why they aren't there (likely some socket.io configuration or version issue).
Since you mentioned that you can reproduce the situation, one thing you want to know is how is the socket getting closed (client-end initiated or server-end initiated). One way to gather info on this is to install a network analyzer on your client so you can literally watch every packet that goes over the network to/from your client. There are many different analyzers and many are free. I personally have used Fiddler, but I regularly hear people talking about WireShark. What you want to see is exactly what happens on the network when the client loses its connection. Does the client decide to send a close socket packet? Does the client receive a close socket packet from someone? What happens on the network at the time the connection is lost.
webSocket network view in Chrome Debugger
The most likely cause is one end closing a WebSocket due to inactivity. This is commonly done by load balancers, but there may be other culprits. The fix for this is to simply send a message every so often (I use 30 seconds, but depending on the issue you may be able to go higher) to every client. This will prevent it from appearing to be inactive and thus getting closed.
We have an browser application (SaaS) where we would like to notify the user in the case of internet connection or server connection loss. Gmail does this very nicely, the moment I unplug the internet cable or disable network traffic it immediately says unable to reach the server and gives me a count down for retry.
What is the best way to implement something like this? Would I want the client browser issuing AJAX requests to the application server every second, or have a separate server that just reports back "alive". Scalability will be come an issue down the road.
Because GMail already checks for new e-mails every some seconds and for chat information even more frequently, it can tell without a separate request if the connection is down. If you're not using Ajax for some other sort of constant update, then yes, you would just have your server reply with some sort of "alive" signal. Note that you couldn't use a separate server because of Ajax cross-domain restrictions, however.
With the server reporting to the client (push via Comet), you have to maintain an open connection for each client. This can be pretty expensive if you have a large number of clients. Scalability can be an issue, as you mentioned. The other option is to poll. Instead of doing it every second, you can have it poll every 5-10 seconds or so.
Something else that you can look at is Web Sockets (developed as part of HTML 5), but I am not sure if it is widely supported (AFAIK only Chrome supports it).