So here are the questions:
Does Apple's Bonjour even work over cellular (3G, 4G, LTE)?
If so, how local is the discovery? Discover all in the same cell tower? Same provider? The entire internet?
Also, just as a small side note, is there any Bonjour support on Android (libraries, OS, etc.).
Note: I'm really looking for a way to do local discovery, but iOS doesn't have a public Bluetooth API that could work with some droids (please correct me if I'm wrong, I really hope I am). I also read about Bonjour over Bluetooth, but I couldn't find any resources about it. Also, would NFC be an option?
To answer your first two questions:
No; in theory, other subscribers on the same subnet could see each others' services, but AFAIK there's no provision for sending multicast packets over cellular networks. Even if there were, network providers would likely filter it to reduce bandwidth usage.
A Bonjour service is generally visible to any other device on the same link-local network, i.e. the same subnet, assuming that the router doesn't filter multicast packets. Most domestic routers relay them, but some large [e.g. college & corporate] networks drop them, again to reduce demand for bandwidth.
You can use jMDNS to do Bonjour service advertising/discovery with Android, it's pretty mature (or you can even roll your own, it's not that difficult :)
As for Bluetooth and NFC, I'm not sure; it sounds like you'll need to administer some single point of registration/coordination for whatever service you're advertising/consuming.
Related
For android phone which supports volte, they can directly place call with jio sim without data require, but the phones without volte needs to use Jio4GVoice app or a custom rom which supports volte to make phone calls.
IS there any way , we can implement it for offline use?
4th Generation network, which we also know as LTE, was developed forecasting the growing data needs of the future. It was intended to replace wired broadband with wireless devices, a platform for which had already been set with 3G networks.
Hence this time, their focus in the development phase was not Voice, but only Data. To simplify network designs, all communication in & out was to be handled on fully-IP networks, much like the present Internet. This would enable faster, simpler communication than 3G, since all communication is now referred with their node's IP addresses. It was only in the final phases of development that they practically realised, for 4G to completely replace legacy systems, they must find a way to transmit Voice over the network, which they succeeded in, with VoLTE.
Basically, VoLTE speaks for itself, i.e. Voice over LTE.
VoLTE transmits Voice in Data form, much similar to VoIP internet calls we make on WhatsApp or Skype or Google Voice.
This means, you always need to establish a Data network with your respective 4G operator. This is unlike the system established in 2G/3G networks, where it would establish data networks only when you needed to surf the internet. Those were based on two way systems, different for Voice & Data.
4G transmits both Voice & Data simultaneously over the same Data pipeline, so you have the right to only be charged in Data you consume & not Minutes you talk. Which is the reason why Jio does not charge you separately for calls. The bandwidth required to transmit Voice is very small, (most calls usually fall in the range of KBs, in standard plan you get 1GB per day) & so Jio deducts the data used for Voice from your Data balance.
Since everything is data, you need to establish the data connection on your 4G smartphone or JioFi router to make calls. Hence Jio4GVoice app cannot function without a data connection.
I've seen in various VoLTE enabled smartphones, they still give you a Data Toggle/Switch to turn on/off data so that you can conserve some when not in use. It does not physically terminate data communication with the network, since it is the only connection. Rather, it just isolates all apps on your system from accessing the internet, and only the Dialer is given access to continue to make & receive 4G VoLTE calls.
Hope I've managed to solve all your curiosities.
I am developing an p2p application in android for an educational project in which I want to form groups android phones of students nearby and exchange sensor data in a university campus.
Now there are some considerations :
Devices will automatically discover each other and upon discovering connect and exchange data.
The process runs for a long time maybe 4-8 hours per day. (process of periodically sensing data and exchanging )
Now the p2p groups can be formed using either Bluetooth or WiFi (Not WiFi Direct, simple UDP packets over WiFi considering phones are connected on campus WiFi).
What are pros and cons of using Bluetooth and WiFi in this scenario in terms of reliability, power usage of phones, scalability and any other you can suggest.
Among other answers and input, I would added this answer.
First of all, before we chose WiFi or Bluetooth we need to find out the difference between those two technologies.
I have made comparison chart that covers some of the important information you might need regarding your project.
Note: There are different versions of Bluetooth's and WiFi, this chart is to represent the the general picture of Standard Bluetooth,
Bluetooth v4 and WiFi. It is always suggested to refer to manufacture
specification of each technology.
From the chart we can conclude that Bluetooth has lower power consumption vs WiFi, but at the other hand WiFi has more bandwidth than Bluetooth.
Range in general is just approximation, a lot of things affecting range like human body, obstacles, location (inside or outside), if inside; structure type and materials used inside the building, noise from other sources and devices etc.
(*) Regarding scalability, I have tested WiFi and Bluetooth v4, both system with up to 8 devices, where one of those is host (group owner, server) device and 7 others are guest (clients). see the figure below.
What regards reliability, with Bluetooth v4 I have had some time connectivity problems, but when it works than every-thing is fine.
Note: Bluetooth v4 is not back compatible with older versions of Bluetooth, so if your host is Bluetooth v4 than all other clients
should have Bluetooth v4 or vice versa.
So I will not say which one is best, but if you need longer battery life and light data communication than Bluetooth is the way. Regardless if it is Bluetooth OR WiFi you might need to start with Bluetooth to and test it, if you are happy with it than keep it, otherwise switch to WiFi.
In case you want to build your own code, the code example I followed and used previously for another university research project. It is based on 8 phones (host and client) as seen in the figure above, we collected sensor information and send it to host phone using Bluetooth 4 connection. The source code we used for that can be found here. The same project has WiFi and other type of connections.
Android official google documentation has some information and code example regarding WiFi peer to peer connection, you can follow with example of the code as well.
Regarding collecting your sensor data and sending those to one device. You could added a method that starts collecting sensor or what ever data, and after connection is established successfully than start sending it over to the other device.
As others suggest https://developers.google.com/nearby is also a way to go.
As you can rely on campus Wifi, I would definitely go with the implementation of Google Nearby APIs in my App as it was designed for such use cases...
The way it works answers your question : it makes all the heavy stuff for you, including choice between wifi or Bluetooth for better performance...
Google Nearby is definitely a good choice. You don't have to tackle all the problems when working with WiFi or Bluetooth directly. But Google Nearby only works when both devices are online and have their screens on. For a more critical review of Nearby have a look at http://blog.p2pkit.io/how-google-nearby-really-works-and-what-else-it-does
If you can not accept these limitations, you should look into other frameworks like http://www.p2pkit.io.
Disclaimer: I work for Uepaa, developing p2pkit for Android and iOS.
My computer does not have any Bluetooth capability, however it has WI-Fi capability. My phone has both.
I was asking myself if there is anyway to "stream" Bluetooth over WI-Fi?
Thanks!
The short answer is no. Easiest would be to purchase a bluetooth dongle for your computer.
Yes, tunneling one type of communication through another is generally possible (within the limits of the Android Bluetooth API), but as it is an obscure need you will probably have to write the bridging server to run on the Android device yourself - this is after all a site for questions about software development. Additionally, it will work best when the app hosting the server is in the foreground, as Android makes no guarantees about keeping services running in the background.
On the PC side, this bridged Bluetooth capability will probably not trivially present as an ordinary Bluetooth adapter, so you would be limited to using custom applications which known how to talk through your bridge. The exception would be if you also spend time figuring out how to write a device driver for your host operating system which presents it with traditional Bluetooth APIs, at least to the greatest degree possible.
can anybody confirm what are the currently allowed methods for peer-to-peer communications within the Android framework? I need to transfer json strings and I'm currently using SMS which works ok but the problem is that the data also ends up as lots of text messages. I've read Reto Meier's first edition of Professional Android Application Development where he says that the data transfer options were not implemented due to security concerns.
Has this changed at all and how would you do peer-to-peer transfer of data?
Have you looked at Qualcomm's AllJoyn library? It is designed to work over Bluetooth or wifi, so may fit, though if you're connecting over 3G or wider range networks it won't work.
Given the variation and reliability of networks between two remote devices not on the same network, I'd question whether peer-to-peer is the best solution, and would venture to suggest considering using an application server in between, so you could then use Cloud to Device Messaging [deprecated] (perhaps in tandem with Google App Engine). i.e. to send a message the sender passes it to the server, and the server then passes it on to the recipient.
In theory all devices on the net have a unique IP address and can talk to each other, but it's rarely that simple as routers/firewalls are configured differently so you'd need to pay great attention to the ports you use, especially considering many inbound ports are blocked by default for security reasons.
You can simply use UDP/TCP sockets. In a separate thread you set up the server-side listener socket and that's it. Of course your application has to be started first (or should run in the background all the time). Here's an example:
http://thinkandroid.wordpress.com/2010/03/27/incorporating-socket-programming-into-your-applications/
If you also need peer discovery that will make the thing more difficult.
You should also take a look at peerdroid, an open source project available here. I've been looking in to peer communication options from the point of view of having a collection of federated devices (pre-paired, if you like, similar to Bluetooth pairing); this library looks like it may give you the foundation for what you are trying to do.
If you are on your own network (for example a home or office WiFi) then you should be able to query for other connected devices. If the network you are on is not under your control (the mobile network or a public wifi) then the network will have been configured to isolate each device from everything else. In this case you will have no choice but to put a server up to act as the man in the middle. That brings its own architectural compromises - every device has to regularly poll the server or keep a connection open - unless you use Google App Engine which supports push notifications over Google's own infrastructure.
Thanks for your answer ldx but I would need peer discovery as you indicated. Some further research appears to indicate XMPP as a suitable technology and there are now some services on offer, although these appear to be aimed at 'server' to client notifications. There is a good discussion here on XMPP and some more here although it would appear that there are still some issues to deal with such as polling v push, long-running open http connections and battery life. Xtify looks promising, especially their web service. I hope this provides suitable information to others looking at the topic of peer-to-peer data communication.
Can anyone explain 3G technology from a programmer's perspective? I am a little bit confused. For instance, if I develop a mobile application with Android or IPhone SDK. Shall I concern about the network I used? Or the SDK has a same interface for all those different network(3G,GPRS,CDMA).
Moreover, is 3G a specific technology or a set of communication technology？ Is it just same as WCDMA?
Thanks.
You do not need to care about the specific protocol, but you may very well want to distinguish between WiFi and 3G, and have your program behave differently according to what is available, because WiFi is faster and cheaper. In case of the iPhone, there are even explicit agreements that certain heavy-data activities must only take place over WiFi.
Another idea would be to detect if roaming is active and warn the user about it (even though the phone should already be doing that).
I'm sure you have no problem finding definition of 3G via a web search. Here's one from wikipedia.
As a developer, your main concern should be whether the application you are developing should/must ride on top of 3G-level type of connection in terms of bandwidth and/or streaming capabilities. You might need to identify the communication layer i.e packet bearer/wifi or just older 2G (GSM etc) and so on.
You shouldn't need to (unless specifically required) really worry about the underlying technicality of it. For Andriod, the SDK should provide you with enough tools/utilities to build an application which is abstracted from the communication layer.
3G is not a single technology but a family of mobile communications standards. There are different standards in different regions around the globe. In USA CDMA is used (not sure if WCDMA as well) while in Europe WCDMA (or better known as UMTS) is used which was lately upgraded to HSPA. These are both 3G family standards.
GPRS and EDGE which are 2G and 2.5G family standards are the predecessors of the 3G family.
From the programmer's perspective the only difference between the listed standards GPRS, EDGE and 3G (UMTS or CDMA) is the connection speed.
3G relates to the speed and capabilities of the cellular network. From an API and programming standpoint, there is no difference, however the 3G network will be able to transfer data at a generally faster rate, but also consume more battery power when active.
3G is an umbrella term for multiple technologies, including UMTS, HSPA, HSDPA, EVDO. WCDMA is simply a modulation scheme, but is often analogous to UMTS when used in cellular networks (which define more than simple modulation).
To test your application on the emulator under different conditions (though not WiFi at the moment) you can use the emulator console and gsm command.
the 'gsm data <state>' allows you to change the state of your GPRS connection
valid values for <state> are the following:
unregistered no network available
home on local network, non-roaming
roaming on roaming network
searching searching networks
denied emergency calls only
off same as 'unregistered'
on same as 'home'
Alternatively from the command line:
$ adb emu gsm data roaming # set roaming
$ adb emu gsm data home # set home