I have an app which continuously sends data in multicast socket after joining to a specific IP group. After sending packets for few hours, all of a sudden it stops sending data. From java socket send is successfull but there is no packet info in tcpdump as well as network packet capture. I have debugged till datagramsocketimpl class, there doesn't seems to have any problem. Suspecting the problem some where after that. Has anyone seen this issue? The data packet just doesn't reach wifi driver. The issue happens randomly no specific procedure.
Related
How we can read or receive Broadcast message in Android WiFi network sent from Same network (Router) using UDP packets . I am trying to use MultiSocket and socket for receiving Packets, but I am not able to get Broadcast message sent from Network.
Also I am testing the broadcast message Wireshark. Its working fine, but I am not able receive packets on Android Device.
So my question is how we can achieve this?
Thanks in advance!
I have a game which uses GPGS Realtime Multiplayer on Android. Everything works fine when I don't use the in-game notification for invites. If I use it, it works only the first time after the game is launched. Afterwards, a player is able to reconnect, but the host does not receive the packets which are being sent from the other client. The other client does receive packets which are being sent from the host.
I keep thinking that the other client must be sending packets to the previous room or something. If I log the packets being sent, I can see that they are being sent, but the host does not receive any packet from onRealTimeMessageReceived().
If I restart the other client, and keep the host running, it will work. But if I restart the host and keep the other client running, it will not work. The issue must be on the other client.
Any ideas?
Turned out I was setting the Room ID variable only when it was equal to null. Which means that it was only setting it one time, and still sending the messages to the previous Room ID.
I want to create a voice chat application in pure java socket programming.
I used UDP protocol to transfer recorded voice from one client to another but when i test it over the internet voice is not comming continuously.
As i am new to this voice chat application, someone may suggest what should i do for getting continuous voice.
The Scenario is like this.
Flow of voice chat as this shows only one way communication-
FLOW of data
Client1------------------------------>> Server ------------------------------------>>Client2
Client1:
Reading 1KB voice buffer from TargateDataLine then create a voice packet and sent to server.
Server: Receive from client1 and then send to client2.
Client2: Receive the UDP packet and get voice data then play.
Also facing the bandwidth up and down problem.
What should be the minimum bandwidth to use voice chat. Ex- skype required 30KBPS udloading/downloading speed.
Thanks in advance.
In order to establish a connection between two or more users for peer-to-peer communication you need a signaling server as well as STUN/TURN servers.
You can code your own ones or use a ready backend solutions like ConnectyCube and concentrate on client-side implementation. Here are some WebRTC video chat code samples for your reference as well.
You should send the packets directly between the clients. The relaying of packets through the server is adding more delay to it. Simply send it from client1 to client2.
The Answer is pretty simple you should use tcp protocol. Coz udp sends the packet but doesn't ensure that the packet was received by the target. but tcp protocol ensures it and you will get a stable connection with cost of some speed reduced in transfer of data.tcp vs udp
I'm working on a project for class using Java and UDP senders and receivers. The premise of the problem is to read in a text file, store the contents within a packet, send the packet, receive the packet, and read out the file on screen and create a new text document on the receiving computer of an identical text file.
I have all of that working. When I test with a local host it appears to work 100% of the time. When I send it from my laptop to my PC it appears to work 100% of the time. However, when I send it from my PC to my laptop it does not work.
I have several System.out debug statements to verify some of the information I send. I know that the text file should take 7 packets. However, whenever I send it from my PC to my laptop it says that I am sending 46 packets.
My initial thought is that maybe the packets are being sent out of order. The first packet I am sending indicates how many packets the receiver should be expecting to receive. I thought maybe for some reason the "46" could indicate a capital "F" so I removed all the capital "F" and it still says I'm sending 46 packets.
I thought maybe I was sending too much information at once so I used Thread.sleep() to give my receiver time to keep up -- that did not work either.
Finally, I read through the Oracle Documentation and some posts online and found out that UDP is unreliable. So, I'm assuming it could potentially be that. However, I want to just verify that that could be the issue.
Or if anyone has a better idea as to what could be causing the problem that would be awesome as well!
Thanks for your help :)
Yes, UDP is an unreliable protocol. UDP messages may be lost, and neither the sender or receiver will get any notification.
The 7 packets becomes 46 packets is typically due to fragmentation at the IP packet level. The protocol level beneath IP (e.g. physical ethernet packets, wifi packets etc) typically has a hard limit on the largest IP packet that can be sent "in one go", and similar limits are imposed by network routers, gateways and so on. If an IP packet that is larger than the limit is sent, two things can happen:
The IP packet may turned into "fragments" that need to be reassembled by the receiver.
The intermediate equipment can sent an ICMP message back to the sender telling it to send smaller IP packets.
In either case, the net result is that the number of IP packets needed to send a given sized UDP message can vary, depending on the network.
Of course, if a UDP message needs to be sent as multiple IP packets, AND there is local congestion in the network, that will increase the likelihood of packets, and hence messages failing.
But the bottom line is that UDP is not reliable. If you want reliability, the simple solution is to use TCP instead.
I wrote a desktop java program to talk to the server I'm trying to reach and got it working. I can send and receive UDP packets. I know what to port what I've done to android. I've been messing around with the Android Emulator for a couple days and ran into an issue with receiving UDP packets. If I start my app, make the connection to the server, then redir the port I'm using, I get ~130 packets that come in and then nothing ... I used WireShark to make sure the server was still sending packets and it is. Is there something like IP Flood Detection on the Android's Emulator?
EDIT:
spelling
The server is connected to a switch that my dev computer is connected to.
The server is responding to my packets that I send from the desktop app.
The server is sending the packets to the dev comupters IP address.
The redir command I'm using is "redir add udp:port:port"
When I issue the redir command, I get the ~130 packets with a from address of "10.0.2.2"
I've tried "adb forward udp:port udp:port" and get "cannot bind to socket"
The server's IP from outside the emulator is "10.10.0.100"
EDIT
The server is not on the emulator or another android device
I did a test with similar setup and got the same behaviour.
Sending a UDP packet per second after aprox. 130 packets the receiver running in the emulator stop receiving packets, and I confirm that the packets kept being sent.
I've made the test above in emulator using SDK 10 and SDK 15, both running in Intel Accelerated Execution Manager.
It looks like a bug in the emulator redirection functionality, or as you suggest, some type of network flood prevention.
I bought a Nexus 7, ran this app I've been working on and can receive 3000+ packets. Looks like its something with the emulator.