I am facing weird problem in receiving udp packets on Sony Xperia Z tablet. My application didn't receive many udp packets. So I have rooted the tablet to install the shark app and captured the network traffic using shark app after rooting the device. When I analyzed the report, the device has received all the packets but my application did not receive many of them. If the application didn't receive any packets, issue could be the packet filter which blocks broadcast packets. Here, my application receives few packets but misses packets received by device. I have not observed this issue with samsung tab 2 and motorola xoom tablet where it receives all the packets. It sounds like there is no code issue. Have anybody faced similar problem? Let me know if you have any suggestions or inputs that I can try.
UPDATE:
I have added my comments below.
I'd tell you a UDP joke, but you might not get it.
Packet loss is a documented feature of the UDP protocol.
UDP protocol does not guarantee that the package will be delivered to the addressee.
http://en.wikipedia.org/wiki/User_Datagram_Protocol
I have found why my app missed some packets received by device. I have set datagram socket receiver buffer size to small value. I removed this code setting buffer size and then it strated receving all the packets. By default, android sets buffer size as 163840B but I set the size to 64 bytes. It is working fine with default buffer size set by android.
Related
I am building a UDP-based audio streaming system and face a weird behavior with two different Android devices, that I do not understand at all.
I have a server broadcasting UDP packets on my local WiFi to 192.168.178.255. The Android app listens to these broadcasts using a DatagramSocket and receives the packets just fine. A MulticastLock has been acquired, but the app stays in the foreground, so this shouldn't matter.
However, after a seemingly random amount of time (around a few minutes) the app stops receiving the broadcasts. Weirdly enough, this does not only affect my own app, but also any third-party tools which can listen to UDP broadcasts. UDP packets addressed specifically to the device are still received. The device will no longer receive any broadcasts until I disable and re-enable the wifi connection.
What's even more weird: The test packets I send have a sequence number, so I can keep track of the last packet the device has received. I am running this test on two different devices (a Huawai FIG-LX1 phone and a Fire-Tablet) and the devices stop receiving packets at EXACTLY the same packet. I am looking at the network traffic on Wireshark and I can see nothing special about this packet or anything happening on the network.
Any ideas what may be killing broadcast reception on two completely different devices in this way?
Unfortunately neither of the devices are rooted, so I cannot run a network analyzer directly on the device, to determine if -for example- the router might not be forwarding the packets anymore.
I am quite aware that udp is not a reliable protocol.
But I see some difference in reliability when I test it with an android device and a laptop.
For example, I have a device that sends udp packets and I am doing a receiving test with a laptop and Android. When testing it with a laptop(a simple udp receiver written in c++), there are merely no losses. Almost no loss occurs.
But when I test it with an android smartphone, the loss rate dramatically increases. About 10% of packet loss occurs.
Why am I resulting in such difference? Is this just a difference of capacity caused by hardware spec?
I'm using the USB host abilities of Android to communicate with my hardware. My communication is done through a CP210X usb to serial chip, and I'm using the driver provided here. My device is a Motorola Xoom running Android 4.0.3.
Everything for the most part works fine. I'm able to send any amount of arbitrary data and the device on the other side of the CP210X chip gets it just fine. We use a request/response protocol, and rarely send any more than about 200 bytes in a second. The other (device) side is able to send me data, and everything works until the amount of data it sends me is longer than 20 bytes. If it sends me 20 or fewer bytes, I receive it normally. However, as soon as the amount of data that it sends me is 21 bytes or greater, the packet never gets to me. UsbDeviceConnection's bulkTransfer never reports anything different happening, as it's return value is always -1 on timeouts anyways. My bulkTransfer timeout is 100ms, which should be plenty of time to transfer such a small amount of data.
In an effort to see if it was an issue with my CP210X chip, I swapped it with an FTDI serial to usb, and experienced the same issues. That really makes me worry that the issue I'm facing might be in the usb drivers on my device. However, I also noticed the behavior when trying it out on a Samsung Galaxy S3, so that's got me very confused.
Is there anything I'm missing or doing wrong?
I have problem with socket communication - > SIP server and android devices.
I can’t send SIP packet over TCP bigger than 800 bytes.If the packet is < 800 bytes everything is OK. There is a successful TCP handshake established before try to send SIP packet and still nothing.
I send the data like this way;
Socket socket = new Socket(ip,port);
OutputStream out =new OutputStream(socket.getOutputStream());
out.flush();
out.write(msg);
There is no problem with send function. Strange thing is that some packets are delivered to server minutes after being send from devices for SIP packets > 800 bytes.
If we try to send other data not SIP with size of packet > 800 bytes everything is OK and server receives it. The problem is only with SIP packets > 800 bytes. This problem happens not for all android devices. For example:
Galaxy s plus – problem.
Nexus 4 – problem.
Nexus s – no problem. and etc.
The issue is resolved if I split the SIP packet at two parts, however I would like to find out why SIP data isn’t flushed and other data is sent immediately. There shouldn’t be any difference.
You didn't provide information about versions, but I bet you have the problem in Android's 4.0.*.
I also bet the problem only happens when you use the port 5060 over TCP.
That is a known problem in those Android versions, and the current workaround is either to update to Android 4.1(and you can't ask users to do that!) or to avoid those settings.
Any other port or UDP will work.
You can find here one bug report.
I'm running some code on the nexus one - and I am having a very strange issue. The "server" sends UDP packets out on the multicast socket that the phone is joined to. The phone receives and sends stuff to the multicast group fine, but it appears that the phone chokes when it receives a large number of packets at one time.
For example, the server will occasionally send out 80 or so 512 byte packets in one go around. The phone starts receiving the packets, but then at the 31st packet (~16KB of data) the receive hangs (indicating that there is nothing on the socket anymore.) I've done wireshark testing and stuff so I know for sure that the packets are not being lost. Even if some are being lost, it is very strange that EVERY test produces the same result --- a large amount of data gets jammed onto the socket at one time, but the socket only allows me to socket.receive() for 16KB worth of data.
I have tried socket.setReceiveBufferSize() with a variety of values (up to 1MB) -- but that doesn't seem to work. Interestingly, a call to getReceiveBufferSize() tells me that the socket should hold roughly 100KB worth of data.
If I tell the server to slow down its send method (which I cannot deploy, I can only do that for testing purposes) - everything works fine, presumably because the packets aren't jammed onto the phone's socket all at one time (ie. I tell the server to wait 1/2 a second between packets.)
Has anyone else experienced this - if so - how did you get around it? I cannot switch the application to TCP.
Thanks!
Dan
PS. The Java code works fine if I run it on a regular machine...
Nevermind - I fixed it by moving onto a closed network where there is 0 possibility for loss and weird things -- not sure what was up with the network I was on (which was supposed to be goo) - but at least it works!
Dan