W3C home > Mailing lists > Public > public-webrtc@w3.org > March 2013

Re: Client/server (non-p2p) video

From: Kevin Day <kevinday@gmail.com>
Date: Sat, 30 Mar 2013 23:41:50 -0500
Cc: public-webrtc@w3.org
Message-Id: <0229BBE7-7CDB-41D5-B77B-AA2774800A73@gmail.com>
To: cowwoc <cowwoc@bbs.darktech.org>

On Mar 30, 2013, at 10:48 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:

> 
>    I second Kevin's motion. We need a more thorough discussion of how to model a client-server chat, especially in light of the fact that this is needed for multi-party chat (ideally you one the server to act as a gateway for the conversation, otherwise you end up with N-N links).
> 
>    Node.js is great and all, but I don't plan on using it to run in production. I'm looking for a solution that will allow me to run a single server that will handle both normal web content, and WebRTC streams. Running two separate servers is not ideal. Are there plans to offer better integration for Java-based web servers who wish to act as WebRTC peers?
> 
> Thanks,
> Gili


Thanks for making my point more clear.

Node.js is great, but won't scale to the levels we need. We have applications using Flash right now where one broadcaster can have tens of thousands viewers using a hierarchy of servers. I'm not suggesting that a server be part of WebRTC's goals, but before anyone starts writing a server it probably needs to be discussed.

There was talk early on that peer-to-peer and client-server were going to use two different protocols. I haven't seen this mentioned since though. Looking at the protocol for how peer-to-peer works, this is probably usable as a client-server protocol, but if that's the case then it probably should be stated somewhere that this is the path for server communications. 

There's probably a level of due diligence that needs to be done to make sure that this is currently and remains possible too - ideally the server won't have to transcode anything to make sure that different versions of encoders and decoders remain compatible with each other, so the same stream can just be replicated to all clients. Clients need to be able to jump into the middle of a stream with minimal work on the server's part, etc.


-- Kevin
Received on Sunday, 31 March 2013 04:42:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:33 UTC