Pass data from peer to peer without collection?

[kiran2020]

I am trying to pass data from one peer to another peer using meteorjs without creating any collection? I found meteor stream for achiving this task but it doesnot work in meteor 1.3. How to solve this problem?

[michaelcole]

Passing data through a collection is easiest. Peer-to-peer is WebRTC, but it’s not supported by all browsers. Socket.io might be an interesting alternative for you.

[kiran2020]

@michaelcole I am writing code for SIGNALLING SERVER for webRTC. For that I have to solve this problem. I got one package named “Streamy” which helps to use Sockjs(meteor internal websocket) but there is no good documentation for this library. Is there any alternatives.

[smeijer]

I got one package named “Streamy” which helps to use Sockjs(meteor internal websocket) but there is no good documentation for this library. Is there any alternatives.

Do you mean yuukan:streamy? Because that package is quite well documented, and has a pretty good demo app.

[kiran2020]

@smeijer Okay, thnx for demo link.

[diegoolivier]

I use meteor collections with their connection set to null. It gives you a collection that allows you to push information for the server to the client but doesn’t save it in mongo. And I manage the client -> server -> client link.

[robfallows]

You could check out the meteor custom protocol package.

[kiran2020]

@diegoolivier Thnx, for you help!

[kiran2020]

@robfallows Thnx, for your help!

[jam]

@robfallows Thanks for the tip! I’d appreciate your insight on how meteor custom protocol compares to using new Mongo.Collection('things', {connection: null});

@omega would love to hear your thoughts as well.

For more context, I’m building a lightweight walkie talkie and am looking to send the audio data in chunks as it’s being recorded. I’d prefer not to go full on WebRTC if I don’t need to.

Ideally the solution would let me send audio blobs in chunks to other specific connected clients with no need to store the audio blobs on the server.

[menewman]

For more context, I’m building a lightweight walkie talkie and am looking to send the audio data in chunks as it’s being recorded. I’d prefer not to go full on WebRTC if I don’t need to.

@jam - Out of curiosity, why avoid WebRTC? Sending audio data from peer to peer without going through the server seems like exactly the kind of thing that WebRTC is built for.

Of course, you’d have to figure out a signaling mechanism regardless, but you could do that using one of the mechanisms above while leaving the high bandwidth traffic to WebRTC.

[jam]

Good question. The use case I’m trying to solve for is a short, 1-many audio broadcast to specific connected clients.

1. I’m not sure what I’m going for really requires WebRTC and its associated overhead – e.g. setting up STUN/TURN servers.
2. Speed / low friction is important. IMO, WebRTC presents friction for the user because of the time it takes to initiate the connection.
3. WebRTC seems pretty involved / has lots of edge cases to the point where I think I’d probably be better off going with something like jitsi rather than trying to implement myself. If someone has experience implementing WebRTC in Meteor though, I’d love to hear how it went.

[menewman]

Yeah, that makes sense! I don’t want to derail the question you’re actually asking with discussion about WebRTC since you said you want to avoid if possible, but I just wanted to offer a little perspective on those points:

1. Twilio offers NAT traversal services (i.e., STUN & TURN servers as a service so that you don’t have to set them up yourself) that aren’t all that expensive, especially if you don’t have to use TURN a lot.
2. In my experience this amount of latency is not noticeable (signaling happens very fast), but it may depend on your use case, especially if you think you’d be creating a new connection with every walkie-talkie burst instead of using persistent connections.
3. This is totally fair, and Jitsi might actually be appropriate for your use case. (Although, subjectively, I think using XMPP for signaling is awful.)

We use WebRTC for video calls in our Meteor app (and we implemented it ourselves without using Twilio’s video chat API or something like that), but we set up signaling through a separate Socket.io server that we already have running for unrelated reasons – because there’s no need for signaling to go through Meteor collections, which is similar to the actual question you were asking above. It works pretty well and honestly wasn’t that painful to set up (maybe a week of development?), but to be fair our use case is more “regular” and we had some prior WebRTC experience on the team. We mostly are supporting 1-1 calls or mesh conference calls with just several users, so that is a little different than using it to broadcast audio from one client to multiple others like you’re describing.

[jam]

Thanks for the insight and sharing your experience! I’ll have to check out Twilio’s offering and do some more research.

Out of curiosity, any reason why you went with Socket.io for the signaling vs something else? Would you still make the same choice if implementing now?

[menewman]

Mostly it’s just because we were already using Socket.io to manage something similar (but unrelated), so it was already an available option for us. If we were implementing now and didn’t already have that, I might consider signaling through a Meteor collection using pub/sub – even if it goes through Mongo the latency for the signaling step only is probably not a big deal (and we could add a TTL index to the collection so that old data gets cleaned up) – or maybe using one of the other options mentioned above.