What is the correct way to disconnect gun peers?
I can connect peers with:
Gun(['http://127.0.0.1:8080/gun','http://127.0.0.1:8081/gun'])
But cant disconnect again using
Gun(['http://127.0.0.1:8080/gun')
as peers will still both sync. In the last part of the video I couldn't disconnect the peers as both db's were still syncing.
On a different note the first part of the video shows problems with Chrome not updating however firefox works as it should.
Video and
Source Code
#soth this is a good question. There is currently no standard way to disconnect from a peer. This should probably be added.
This is terrible. But here is a hacky solution for now:
var peers = gun.back('opt.peers');
Object.keys(peers).forEach(function(id){
var peer = peers[id];
peer.retry = 0;
gun.on('bye', peer);
});
This will disconnect from all peers. If you only want one, filter by the ID which will probably be the URL.
Related
So I'm trying to set up a 3-way video call with WebRTC.
The first two connections connect fine. I have it set up so that the third person to join the room sends an offer to the first 2 sockets in the room (I'm using Node.js socket.io as a signalling server). The offer successfully sends to both sockets, and both sockets send back their answers. Both answers contain 1 audio track and 1 video track, however, for some reason, the connection only works with one of them.
The result is that with 3 users, the first user (usually) ends up seeing both peers, and then the second and third people only see one other person. When I look at the connectionState for each peer connection, one of them is stuck in "connecting", while everything else looks fine.
Any ideas?
Are you creating a new PeerConnection for the first two people in the room? When you say first 2 sockets it sounds like you are trying to use the same PeerConnection for multiple connections.
Each PeerConnection is only for a 1:1 connection. What you are trying to create is a Mesh Topology I believe.
Using latest Chrome. As far as I can tell, everything sets up correctly. Offer/Answer..Candidates..I expected...
However, one strange issue I noticed..and I googled...found that exactly same issue I am currently noticing...
https://stackoverflow.com/questions/44157738/webrtc-sharing-one-stream-with-multiple-peers
I also have three peers. What I want is that A sees B and C, B sees A and C, and C sees A and B.
Only one peer can see the other two peers, but the other two peers only see one...
BTW, I confirmed that each peer got notified onaddstream event two times, which is correct.
Here is what I did..
Once I get the stream, I stored this to my window.localStream...
Whenever a peer connection(since I support multiple peers, I managed this with dictionary) comes in, I added this localStream by peerConnection.addStream(window.localStream)
I set up the stream in video tag in peerConnection.onaddstream ...
Once the MediaStream is active and being transmitted then, this same stream cannot be transmitted to another peer at the same time?
Any help would be greatly appreciated.
Thanks,
Sending the same stream to multiple peers should work. Compare your code to https://webrtc.github.io/samples/src/content/peerconnection/multiple/ which shows how to achieve this. Your issue sounds like you might not set the answer on the right peerconnection. Inspecting eachs connection signalingState and iceConnectionState may provide further insight.
I meet the same problem, finally find out that It's because the sdp and ice candidate of the third client always be covered, only remain single peer of third client work.
After a WebRTC session has been established, I would like to stop sending the stream to the peer at some point and then resume sending later.
If I call removeStream, it does indeed stop sending data. If I then call addStream (with the previously removed stream), it resumes. Great!
However, is this safe? Or do I need to re-negotiate/exchange the SDP after the removal and/or after the re-add? I've seen it mentioned in several places that the SDP needs to be re-negotiated after such changes, but I'm wondering if it is ok in this simple case where the same stream is being removed and re-added?
PS: Just in case anyone wants to suggest it: I don't want to change the enabled state of the track since I still need the local stream playing, even while it is not being sent to the peer.
It will only work in Chrome, and is non-spec, so it's neither web compatible nor future-proof.
The spec has pivoted from streams to tracks, sporting addTrack and removeTrack instead of addStream and removeStream. As a result the latter isn't even implemented in Firefox.
Unfortunately, because Chrome hasn't caught up, this means renegotiation currently works differently in different browsers. It is possible to do however with some effort.
The new model has a cleaner separation between streams and what's sent in RTCPeerConnection.
Instead of renegotiating, setting track.enabled = false is a good idea. You can still play a local view of your video by cloning the track.
I have a video chat application using WebRTC. There is a slight problem: Below is my code for oniceconnectionstatechage:
connection.oniceconnectionstatechange = function () {
if (connection.iceConnectionState == 'disconnected' || connection.iceConnectionState == 'closed')
console.log('connection gone.')
};
The problem is that sometimes, when the internet speed is not well, my connection gets disconnected and I see "connection gone" in my console but the sound still stays on. Both sides can hear each other but the video is gone. What can I do to disconnect my connection completely is such a situation?
You see connection gone in your console when the network connection is unstable, as iceConnectionState may have the state disconnected as
a transient state, e. g. on a flaky network, that can recover by itself.
(Mozilla Developer Network)
It might be - this is an assumption - that in some/many of such cases video is dropped as the available bandwidth can't support both audio and video.
If you really want to close the connection completely when a disconnect occurs, you can replace your if-statement (incl. the console.log) in oniceconnectionchange listerner with the following code:
if (connection.iceConnectionState == 'disconnected'){
console.log('Connection gone. Closing connection.');
connection.close();
}
So each disconnect will be followed by closing the connection completely.
However, this is probably bad practice:
Why would you want to close down the whole connection just because there are temporary problems with the network?
I assume that using this code in a real application will lead to bad user experience, as disconnects will appear in many cases the user would not notice otherwise. I suggest it is better to display a warning to the user in case of (frequent) disconnects.
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.