I've developed applications which handle a connection between a PC and an Android phone via Wi-Fi. I try to send a lot of data really often. The TCP/IP protocol, which I used, allow me to achieve just low speed - around 1 Mbit/s. I found that with 802.11n standard we can achieve speed up to 150 Mbit/s. I've set my router to use only 802.11n standard, but I didn't notice any improvement.
What level of speed should be expected? I understand that part of data is lost, but is there any better solution? Any ideas? Where can I find some information to better understand this topic?
You should expect much better performance running 11n with TCP/IP, perhaps 20 Mbit/s in a good environment. But since it is radio, the medium is shared between all users of the air so it is not easy to give a good answer that is valid everywhere.
A tool to test your network throughput is Iperf available on Google Market for your Android device and on Sourceforge. You could use this to see if it is your application or external factors that might affect performance.
If you want to debug it further, you could use Wireshark together with a Wi-Fi sniffer card to see individual packets/transmission rates and retransmission.
Related
Out of curiosity... has anyone ever been able to integrate AirDrop functionality into an Android app?
I really don't care about receiving any information on the Android side, but am hoping I can send information to the iOS side from Android. I'm hoping to find someone with a more in-depth understanding of how it works and if it is physically possible. Also, any direction on whether Apple has proprietary use over the protocol (or if it is just the name and branding) would be awesome!
Trying to build a cross-platform app and getting pretty close, but this would just extremely convenient if it works out :)
Currently, it is not possible as AirDrop uses Bluetooth to create a peer-to-peer Wi-Fi network between the devices. Each device creates a firewall around the connection and files are sent encrypted, which actually makes it safer than transferring via email. AirDrop will automatically detect nearby supported devices, and the devices only need to be close enough to establish a good Wi-Fi connection, making it possible to share files across several rooms.
Some Android devices use a combination of Near Field Communications (NFC) and Bluetooth to share files. But both Bluetooth and NFC are relatively slow compared Wi-Fi, which makes sharing larger files using AirDrop much faster and more convenient.
Regarding protocol, I don't think Apple has made it public and as far as I know Apple they must have patented it. Since AirDrop uses Bluetooth as well, and Android and iPhone Bluetooth are not compatible. Hence, due to all these reasons, we did not see any Android app that can send data via AirDrop.
I was wondering how people typically test mobile data for mobile apps. We currently only test on WiFi and that has caused problems in production. Are there services that allow us to use all of our test devices on a mobile data network? Or can we really only buy a sim card for every test device? I just think that's rather clunky, especially since we only need data and not texting or calling. Or should WiFi be sufficient?
Any ideas or thoughts are welcome.
Thanks in advance!
Typically people test apps based on data speeds used by their targeted audience but we should always use best cases on wifi/broadband and worst cases on 2G/3G mobile networks. there ary many tools and services/platorms free and paid that you can use online for testing apps on diffrent speeds they tell you everything from ping time to download time some of them are LoadRunner, NeoLoad, LoadUI or Webload and neoload i never used any of them but many of clients do use.but it's always good practice to have your own sim cards ready if you are planning to have more apps and more releases every now and then. Mark if it helps ..Cheers
You are speaking specifically about the issue of network impairment. What you are seeing is that the network you are testing on is likely both faster and cleaner than the intended network in production. Mobile devices have a longer "latch time" on the stack due to the characteristics of the network than the same application on a clean network. This higher latch time causes a higher percentage of resources to be dedicated to "ring 0" type activities, those that take priority and must be handled immediately, related to network. This means that the total resource pool that the application layer, "ring 3" activities can draw from is diminished. The net-net of all of this, you can bring down performance on a server with fewer mobile clients versus desktop.
There are a few paths here. The industry benchmark for impairment was the solution set from Shunra, particularly the hardware devices. Shunra was scooped up by HP a couple of years ago so if you want to go that route you are likely in the LoadRunner camp. With Shunra absent as an independent solution a number of players have added network impairment to their tools. I think both SOASTA and Neotys are in this camp.
There are some build your own models as well. You can use two small routers with a single line between them and then assign characteristics to this line related to speed and error rate which match the characteristics of mobile networks. You will need data for these - OOKLA is the default source for line profiles in the industry. You have what were the competitors to Shunra on the network simulation front: Ixia Communications, Spirent, Agilent. Their solution sets are much more geared at the OSI layer 2 crowd. There is also WANEM, an open source solution, but it lacks the complex modeling capabilities. Also, do not run it in a Virtual Machine - Network impairment needs a consistent and precise system clock, something that the virtualized clock in a virtual machine cannot provide.
I need to stream a set of numbers, 6 floats, from an android device to a PC, to which it is connected by a USB cable. All the solutions I have found proposes using a WiFi connection. However, I have found that the latency caused by this is not acceptable. As such I have decided that I am going to hire someone to integrate the components, thus enabling direct communication. Until then, however, I want to try a variety of devices to see what works and the quickest way to "Integrate" two devices is by allowing them to share a (US)Buss. However, this is the one field I have zero experience with.
Do you make a socket and treat the connection as a network connection or is there another fancier way to achieve what I want? I have seen some talk about making a device driver for this purpose and I do not feel like crashing my OS 500 times again. I find it hard to believe that the android devices do not have some kind of driver already made that I can exploit.
The android code is written in Java, but it could be changed depending on what people suggest. The main chunk of mys system lies on the PC and is written in C++.
I need the latency of the stream to be as low as possible since the entire system needs to be as real time as possible. The limit is 15 ms between data acquisition on the device and the rendering of the simulation on the PC.
TL/DR: I need to stream data from a program on an android device to a PC with as little latency as possible; i.e. one way communication. As long as I can stream bytes I can design protocols and translate the bytes on the receiving end. My global cap is 15 ms and I need to stream continually updated 6 floats. What is the best way to achieve this?
Thank you in advance for your help.
Raw USB is probably not the way to go. USB is a device-oriented specification and cannot be used in a general send-arbitrary-bytes-across-a-wire way.
If Wi-Fi really is too slow, you could try purchasing an Android-compatible USB-Ethernet adaptor and connecting the device to the computer via a wired network connection, which might reduce the latency. Android recognises many types of these adaptors and you communicate over the network connection in the same way as other networks.
We ended up using the ADB brigde and it seems to be stable and fast enough for our purposes. All we had to do was to open a socket and connect with TCP. For some reason it fails when we try to connect with UDP, but I assume this might be due to ignorence on our part.
I've been reading up on how to transfer data between iOS devices over Bluetooth using GameKit. I'm not writing a game, per se, but do have a need to transfer a small amount of binary data between two devices. Between two iOS devices, this is easy enough. However, I was wondering if it is possible to transfer data between an iOS device and an Android device via the same mechanism.
Has anyone come across documentation/tutorial that would explain how to do this? Is it even technically possible? Or has Apple put in some sort of restriction that would prevent this?
The other option I discovered was Bonjour over Bluetooth. Would this be a more suitable option for this type of operation?
This question has been asked many times on this site and the definitive answer is: NO, you can't connect an Android phone to an iPhone over Bluetooth, and YES Apple has restrictions that prevent this.
Some possible alternatives:
Bonjour over WiFi, as you mentioned. However, I couldn't find a comprehensive tutorial for it.
Some internet based sync service, like Dropbox, Google Drive, Amazon S3. These usually have libraries for several platforms.
Direct TCP/IP communication over sockets. (How to write a small (socket) server in iOS)
Bluetooth Low Energy will be possible once the issues on the Android side are solved (Communicating between iOS and Android with Bluetooth LE)
Coolest alternative: use the Bump API. It has iOS and Android support and really easy to integrate. For small payloads this can be the most convenient solution.
Details on why you can't connect an arbitrary device to the iPhone. iOS allows only some bluetooth profiles to be used without the Made For iPhone (MFi) certification (HPF, A2DP, MAP...). The Serial Port Profile that you would require to implement the communication is bound to MFi membership. Membership to this program provides you to the MFi authentication module that has to be added to your hardware and takes care of authenticating the device towards the iPhone. Android phones don't have this module, so even though the physical connection may be possible to build up, the authentication step will fail. iPhone to iPhone communication is possible as both ends are able to authenticate themselves.
Maybe a bit delayed, but technologies have evolved since so there is certainly new info around which draws fresh light on the matter...
As iOS has yet to open up an API for WiFi Direct and Multipeer Connectivity is iOS only, I believe the best way to approach this is to use BLE, which is supported by both platforms (some better than others).
On iOS a device can act both as a BLE Central and BLE Peripheral at the same time, on Android the situation is more complex as not all devices support the BLE Peripheral state. Also the Android BLE stack is very unstable (to date).
If your use case is feature driven, I would suggest to look at Frameworks and Libraries that can achieve cross platform communication for you, without you needing to build it up from scratch.
For example: http://p2pkit.io or google nearby
Disclaimer: I work for Uepaa, developing p2pkit.io for Android and iOS.
You could use p2pkit, or the free solution it was based on: https://github.com/GitGarage. Doesn't work very well, and its a fixer-upper for sure, but its, well, free. Works for small amounts of data transfer right now.
Through WifiManager, my Android app can get a lot of details about Wi-Fi. However I fail to get protocol type like a/b/g/n. I have a client requirement to do that.
Does anyone know how to achieve that? (I don't have the option to use adb). It is to be done programmatically. I strongly believe that device and router have already negotiated protocol before they can connect. So that information is there with device. Question is, how do we get it?
You can partially deduce the protocol from the link speed
WifiManager.getConnectionInfo().getLinkSpeed()
By Wikipedia 802.11 protocols speed table you can tell if it is 802.11b, 802.11n or 802.11ag.
802.11n and 802.11ac full link speed tables
Link speeds of protocols 802.11a and 802.11g are the same, you can distinguish between them by the used frequency (5GHz or 2.4GHz) in the scan results.
Note that protocol can change during the connection, client and access point do negotiate protocols and speeds but they agree on a list and not on one specific speed.
I don't think there is a way to distinguish between 802.11n and 802.11ac in their overlapping speeds.
I don't believe this is possible to get in a clean manner. The protocols - a, b, g, n, etc - are actually human abstractions of the MAC and physical layer in networks. These are defined as their recognizable letters if they meet certain hardware specifications, both for the device and the network device.
After doing some digging, it seems that Windows phones are able to display this information. When digging into the manner of determining the protocol on Windows, I came across the desktop explanation as well as the Visual C++ implementation via enums. It seems that even the official Windows documentation relies on vendor-provided data and enumerated values, which would lead me to believe that they need to determine hardware specifications beyond what is likely exposed in the Android API.
If you want to determine the protocol yourself, you'll need to understand the link speed as well as the frequency, modulation, and bandwidth.
TL;DR
Likely not possible unless you are working with a rooted phone and can access the hardware specs directly.