search

muaz-khan / WebRTC-Experiment

WebRTC, WebRTC and WebRTC. Everything here is all about WebRTC!!
https://www.webrtc-experiment.com/
MIT License
11.71k stars 3.95k forks source link

Running video-conferencing without firebase #27

Open Mumin opened 11 years ago

Mumin commented 11 years ago

Hi Muaz,

I am trying to run your video-conferencing example and replace Firebase with my local node.js server. As your example makes use of the Firebase API I am wondering whether you have already a node.js wrapper around socket.io that will run with the video-conferencing example?

I saw your other experiments with socket.io and node.js but that doesn't seem to provide a suitable implementation for the API.

Thanks in advance Mumin

muaz-khan commented 11 years ago

Primary focus of my experiments is multi-users connectivity; which causes reusability and results a dynamic nature.

Because everything is dynamic; that's why my experiments' main requirement is dynamic channels or in simple words dynamic namespaces.

So, what’s the easiest and most suitable solution to write dynamic namespaces in socket.io over node.js?

I know signaler.js is not well written; do you know any other better solution?

I know signaling implemented in my all experiments are hard to understand because of their complex implementations. A lot people complained about it. But I don’t know how and what is the easiest method of writing signaling code?

Did you try this? It is using my own socket.io over node.js implementation. Source code of the demo available here.

Mumin commented 11 years ago

Thanks Muaz for pointing me to the subdirectory using socket.io and node. These examples do work for me now. I have simplified signaler.js a little by using express and standard socket.io.

BTW, the file transmission via WebRTC is extremely slow with all these small chunks. Is there a way to accelerate that by larger chunks or is it a principal problem with this standard?

muaz-khan commented 11 years ago

RTP i.e. unreliable unordered UDP-like data channels are implemented on chrome; where some big issues are:

  1. Multi-channels ignorance
  2. Single message's length (about 1200-to-1400 chars)
  3. Non-Binary type

etc..

Chrome ignores longer or non-compatible messages. That’s why objects like FileReceiver, FileSender, TextReceiver and TextSender are used to support it a little bit.

imomin commented 11 years ago

Muaz, What do you think about this? https://github.com/muaz-khan/WebRTC-Experiment/issues/38#issuecomment-18808784