.NET and WebRTC – not what you thought it means.
WebRTC frameworks are interesting. Each one of them takes a slightly different approach, ending up with a different set of features and customers. They are also the basis of a healty WebRTC ecosystem.
When I had the chance to chat a bit with Magnus Thor, Co-Founder/Developer of XSockets.NET – I immediately seized the opportunity. You see, XSockets.NET is actually a framework for web sockets and the real time web that predated WebRTC. Adding WebRTC to it, made it interesting enough for me to look at it, but also to a lot of developers who might be on a lookout for a .NET framework to handle their real time comms service.
Here’s what Magnus had to say about WebRTC and XSockets.NET.
What is XSockets.NET all about?
XSockets.NET is a realtime framework for .NET & Mono – thats an extremly short version. I’ll try to explain it without becoming boring and not to sound like a sales person.
It’s a wide range of components for building real time applications primarily by using websocket through an abstraction layer. The framework is completely plugin based and adopts common design-patterns such as MVC and MVVM, both out of a client and server perspective. The major benefits of XSockets.NET is the plugin based arcitecture, state-ful controllers and the different client libraries that we offer.
The goal has since we started the project been to create an intuitive API for both server and clients.
During early 2011 we started to experiment with WebRTC. Since our first look at
the specifications for WebRTC we saw it as a natural part of a real time framework such as XSockets. As we already had an architecture and infrastructure that simplified i.e signaling and brokering in place it was quite a quick job for us.
So, XSockets.NET is all about enableing, simplifying any realtime communication.
What excites you about working in WebRTC?
I would say that the P2P connectivity is what excites me most, it brings enormous possibilities .
It’s easy to say the possibility stream audio & video, but I actually go more for the Page to Page communication in general.
Where do you see the main value of WebRTC?
A short answer? By being given the opportunity to embed rich real time communication that flows page-page (p2p) in a standardized way we can build services beyond our imagination.
The longer version:
As many web applications today circuits around collaboration we can via WebRTC add yet another dimension to them by combining video, audio and regular messages and let this flow Peer to Peer (Page to Page) . Also based on the fact that things run Peer to Peer and don’t necessarily involve a middle more that in the initial phase will bring benefits such as speed (reduced latency) and security.
As we reduce our heavy dependence on the plugin and external services by using WebRTC we can actually start focus on the correct thing – our business!
Backend. What technologies and architecture are you using there?
We are using our own technology (XSockets.NET). The solution is really simple… The signaling is solved by a simple XSocketsController. The controller acts as a broker and ensures that signals are sent and that the Peers are able to connect etc. The peerbroker is open-source and the XSockets.NET platform is free to use.
Why .NET and not Node.js?
The development of XSockets.NET on the .NET platform started even before WebRTC was announced.
The platform (.NET) needed a real time framework that could co-exists, integrate and leverage the power of the platform as a whole.
Node.JS and the hype around it is impressive and i envy the community around it . I would be a moron if I say otherwise. We, the team of XSockets.NET think the idea is great and bring much good.
As there is a need of extending, boosting or integrating existing applications with any real-time service we need to find value in what we do – no matter if it’s NodeJS or .NET.
XSockets.NET brings a high grade of interoperabillity – something that we see as missing on the Node.JS stack.
What is the business model you have? How do you bring food to the table?
XSockets.NET is free to use and many parts such as the WebRTC API’s and componets are open-source. Clients pay us for education, support and we do lots of consultancy services around XSockets.NET. We also see an increase in donations, especially coming from the WebRTC angle of XSockets.NET.
As we have been in the game for a while we also teach, speak and brag about HTML5, ASP.NET and what we do – People also pay for that 🙂
Where do you see WebRTC going in 2-5 years?
Good question again, hopefully we will see a wider support for WebRTC and that the number of flavours is limited as this is a risk for the technology itself we hope that all the “vendors” focus on following standardizing work. That is what we hope but to speak frankly I think the risk of sprawling and messy implementations are imminent. Politics, protectionism and selfishness probably will cause some trouble during the next few years. But I hope that I am completely wrong on that subject!
If you had one piece of advice for those thinking of adopting WebRTC, what would it be?
During our time on the “real-time-scene” we often heard the phrase – “We’ll wait a while..” . Our advice is to start adopt the technology now, in that way we can help and force the “vendors” to actually do stuff for us! I once heard someone say ; If the API is implemented in two major browser – Go! And as we can find WebRTC in Google Chrome and Mozilla Firefox there is no reason waiting at all!
Given the opportunity, what would you change in WebRTC?
I’d say that we should look more into Data Channels, extend those API’s a bit. They are pretty straight forward and are very similar to the WebSockets API’s strength in itself but could be refined.
What’s next for XSockets.NET?
We are currently working in the next major release (version 3) where the 30,000 ft view says that are focusing on scalability, clearness and more interoperability. If you go deeper we are stabilizing the API’s even more. The work with and around WebRTC is primary bringing all the pieces together in a tight and fully capable API that can interop with the rest of the things that XSockets.NET brings.
One detail that may be of special interest for WebRTC geeks is our work with a full .NET stack based WebRTC implementation bringing the possibility to “connect” server side XSocketsControllers and run those as “PeerConnection” i.e capturing & sharing Media Streams and/or pass data over a DataChannel just like it would be a “client” RTCPeerConnection. But unfortunately this wont be shipped in the coming major release.
The interviews are intended to give different viewpoints than my own – you can read more WebRTC interviews.