Sending UDP packets from React-Native app - react-native

I have created a UDP server, and have tested it using the Microsoft UDP tool and it receives a UDP message and executes accordingly. I am only trying to send a "1" or a "2", but I need to send this to several UDP Servers nearly simultaneously (which is why I cannot wait for a response). The Microsoft UDP tool has entry for IP Address & Port, then a connect button - then I type a message and hit send. Pretty simple and extremely fast.
I can find several examples using React-Native-UDP for receiving, but I cannot find a simple example where someone sends something as simple as a "2" from React-Native to a listening UDP Server.
My goal is to cycle through 10 IP address / port combinations, sending a "1" or "2" depending on the circumstance.
I have accomplished this using HTTP Server, but it is much too slow to be useful.
Is this doable using Native-React-UDP? Will this work for both Android and iOS?

I made it work with react-native-udp. Create a socket and send the udp request. Make sure you have something like 200-500 ms between requests else they may fail.
docu: https://www.npmjs.com/package/react-native-udp
a extra tip: download one of many udp sender / receiver apps on the play and/or appstore to help you debug. Good luck!
import dgram from 'react-native-udp'
const socket = dgram.createSocket('udp4')
socket.bind(12345)
socket.once('listening', function() {
socket.send('Hello World!', undefined, undefined, remotePort, remoteHost, function(err) {
if (err) throw err
console.log('Message sent!')
})
})
socket.on('message', function(msg, rinfo) {
console.log('Message received', msg)
})

Related

onaddstream event not working when 3rd person joined the room in webrtc

I am new here in webrtc, i have strange issue, when i worked with one to one user onaddstream event is working, i am getting its response, but after then 3rd person joined the room onaddstream event is not working, can anyone please help me how to resolve this issue ? here i have added my whole code for it, can anyone please review it and helped me to get event for all the remote users
var pc = new RTCPeerConnection(configuration);
pc.onaddstream = (remoteaddstream) => {
console.log(remoteaddstream);
};
navigator.mediaDevices.getUserMedia({
audio: true,
video: true,
}).then(stream => {
var localstreamid = stream.id;
console.log("stream id :"+localstreamid);
pc.addStream(stream);
}, function(e) {
console.log(e);
});
You need multiple peer connections to connect more than 2 parties, or alternatively you can make all the parties connect to a server that forwards the data.
From https://medium.com/#khan_honney/webrtc-servers-and-multi-party-communication-in-webrtc-6bf3870b15eb
Mesh Topology
Mesh is the simplest topology for a multiparty application. In this topology, every participant sends and receives its media to all other participants. We said it is the simplest because it is the most straightforward method.
Mixing Topology and MCU
Mixing is another topology where each participant sends its media to a central server and receives a media from the central server. This media may contain some or all other participant’s media
Routing Topology and SFU
Routing is a multiparty topology where each participant sends its media to a central server and receives all other’s media from the central server.

WebRTC - how to send voice stream from chrome to endpoint via sip

experts! Issue - we have an equipment which can receive voice stream via sip. We can use standart application to do this (and it works) but we want to send voice stream from browser (i.e. Chrome)
clients and "sevrer" (means equipment) are in our local net
I've discoverded WebRTC, and tried to get MediaStream from Chrome.
My code
var constraints={audio:true};
if (navigator.mediaDevices.getUserMedia) {
navigator.mediaDevices.getUserMedia(constraints)
.then(function(stream) {
alert(stream)
})
.catch(function(err){.
alert(err)
});
} else {
alert('getUserMedia is not supported in this browser.');
}
But what should I do to send voice stream to equipment?
I know "coonection string" to equipment (e.g sip:192.168.22.123:5060)
Thanks
You need to have a signaling server which can exchange an offer and answer, as well as ICE candidates. A SIP INVITE can include SDP which can be provided to the setRemoteDescription method of an RTCPeerConnection object in the browser. Then, create an answer and send that back as a SIP 200. I recommend doing some reading about the basics of WebRTC before you post again. You really have not shown any effort on the side of WebRTC, only in capturing a media stream from the browser, which is actually not a part of WebRTC itself, only often used in conjunction. https://www.oreilly.com/library/view/real-time-communication-with/9781449371869/ch01.html

What happens to client message if Server does not exist in UDP Socket programming?

I ran the client.java only when I filled the form and pressed send button, it was jammed and I could not do anything.
Is there any explanation for this?
enter image description here
TLDR; the User Datagram Protocol (UDP) is "fire-and-forget".
Unreliable – When a UDP message is sent, it cannot be known if it will reach its destination; it could get lost along the way. There is no concept of acknowledgment, retransmission, or timeout.
So if a UDP message is sent and nobody listens then the packet is just dropped. (UDP packets can also be silently dropped due to other network issues/congestion.)
While there could be a prior-error such as resolving the IP for the server (eg. an invalid hostname) or attempting to use an invalid IP, once the UDP packet is out the door, it's out the door and is considered "successfully sent".
Now, if a program is waiting on a response that never comes (ie. the server is down or packet was "otherwise lost") then that could be .. problematic.
That is, this code which requires a UDP response message to continue would "hang":
sendUDPToServerThatNeverResponds();
// There is no guarantee the server will get the UDP message,
// much less that it will send a reply or the reply will get back
// to the client..
waitForUDPReplyFromServerThatWillNeverCome();
Since UDP has no reliability guarantee or retry mechanism, this must be handled in code. For example, in the above maybe the code would wait for 1 second and retry sending a packet, and after 5 seconds of no responses it would report an error to the client.
sendUDPToServerThatMayOrMayNotRespond();
while (i++ < 5) {
reply = waitForUDPReplyForOneSecond();
if (reply)
break;
}
if (reply)
doSomethingAwesome();
else
showErrorToUser();
Of course, "just using TCP" can often make these sorts of tasks simpler due to the stream and reliability characteristics that the Transmission Control Protoocol (TCP) provides. For example, the pseudo-code above is not very robust as the client must also be prepared to handle latent/slow UDP packet arrival from previous requests.
(Also, given the current "screenshot", the code might be as flawed as while(true) {} - make sure to provide an SSCCE and relevant code with questions.)

How to implement fire-and-forget messaging from one process to another?

At the click of a button a simple message is to be sent from one process to another, and the message would be just a simple command with string arguments, totaling something like 50 characters (definitely much less than 1k), like
DisplaySomeInfo("param1", "param2")
and satisfying the following:
must be simple (i.e. no full-blown messaging system)
must run on Windows, should run on Unix
the picture below shows my actual requirements, but it should work with any major programming language / runtime
performance is not crucial, the whole send/receive cycle should not take more than a millisecond though for such a simple message
"guaranteed delivery" etc. NOT necessary
sender does not care if a/the receiver got the message - or if there is a receiver in the first place
no encryption/authentication/authorization necessary
In wikipedia there is a long list of ways to do IPC, but the simplest one seems to be the non-connected socket option.
Are there any better ways (easier to implement/maintain/debug, more future proof, ...) to implement it than simply sending / receiving UDP packets (one message per packet, TTL=0), say coupled with a JSON (de)serializer?
For these requirements, simply sending UDP unicast packets to some port on localhost seems ideal. The only problem is that a port number has to be chosen and fixed. But if that is not an issue, simply sending and receiving UDP packets is as easy as it gets, without the need for third party libraries.
Bare-bones example for sending a UDP packet from a .Net app:
public static void SendUdpPacket(int destinationPort, string payload)
{
IPEndPoint endPoint =
new IPEndPoint(IPAddress.Parse("127.0.0.1"), destinationPort);
byte[] buffer = Encoding.UTF8.GetBytes(payload);
Socket socket =
new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
socket.SendTo(buffer, endPoint);
socket.Close();
}
The only open question is how to encode multiple parameters. But for that there are gazillions of ways, built into many languages is HTTP URL encoding.

WebRTC - Detecting if the camera stopped

WebRTC Questions
Is there an event for when the users camera stops streaming prematurely?
WebRTC can connect Peer2Peer what about Peer1 having a stream and multiple observers viewing?
Thanks
My experiment with Chrome 24 and 26 show that none of the mediastream/localmediastream or video events fire when a peer disconnects, but the (RTCPeerConnection) icecandidate event does fire several times right after the disconnect: first with the candidate and then without it on the event object.
peer = new RTCPeerConnection({ "iceServers": [{ "url": "stun:stun.l.google.com:19302" }] });
peer.onicecandidate = function(e){
if(!e.candidate) return console.log('Did someone disconnect?',e);
console.log('Someone might have just disconnected. Or maybe not.',e);
}
I've been able to connect 3 peers in chrome successfully as well: as far as I know each peer connection just connects two peers, so to have multiple simultaneous connections the host connects with each one individually.
This is what you wanted:
(await peerConnection.getStats())
.forEach((c)=>{if(c.type =='track')console.log(c)})
That will tell you how many frames have been received. Store that and then ask a second later and compare the two results. if the number of frames is the same it is not getting new data.