Nearby Share sometimes uses bluetooth to transfer the files because of which it is very slow. Sometimes it is not at all handy to transfer files that are more than 100 MB. Initially I thought Bluetooth is used only for handshaking purposes. But later I realized that the files are itself transferred via bluetooth. I'm curious to know why should the files be transferred via bluetooth when it can be transferred via wifi direct. A lot of third party apps including Google Files use wifi direct to transfer the files. So why does a built-in functionality like Nearby Share should use bluetooth. The sole purpose of Nearby Share itself is to achieve fast file transfer with wifi direct and without internet. So if the files are transferred via bluetooth there is no point in using Nearby Share.
I'm also curious to know the various modes of file transfer present in Nearby share. There are three modes: Data, Wifi Only and Without Internet. I'm really curious to know why is an internet connection required to transfer files when Nearby Share is meant for file transfer without Internet. Is it meant for handshaking purposes in Web RTC?
(Disclaimer: I work on Nearby Share)
Nearby Share will always attempt to upgrade to WiFi before sending files larger than 1MB. A grace period of 10sec is given for that upgrade before fallback mechanisms kick in and the file is sent over Bluetooth as a last resort. Even after falling back to Bluetooth, the devices will continue to attempt to upgrade to WiFi in the background, but some failures are unrecoverable and the file will fully send over Bluetooth. Note that urls and very small files will immediately send over Bluetooth.
This upgrade can fail for a multitude of reasons. Most commonly, it's a concurrency issue. The same radio is used for Bluetooth, p2p WiFi, and your normal access point connection and it must be time-shared accordingly. If all 3 want to be on different channels, you will miss messages -- it's a guarantee. If these messages are important, such as the authentication frames when connecting over WiFi Direct, then the connection will fail. If these messages are less important, they may be resent until successfully received, but it will lower throughput for the transfer such that even 5GHz WiFi can look to be as slow as Bluetooth.
Nearby Share tries to avoid this in a few ways. When regulations allow, we will attempt to start the WiFi Direct group on the same channel as the access point. This way, the phone doesn't have to timeshare (although it does have the side effect of colliding with messages from the access point. But generally, both sides will back off a random amount and retransmit, and the loss is less than the loss of multi-channel concurrency). Unfortunately, many countries do have regulations that allow certain (or all) 5GHz channels only indoors -- in those cases, the access point can be set up to utilize it but WiFi Direct cannot.
We also prefer mediums like WiFi Direct over Hotspot, as WiFi Direct commonly uses CTS2SELF frames to advertise "Do not transmit for this duration". Unfortunately it's not as straightforward a message as "I am going off channel, do not try to communicate with me" -- CTS2SELF has the side affect of quieting all communication over the access point even if it wasn't directed to the phone -- but it does get the point across.
We pause any Bluetooth activity we have control over, to reduce the need to timeshare with it. In some severe cases, where the OEM has implemented timesharing that's too aggressive, we will turn off the Bluetooth radio to forcefully interrupt Bluetooth activity, but this is disruptive and usually a bad user experience.
We may try to send the data over your access point itself instead of setting up WiFi Direct. This can avoid the MCC situation described above, but comes at the cost that the data needs to be re-encrypted (because we don't know what other devices are connected over LAN and might be eavesdropping), and it does introduce another hop, as the data needs to go through the AP even if the devices are side-by-side. TDLS helps avoid that last issue, but it has limitations (eg. it won't use 40/80/160MHz bandwidth if the AP isn't set up for it, and it'll send over 2.4GHz if the AP is on 2.4GHz).
Other possible failures include the device getting into a bad state (toggling airplane mode can help here), the Android version being too low (ideally both devices should be R+, as it's almost impossible to fix bugs on older Android OS versions, even though we try), or just bad luck.
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 have made an app on iOS and Android that can connect to a BLE device. I connect to the "device by service" and things work well.
A customer is asking me why the device is not showing in the list of bonded bluetooth devices. I didn't need pairing to connect because I found code that didn't require it, but now that I think, I wonder :
What would be the benefits to have a paired device ?
Would it connect faster ? Hold connection better ? ...
Security, mainly.
Sending data to a non-paired device requires that the device be discoverable and open to receiving data from random devices. This isn't always the case for reasons of security, and so many devices ship with both disabled.
The attack vector is something like this: you'll always have to pick a device in the list of discovered devices. It's not too difficult to create a device with "<CEO>'s iPhone" as the name and wait until he tries to send the secret memorandum to his iPhone, then intercept it.
Additionally, bluetooth stacks have been known to have vulnerabilities that can be exploited by sending data to the device, which was made more problematic by devices auto-accepting data without confirmation.
Paired devices create a pre-existing relationship between the two, allowing your user to be notified when something out of the ordinary happens. This is always a good thing.
It is indeed also true that not having to go through device discovery (which may take up to a few seconds) improves performance when doing the initial connection setup, but I wouldn't see that as the major reason.
How can a device identify the other devices to whom we need to send data and transfer the data to other device.
If the device1 send the data to device2, will other device say device3 near to them will receive same data?
Please read up on the whole Bluetooth story. You seem to have problems with basic concepts. Also, it would probably help to be a bit more specific in your questions for example specifying which BT version are you referring to.
For identifying the devices, each of them has a separate address. They even have human readable names. (Look at the Wiki page linked above Connection and communication) Also, during the pairing process, you should have to get to know and explicitly allow the devices which you really want to communicate with, the goal of the process is exactly to make sure to have an explicit authorization between the devices for communication.
Yes, device3 will receive the radio signals, but if not authorized, it won't be able to tell what is going on - unless it is a misbehaving device cracking the encryption... (Given the communication is actually encrypted, that is.) Reading the Security Concerns part is also useful.
Bluetooth can connect up to eight devices simultaneously. With all of those devices in the same 10-meter (32-foot) radius, you might think they'd interfere with one another, but it's unlikely. Bluetooth uses a technique called spread-spectrum frequency hopping that makes it rare for more than one device to be transmitting on the same frequency at the same time. In this technique, a device will use 79 individual, randomly chosen frequencies within a designated range, changing from one to another on a regular basis. In the case of Bluetooth, the transmitters change frequencies 1,600 times every second, meaning that more devices can make full use of a limited slice of the radio spectrum. Since every Bluetooth transmitter uses spread-spectrum transmitting automatically, it’s unlikely that two transmitters will be on the same frequency at the same time. This same technique minimizes the risk that portable phones or baby monitors will disrupt Bluetooth devices, since any interference on a particular frequency will last only a tiny fraction of a second.
So what if they interfere and there is a erroneous data, the receiving system simply discards it based on correcting bits of the packets transffered.
Bluetooth devices have a parameter or option called visibility. When you enable visibility, then the bluetooth device starts
publishing its presence within the bluetooth frequency range. This presence can then be detected by any other bluetooth device which can connect to this device when
it scans the above bluetooth frequency range.
As they use spread-spectrum frequency hopping described above they
publish data to all receivers but only the intended receiver with whom
the sender is connected will have the key to unlock the data.
This is sort of an odd question, but I know it is possible.
I am trying to broadcast packets over a specific frequency and I want a phone running an application to pick up on these packets. The phone will not need a connection to any network to do this, but simply have it's wifi turned on. The broadcasting device does not need to get any information back from the phone and delivery of every packet to the phone does not need to be guaranteed, much like UDP.
Where do I start? Is this possible for phones without rooting them. Is there some kind of FCC regulation against doing this (over the standard wifi spectrum).
I know this is possible because it's exactly how routers tell a phone they are available to connect. Thanks in advance for any input.
I'm not familiar with iOS development although similar techniques may exist.
Without root
But requires coarse- and/or fine-grained location permission on Android
You can use WifiManager.getScanResults() to scan for wireless router broadcasts.
The network "name" (SSID) and router MAC address (BSSID) are included in the results. You could broadcast these packets and encode data into these fields.
That said, I hope your messages are short as you'll be getting 38 bytes per packet (32 SSID bytes + 6 MAC address bytes).
Yes, some MAC addresses are special or invalid, but if you're just broadcasting and not actually using them, they can still transmit the data.
With root
Depending on the wireless chipset and driver support, you may be able to put the device into "monitor mode" which gives you access to the raw packet data.
The main drawback is that there is no official support for it.
You might find some hacky ways to do this from a Google search but I wasn't able to find any universal solution that works on all (or even most) devices.
I'm currently working on an android project and I am trying to find the best way to go about setting up communication between two android phones.
One android phone will be docked on a mobile platform e.g. an R/C car. I want this phone to receive simple control signals ("forward", "backward", "left", "right", "gotoCoordinate") sent from another android phone. I also want the docked phone to be able to return status signals.
Preferably I want the communication to happen via GPRS. I'm aware of the difficulties concerning P2P-communications and I'm currently looking into "Android Cloud To Device Messaging." (http://code.google.com/android/c2dm/index.html)
I'd like to hear about your experience with Android C2DM (glad to hear about delay from transmit to receive) and your thoughts on utilizing it in my project. I'd appreciate other suggestions on how to go about this. I'm expecting to have to deal with relatively high latency using this method, but of course preferably lowest possible.
C2DM makes no guarantee about the "delivery or order" of the messages, and it is limited in the number of messages you can send (a high limit, but still a limit). It's not really for low-latency stuff like controlling an RC car. It's better for non-realtime events.
http://code.google.com/android/c2dm/
For lower latency stuff using GPRS you can setup a third party server on your own and have both phones communicate through it. I've done that for several Android apps using straight up TCP sockets and it works reasonably well (and it would be even faster/better if you went UDP). Using GPRS may still have too much latency, depending on your needs, but it's a tradeoff (it's very convenient, almost always there, other methods are not).
The ideal way to do this would be to combine whatever is available and fallback gracefully, and test the latency once connected to make sure the network is up to par, or bail out. For example, use the local WiFi network if it's available. That is to say, have both devices "register" with a third party server as they startup, then if they're both on the same WiFi just have them communicate directly (run a server on or both, and clients on one or both, get information about discovery and such from the registration). If they are not on WiFi then fall back to GPRS, but realize there will be more latency, of course. Finally, once any method has been established send some test messages to check latency.
I know this isn't really an "answer," it's more of a stream of consciousness about this, but it wouldn't fit in a comment, and I thought it might help ;).
(Full disclosure: I've worked on Android apps that connect multiple mobile devices and multiple TVs, some over GPRS, some Wifi, some directly. I work for a company (MOVL) that makes a platform for stuff like that, it's more focused on mobile-TV-mobile, but it supports mobile-mobile also. In all it's not too hard to do yourself with regular networking, the tricky part is getting the latency down and picking the correct method for each device.)