Recent days there is a rumour that some Internet Service Providers in my country limiting the speed of traffic for certain services e.g. Skype, Whatsapp, Viber, etc. Also in reality neither of those services work properly, I can barely call someone.
Is it possible to prove it technically doing some tests or it's just a Hoax and maybe internet itself is heavily loaded?
Related
I live in an area where net access is mobile or nothing. While I can occasionally get access by tethering a mobile to that network, it isn't often connected, and when it isn't connected, no local device will function on its own, no matter which protocol it uses. Why isn't there any kind of server/cloud resiliency built in where devices can communicate in a peer fashion like Apple's Bonjour (Rendezvous? I can't remember)? If I have an Echo device, I should be able to switch it on through an Alexa interface. I'm OK without speech processing which requires interpretation of commands through an AWS or Google or Apple or whatever cloud, but being able to locally control a switch seems as though the interface could be smart enough to route locally. I guess I may have just answered my question. It seems as though routes could be internally stored so as to not to definitely require a server. Can you imagine shipping a colony to Mars and all the IoT devices stop working? If you ask me, they should not require a branch variation or special programming in order to function.
From the experience of having sat down and built a few, there are a some key reasons why viable IoT gadget products for the general market typically end up having to have a cloud-mediated mode, no matter what was envisioned when the design effort originally commenced:
General consumers (at least think) they want the option to control things when outside the home
Often even at home, a mobile phone may be on the mobile network not wifi, meaning that even if the user is physically inside their home, in network terms, they are not.
Firmware updates, dynamic content, etc are easier when they don't have to be relayed through a mobile phone or PC, especially a mobile that might sometimes have to jump networks partway through the process.
Ironically, having once set out to build an IoT product that could work entirely offline, the further the project progressed, the more and more difficulties that approach presented for general users, and the more the cloud path that was added as an option, started to look preferable in terms of how things should work all the time so that it could become the exclusive focus of development efforts.
My conclusion is that it's very hard to build an offline IoT gadget. Not only the developer, but also the users and marketing people need to understand and accept what sorts of difficulties and limitations that can mean.
So where does it happen? In the situations where the "users" are the "developers" - eg. open source. If you look around a bit, you'll find plenty of gadgets either built form scratch, or more commonly reverse engineered so they can run a custom firmware. Want a local RESTful API? Done! Want could relay via MQTT over SSL to your own broker? Done!
When you control the code, you control the mode.
But with products for the general market, most customers want things to work, not a lengthy technical explanation of why the details of their network setup mean they cannot.
I am struggling to find how to let google home do a local network rest call.
I have some ESP8266 laying around with mDNS and rest api in them.
Now with the google home I want it to send a rest call to the device.
I don't want any web hooks / services like IFTTT. I don't want the communication going through these 3rd party services.
It should work like this google home gets input (google service to understand is oke). It retrieves the action (local network, url rest call with body). Google home sends the rest api call to the local device.
No need to have port forwarding / firewall changes.
The Google Home does very very little on-device processing. Sending out local network calls is not one of the things it does. Almost all processing, including IoT controls through the Smart Home API, are done through cloud-based services.
Update
I can't answer "why" it doesn't do this, since I'm not one of the engineers that built it, but I can make a lot of guesses about why.
For starters - it increases the complexity of the software and hardware on the device dramatically. Right now, the device is really little more than a microphone and a speaker, with a little logic to detect the hotword and then stream everything else to the server, and then get a result back and play it. Most of the rest of the code is likely to handle setup and configuration.
If the device has to also be a general purpose IoT hub, then it needs software and hardware for Bluetooth and possibly other signaling systems. It needs to be able to keep track of the state of other devices on the network and manage that in between power cycles of the device (or even handle interruptions in power for the device itself). Some of the implications of that may need to open up the networking on the device to receive messages, not just send them. It has to have more extensive network configuration - to understand what local networking is and not just what the local router is and how to deal with that configuration (and that configuration when it changes). These are all possible, to be sure, but increase the complexity and, in some cases, lower the security of a device.
And that might be reasonable... if there was significant value in doing so. But you've already stipulated in the question that the voice processing could be done in the cloud, so once commands are sent to the cloud and parsed there - why not also do all of the above (device and state tracking, changing, etc) in the cloud? Particularly since most IoT devices maintain cloud servers anyway because people also want to be able to control or monitor their home devices when they aren't on their home LAN. Having a dual set of commands (some for when you're local, and some when you're not) does make sense in some cases - but also dramatically increases the complexity of both the controller and devices, so most just rely on the cloud, again.
So while I understand why some people would like to have a nice little system that can just sent your play local REST server a command now and then, the reality is that to do this for a consumer system isn't that reasonable.
If you really wanted a system that can do this - you can continue in the hobbyist spirit and build something with the Assistant SDK and your favorite IoT platform.
The “local” API for Google Home is a bit limited. Here’s a doc from someone who reverse-engineered the API.
Looks like they expose Bluetooth and Alarms/Timers, and some limited configuration stuff.
https://rithvikvibhu.github.io/GHLocalApi/
I have an idea for an iPhone app that will make billions of dollars for me, and help me take over the world. I am currently designing the architecture of the application. I had originally assumed that I would need to create and host a database that would allow users to upload their data and share it with other, targeted, users. But I thought it would be better if the users could send their data directly to each other without having it stored in a database. However, I haven't been able to find anything that would suggest this is possible.
Is it possible to send data between iPhones that are not in close proximity (bluetooth) and not on a LAN? For instance...User #1, who is in Tennessee, creates some information and hits "Send to others" and it sends that information directly to User #2, who is in Arizona, and User #3, who is in Maine. Could the text messaging functionality be hacked to do that?
(I realize that the phones belonging to Users #2 and #3 would have to be on, and running the app that would receive the data)
I am new to mobile development, and I am still getting used to the functionality of mobile devices so, I am certain this is a dumb question. But, it is worth asking because, if it can be done, this would dramatically change the architecture (and maintenance costs) of this application.
Thanks, in advance, for whatever advice/pointers you can give.
This is something handled by using the publish - subscribe pattern. You may want to look into a plug 'n play service such as pubnub. That will let you do just that. Phones that should be receiving each other's messages will have listeners set up on the same pubnub channel, and will receive a notification when any of the other phones publish to that channel. Something like pubnub has a pretty simple API/SDK that you can use to get a prototype up and running pretty quickly (and for free, at least at first).
User #1's app sends the message to your server. You server does an APNS push to the phones of users #2, and #3. They don't even need to be running the app.
No need to mark this correct or up-vote it, but I will take a high-paying job in the new world order.
Amazon has an application service called Simple Queue Service (Amazon SQS) which Allows you to create queue's with messages in them tat app's can subscribe to.
To quote their page:
Amazon Simple Queue Service (Amazon SQS) offers a reliable, highly
scalable, hosted queue for storing messages as they travel between
computers. By using Amazon SQS, developers can simply move data
between distributed components of their applications that perform
different tasks, without losing messages or requiring each component
to be always available. Amazon SQS makes it easy to build an automated
workflow, working in close conjunction with the Amazon Elastic Compute
Cloud (Amazon EC2) and the other AWS infrastructure web services.
Amazon SQS works by exposing Amazon’s web-scale messaging
infrastructure as a web service. Any computer on the Internet can add
or read messages without any installed software or special firewall
configurations. Components of applications using Amazon SQS can run
independently, and do not need to be on the same network, developed
with the same technologies, or running at the same time.
They have an iOS API to integrate it into your app, and it is free for up to 100,000 messages per month and then $0.01 per 10,000 messages after that.
More info here:
http://aws.amazon.com/sqs/
Is it possible to send data between iPhones that are not in close
proximity (bluetooth) and not on a LAN?
The two devices obviously need some kind of connectivity.
For instance...User #1, who is in Tennessee, creates some information
and hits "Send to others" and it sends that information directly to
User #2, who is in Arizona, and User #3, who is in Maine. Could the
text messaging functionality be hacked to do that?
The problems here are:
helping each device discover the correct address for the others, and...
ensuring that the devices can reach each other.
Mobile devices are constantly moving around on the network and changing their IP addresses as they go. As you're driving to work, your device may have Internet access through it's 3G connection, except for those times when you're driving through a tunnel and don't have any connectivity at all. Once you enter your building, a wifi connection becomes available, so the device switches to that. But your company's network has a firewall that blocks incoming connections, and it's impossible to know in advance which IP address you'll get from the DHCP server at any given time anyway. The same is true for the folks in Arizona and Maine and wherever else.
A server, on the other hand, is usually located at an address that's both easy to discover (thanks to the Domain Name System), easy to reach, and almost always available. For those reasons, it's common to have mobile devices communicate with each other by going through an intermediate server.
I want to connect multiple devices through socket without any server implementation.I will use that only for getting the IP addresses of the devices that will register.
There are two major problems to peer-to-peer communications: discovery, and reachability.
First, you need to know the IP address of the other peers to connect to them. Once you're connected to a mesh of peers, they can all keep each other updated on the state of the network, suggesting better peers to each other, passing around notifications of new peers who've joined and left, etc. But you have to design and implement a mechanism for trading that information. More importantly, you need to jumpstart things in some way, because when a new peer starts up, it's in a mesh of just itself, and it has no information to give itself.
One possibility is to have a handful of well-known "superpeers" (that you run) that are always connected, and bake their addresses into the app. Or you can have "introduction servers" instead of peers, serving much the same function. Or you can have some external way of trading addresses (the simplest is that users trade them on a web forum or an IRC channel or in person and type them in manually), which can be automated to various degrees. There are also shortcuts that can help—Bonjour can get other peers onto the mesh as long as one peer on the LAN is already there; GameCenter/GameKit can be used as an automated external trading network; etc.
Once you've solved the discovery problem, you still have the reachability problem. Most iOS devices usually don't have publicly-accessible IP addresses; instead, they're behind routers that do Network Address Translation, whether they be a home WiFi router or a cell carrier's 3G network. This means you need some way to do NAT Hole Punching to get two iPhones talking to each other. Somebody who knows both the public address and the internal address of each device can arrange for them to set up a connection to each other. You can have either normal peers do this (although that makes the jumpstart problem even bigger) or have your superpeers/introduction servers/etc. do it.
If you want to build all of this yourself, you probably want to look at other implementations. BitTorrent (including trackers and DHT) is well-understood and documented at a continuum of levels ranging from "lies-to-children" for curious end users to detailed protocol specs and open source implementations. And then look at some other P2P networks, because BitTorrent is not perfect, and doesn't try to do everything that everyone's come up with.
You can use GameKit. It has the matchmaking api that can help you.
It can be used for non game apps.
I've been working on something similar and it's a giant pain in the ass. There are 3 considerations: 1) Reachability 2) Discovery 3) The connection itself.
1) Don't even consider using 3g/4g, it just won't work well for keeping an open socket connection.
2) I'd use some sort of broker service between the two on the internet to connect the two. For discovery, you can just list what devices are available on the service.
3) For the connection, I find the IOS socket libraries to be rather painful to use, but if you go down to the BSD socket level it's not as bad. I think it'd be very interesting to use zmq sockets; that might simplify writing the broker service.
You can't. If the device is all online with wifi, it maybe possible and rely on the router setting just like pc connect. If some device is connected with 3g or gprs protocal , they may have no ip address at all.
I am implementing an iPhone/iPad app that allows users to send each other messages using the bonjour protocol. Basically, a server publishes his service over bonjour and the clients connected to the same wifi can discover his service and connect to it to start sending messages. The problem I've found is that some routers seem to have problems with Bonjour. When running my app at home or at some other places it works perfectly. The publishing and discovering of the bonjour services works flawlessly. However when I tried my app at one of my friend's apartments, some (not all) of the clients were not able to discover the published bonjour service. I also noticed that other apps that use Bonjour (such as Apple's Remote app) were also having trouble on said network. After doing some digging I've found that other people have had similar problems with bonjour and some routers. Therefore I have 2 questions:
1) Does anyone know if this problem with Bonjour that some routers seem to have is a widespread issue? In other words, if my app relies on Bonjour in order to function at all, do I have to be worried that it won't work in 50% of the WLAN networks or do most routers not have any issues with bonjour. Obviously I can't expect anyone to know how every router out there deals with bonjour packets but maybe there are some Networking gurus that can point me in the right direction :-p.
2) Second, if bonjour is too risky of a protocol to build my app on, what are some alternatives with similar features? The features I would (preferably) need would be service publishing and discovery without users having to manually enter IP addresses of other phones.
Ok thanks for your help! I understand that this is kind of a broad question but any help is appreciated! :)
This is potentially a tough nut to crack. The problem causing devices not to find each other on certain networks is related to the underlying transport (i.e. multicast UDP) and not Bonjour (or mDNS or whatever else you wanna call it).
In high-level, non-rigorous terms, multicast data puts more load on routers. Large corporate and university networks sometimes like to drop Bonjour messages (i.e. UDP packets sent to the multicast group 224.0.0.251 on port 5353) because it means the network isn't inundated with thousands of clients advertising their iTunes libraries or whatever, and at scale this can improve general performance. At the other end of the spectrum, some domestic routers drop multicast packets out of the box for reasons known only to the manufacturer. There's not a whole lot you can do about either situation.
Try running a tcpdump on the network to see if the packets are actually coming through. I've not come across a home router that doesn't forward them for a while. If they're not, you'll have to come up with some central [internet-facing, perhaps?] lookup facility. If they're visible, then there's something up with your implementation.
There's nothing stopping you from writing your own simpler protocol for service discovery to be sent over multicast- it's just that there are loads of Bonjour clients in a ton of different languages already written and tested.