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!
Related
I have some iOT devices , currently i am creating tcp socket connection one by one to all of the device, all devices are connected to my local wifi.
Is it possible to send one command to all devices at a time, like a broadcast pattern? Is it possible to send and receive broadcast message in android?
Yes you can send broadcast message to all your device connected on to your network. But for that you need to understand broadcast IP address of your subnet / net. Which is something like 255.255.255.255.So get your subnet mask first and your ip address. Once you have both find your NETWORK Address. Do a search how to calculate network address from IP address and Mask. Once you have Network address do a search about how to get broadcast address. Now when you have broadcast address you need to create DATAGRAM socket (UDP) with the broadcast address. All your IOT devices must be listening on that UDP socket. So once you send your data to this UDP socket all your devices on the network will receive that message.
Check here for java based implementation
Check here for how to get broadcast address from ip and subnet mask
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 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.
I have a SMS Sender & Receiver MIDlet with MessageConnection created in Client mode for sending SMS to a particular destination on a particular port. This destination is sending back an ACK SMS without any port number set, to my device inbox. My MIDLet is listening on a same port number used for sending SMS. Problem is MIDlet is unable to listen & process this SMS. The message always goes & sits in the device inbox. Is there any way to listen to SMS without any port number? or route the SMS to the MIDlet?
No. It is not possible to receive SMS on the standard port with JavaME.
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.