I have a slight issue and wondering if someone out there can help.
I am using reachability in my project and it is working without any issues, however we have a phone that has 3g connection but no credit and this isn't falling within the reachability criteria so not erroring at all.
Is there any way to detect this and handle it?
Thanks
IF no credit, the behavior of network connection is up to your operator.
You can check whether socket is broken but you will not know it is caused by no credit or, server down, or other real network connection issue.
If you operator provide some online system to check credit, maybe you can implement a function to check credit online with some delay (up to operator's system)
Related
We’ve been using the Tokbox platform for several months now with a Javascript web-client as well as an Android phone client, where sessions and connections are managed by a Python server. While integration and bring-up went well on both ends (client and server), we continue to encounter problems with the in-session audio and video experience.
Sessions are always routed and always between two participants only, with much use of a collaborative editor.
The in-session experience is like a coin toss: we never know how it’s going to go, and that’s becoming a business threat.
Web-Client: A/V Resources
The most common problem is the acquisition of audio and/or video: at the beginning of a session, one or the other participants may have problems hearing or seeing the other. Allocating a new connection to establish new streams does not fix that, nor does restarting the browser.
Question: What’s the recommended way to detect possible resource locks (e.g. does another application hog the camera/microphone)?
Web-Client: Network
Bandwidth and packet loss are a challenge, for example this inspector graph:
Audio and video of both participants is all over the place, and while we can not control the network connections the web-client should be able to reliably give useful information.
Question: Other than continuous connection monitoring with getStats() and maybe the experimental navigator.connection property, how can the web-client monitor network connectivity?
Pre-Call Test
We recommend to customers to run a pre-call test and have implemented it on our site as well. However, results of that test often times do not reflect the in-session connectivity. Worse, a pre-call test may detect a low (no video) bandwidth while Skype works just fine.
Question: How can that be?
I'm a member of the TokBox development team. I remember you reported an issue with the Python SDK, thanks for that!
Web-Client: A/V Resources
Most acquisition issues are detected by the JS SDK and if they aren't then we'd really like to hear about it! Please report reproduction steps or affected session IDs to TokBox support (referencing this StackOverflow question): https://support.tokbox.com/hc/en-us/requests/new
Most acquisition errors appear as OT_HARDWARE_UNAVAILABLE or OT_MEDIA_ERR_ABORTED errors. Are you detecting and surfacing these errors to your users? There is also the special OT_CHROME_MICROPHONE_ACQUISITION_ERROR error which is due to a known issue with Chrome that has been mostly fixed since Chrome 63 (see https://bugs.chromium.org/p/webrtc/issues/detail?id=4799).
Web-Client: Network
Unfortunately this is one of the more difficult issues to troubleshoot. Yes, Subscriber#getStats() is the best tool we have at our disposal and is a wrapper around the native RTCPeerConnection#getStats() function. Unfortunately we don't have much control over the values returned by the native function and if you think our SDK is returning incorrect values when compared with values from RTCPeerConnection#getStats() then please let us know!
It would be worthwhile confirming whether the issue is reproducible in all browsers or only a particular one. If you have detailed data regarding the inaccuracy of the native RTCPeerConnection#getStats() function then we could work together to report it to the browser vendor(s).
Fortunately we have just released the new Publisher#getStats() function which lets you get the publisher side of the stats. This should help you narrow down the cause of a connectivity issue to either a publisher or subscriber side. Please let us know if this helps with tracking down these issues.
Pre-Call Test
Again, these tests are based on Subscriber#getStats() which in turn are based on RTCPeerConnection#getStats(), the accuracy of which is out of our hands, but we'd love any reproduction steps to either fix a bug in our client SDK or report a bug to the browser vendors.
Just to confirm though, when you say you've implemented a pre-call test in your site, did you use the official JavaScript network test module? https://github.com/opentok/opentok-network-test-js This is actually what's used by the TokBox pre-call test.
#Aiham, thanks for responding, I've been looking at the the new Publisher#getStats() you linked to (thank you!), so we too can give our users some way of visibly seeing the network conditions that might be affected the quality of their call (and who's causing it). However, it seems as though bytes / packets sent goes up sharply as the number of subscribers increases, even though we're in a routed session.
Am I wrong to expect the Publisher#getStats() statistics to stay fairly stable regardless of the number of subscribers then receiving that stream in a routed session? I expected the nature of a routed call to mean it's sent once to the OpenTok Media Servers, and the statistics would end there.
I'm working on a WebRTC solution for audio/picture comunication and I'm a bit concerned about the lack of bandwidth control when two Peers in LAN are communicating.
Basically I want to be able to prioritize and pre-allocate bandwidth on my switch for WebRTC calls. But I couldn't see a proper way of filtering the packets when they are in a P2P call.
Also, I don't want to decode the packet to do that, because of the possible delay caused by this operation.
I hope you guys can show me a proper way or just tell me if my teorical solution could work.
I'm not 100% sure about the idea I'm planning to test, because I don't know how TURN server works internally.
But here is the idea:
And what I dont know is: Is it possible to make 2 turn servers know each other? Would they work like a 2 layer proxy between callers? If yes, could you please show me what I have to do to make it work?
Just install a internal proxy server to the external turn server and prioritize the proxy on your lan.
(answering my own question after realizing the solution was easier than I thought)
Been trying to find the issue here (Unity devs make it seem it's a design choice somehow), but I've been trying to simulate lag to see how my game works over the internet (I've also tried connecting a client from a tethered hotspot and it disconnected as well) and found that any amount of packet loss (even just 1%) will eventually lead to a disconnection within a couple minutes.
My game receives data just fine, as you can see the remote players moving around just fine until the disconnection. I think it has something to do with UNET's heartbeat packets not being resent for some reason, and has soon as it drops the first one you get disconnected.
If this is a design choice, I can't see how Unity would think you could have a rock solid connection when you obviously have some who could be playing off a cellular connection. Anyone know anything about this? I've tried asking on the Unity forums as well, and there's been no replies for over a week now.
Thanks
I have been working on Reachability class for a while and have tried both the one from Apple sample and the one from ddg. I wonder whether the Reachability class keep sending / receiving data after starting the notifier.
As I'm developing an app which connect to different hosts quite often, I decided to write a singleton and attach the reachability classes I need on it. The reacability classes would be initiated and start their notifiers once the app start. I use the singleton approach as I want this singleton class to be portable and can be applied to other apps without much rewriting. I am not sure if it is good idea to implement like this but it worked quite well.
However, someone reported that the battery of his device drain significantly faster after using the app and someone reported more data usage. My app does not send / receive data on background so I start wondering if it is related to the reachability.
I tried profiling the energy usage with Instrument and I notice that there are continuous small data (few hundred bytes in average) coming in via the network interfaces even I put my app in idle. However, there are almost no data sending out.
I know that Reachability requires data usage when initiate (resolving DNS etc) but I am not sure that whether it still keep using data after starting notifier. Does anyone can tell?
I am not familiar with the low-level programming, it would be nice if someone could explain how does the Reachability work.
I use Reachability, and while I haven't monitored the connections, I have browsed the code, and I can't see any reason why it would keep sending ( or receiving).
If you have a ethernet connection to your Mac, it is quite easy to check. Enable sharing over wifi of your ethernet connection. Install little snitch, it will run in demo mode for three hours after every boot. Turn off the data connection on the test device and connect it to your mac over wifi.
This will allow you to see any network access your test device is making.
If this isn't possible, you can also run your app in the simulator as the network side should be the same, so you should be able to check.
There are also a ton of other tools to track network activity, but I think little snitch is the easiest to use.
Besides "no connection", what other failure modes should I test for? How do I simulate a high-latency link, an unreliable link, or all the other sorts of crazy stuff that will undoubtedly happen "in the wild"?
How about wireless applications? How do I test the performance in a less-than-ideal WL environment?
To add to TimK's answer, if you have a router, test pulling the upstream link on the router, this will test a bad connection without your system knowing that you lost the physical link.
Also if you plug it back in after a few seconds it's possible that the connection won't be lost*. This can simulate a very high latency.
*this depends on your ISP and your router.
If you're using Linux, try Virtual Distributed Ethermet (VDE).
VDE gives you virtualised switches/hubs and Ethernet cables. You can tune network characteristics such as latency, delay, MTU, errored bits per MB, bandwidth, duplicates, etc on individual cables - all in real time!
You definitely want to test physically pulling the cable out. Lots of networking code will throw different exceptions in that scenario vs when the connection has just been lost.
To add to TimK's answer, if you have a router, test pulling the upstream link on the router, this will test a bad connection without your system knowing that you lost the physical link.
Our network/server closet is a spaghetti-mess of wires; I'm not going to walk in there and start unplugging stuff lest I hit something mission-critical. (At least I have access to it; I'm sure many readers don't even know where their routers are.) Similarly, both ends of the ethernet cable require a hands-and-knees adventure to reach.
I tested enabling/disabling the network adapter, and I'm going to test from my cable internet connection from home as well. Also, I had the idea of installing Tor to create a high latency connection.
For wireless connections, I have a metal box to test what happens when the signal dies, but I notice that network connection behavior is very different depending on how I test:
put the transmitter/reciever in a metal box
go stand next to the microwave in the kitchen and turn it on
go stand in a little closet which has concrete walls