I want to create a simple video conferencing site and at the beginning I have decided to use Microsoft's SignalR with Mono and apache. But there are some voices saying that SignalR is slow. And if that's true it might be even worst on Mono in linux.
That's why i decided to come here and seek your help. There are a few projects like:
1. Microsoft's SignalR
2. xSockets
3. Microsoft.WebSocket
4. SuperWebsocket
I would like to ask if any of you have any experience with this projects and could help me chose between them.
Thanks in advance!
Disclaimer: I work at XSockets.
I would use OHM's law in combination with what hosting you are planning.
With XSockets and SuperWebSocket you will have support for full-duplex communication (websockets) on all server platforms.
SignalR and Microsoft.WebSockets require Win8+/2012 Server and IIS8 to be able to provide websockets on the server. If you use another platform you will get half-duplex techniques (SSE, Longpolling...) See supported platforms
Maybe that is why you ask about SignalR being slow since you will run on Linux and that means that you will not get WebSocket-support from the server when using SignalR/Microsoft.WebSocket?
When it comes to implementation both SignalR and XSockets has implementations of WebRTC (I assume that it is WebRTC you are talking about event though you do not mention it). I have no idea if SuperWebSocket has any WebRTC samples, but you should be able to port the samples of SignalR and XSockets to SuperWebsocket if you want to.
When it comes to client support there is obviously the issue with IE, but Chrome, FF and Opera will support WebRTC in desktop. On mobile you will have support on Android, but on iOS you will need something like this Cordova lib
It is tested with XSockets webrtc implementation, but I cant speak for others. Should work with the SignalR implementation as well, but we have not tried that.
So, IMHO you should choose between 1,2 and 4 depending on server platform and the implementation that suits your project the best.
Option 3 is probably not a good choice at all...
EDIT:
A link to a WebRTC sample
Here is a project that uses SignalR for video conferencing.
Now, unless you provide the sources saying that SignalR is slow, I can't really have much to say, except that it depends on your scenario. Have a look at the introduction to SignalR and see if your project fits.
If you really want to use Mono and Apache, you will face some compatibility issues, since ASP.NET doesn't have a stable release on Linux, and SignalR will not make the first release of ASP.NET 5.
Unless there is no other option, I would go with IIS for hosting an ASP.NET application until Microsoft releases the cross-platform framework.
As of SigalR being slow, I really don't know what this is about (how many users, what is the behaviour of this 'slow', when sending, or when receiving messages?).
Hope this helps. Best of luck!
EDIT: Ok, have a look at this repo, give it a try and see if you have issues. As for the other technologies listed, I didn't work with them, so I can't really help you.
Related
I have a smart device (Windows CE 2013) that just got the requirement to be controlled from a number of different devices, to do this, we decided to serve a web page from the device that allows it to be controlled.
I've also read that compact framework doesn't support ASP.NET so I'm intending to serve a static webpage that contains a javascript application that calls web services hosted on the device.
I also found this link explaining how to serve a SOAP Service in C++, but it seems old, and I'd prefer to do this in C# as it's my preffered language and I already have some code on it
I'm not quite happy with this solution, am I missing something? Can't I really do this in C#?
You could try this library for .NET https://github.com/ServiceStack/ServiceStack .
It is a free in case if you are using branch v3 form a github.
There's nothing built-in in the CF that provides web server capability. Windows CE has always shipped with an HTTPD server, but, honestly, it sucks and can't be integrated with managed code anyway.
We solved this problem long ago by creating our own IIS-like web server implementation (available commercially). You could do something similar as well - it's just a lot of Socket work. That trivializes the complexity of concurrent request handling and providing an IIS-like object model, but you get the idea. Basically you have to write the whole thing.
The main answer to this is to use Mongoose (or the MIT-licenced equivalent Civetweb). They are C webservers designed for just your task - an embedded web server.
They are really easy to implement, 1 C source file added to your project, give it an array of options, and you're done. See the examples. It has plenty of features and is fast, and small (40kb compiled!). They say it takes 5 minutes to get going with it, and they're right - I tend to use it to add webserver functionality for normal applications now.
I have been playing with Redis win64 port with ServiceStack.Redis client (in C#) since couple of weeks now, and it has admired me alot.
The significant gain in performance I have seen using Redis has made me to think of moving my web application caching to Redis.
So far I haven't faced any issue and my web app is running smoothly using Redis for caching with visible performance gain. Response time has been greatly reduced and my app testers are pretty happy with that.
Now I'm planning to go further ahead and move it to PRODUCTION environment. Before that I'd like to know that:
If it is GOOD to GO with Redis win64 port in PROD environment OR still there are some question marks in doing so.
Are there any recommendations if I opt to go in PROD?
How Redis is used at StackExchange?
Looking forward to some good feedback.
The official word from the developers sounds like you're a bit on your own;
There is no official support for Windows builds, although you may have some options.
As to an official supported Windows version, you seem to be out of luck, but for future reference, Microsoft is working on a Windows version but it's currently at the prototype stage and there are other options but they seem to currently reference back to Microsofts prototype port for coming official support.
Your best supported option would seem to - like all production deployments I know of - be to run Redis on linux for now.
For my website I wrote a WebSockets server in C# (most preferred language to code in) that uses Fleck and it's approximately 600 lines of code. Everything seems to be working decently (a little unstable at times though. Not sure if it's a problem with my code or Fleck).
However, I want to move this from my computer to an actual domain and I'm not sure if there are any hosting providers that would support .NET console applications like that.
I was thinking that maybe I would have to rewrite it in another language like PHP but I'm slightly unsure about the whole idea. Are there any popular hosting providers that would support what I am looking for? And even if they are, is it such a good idea? I imagine it may be less secure or slower than the typical solution of using Perl, PHP, or Python for servers. (lots of P's)
Lastly, if it was a good idea to rewrite, I'm not sure of which language I would write it in. It's been a while and I'm not sure what everyone still uses. Is PHP still considered to be the most supported and secure for web servers?
Which WebSockets implementation is best suited? It took me a while to find Fleck and there seem to be twice as many PHP derivatives and I'm feeling a bit overwhelmed again. Also, a lot of posts on Stackoverflow about WebSockets are from two years ago when they were not as supported.
Sorry for my naivete and lack of focus in my question but as you can see I'm a bit confused as to what my course of action here should be and I'm looking for some insight. Thanks for reading.
Probably the most popular WebSocket server is Socket.IO. It is implemented in Node (Javascript) and has fallbacks to long-polling/AJAX when WebSockets support is not available.
The most well supported implementation of WebSockets is the python pywebsocket project which is used by both Mozilla and Google for developing and testing their client browser implementations. In addition, pywebsocket is designed to easily integrate with Apache allowing you to run your web server and websocket service on the same port(s).
If your application just needs a WebSocket based messaging service and is largely peer-to-peer you might consider using a commercial WebSocket service like Pusher. That could save you from having to host and manage your own server for this.
I would not recommend PHP for WebSocket servers. Until recently there wasn't a PHP implementation that supported both the older and newer WebSocket protocol variation. The older is still used by current iOS devices and the newer IETF 6455 version of the protocol is used by Chrome, Firefox, IE10 and the Flash based WebSocket polyfill web-socket-js.
Also, you ask if PHP is still considered to be the most supported and secure for web servers. Certainly, PHP has always had great documentation and examples and very wide deployment so you could argue it's well supported. However, PHP falls near the bottom of the list in terms of security. I would certainly not rewrite your application from scratch in PHP.
If you are partial to C like languages, you might consider libwebsockets which you could use to build a C or C++ WebSocket server. Andy Green developed and maintains libwebsockets and participated in the IETF working group that developed the standard.
Ruby is another language/community that has seen a lot of uptake of WebSockets (perhaps second behind Node). The most popular websocket library for Ruby is em-weboskcet.
you can try node.js, is "new" and it look good.
Regards
I'm working on project that will work real time: I have to write a video streaming client-server app, this server will to send the AVI/MPEG etc to an web application. I have some questions:
What is the protocol recommend to do this, http? rtp? or other?
In the web application, how do I to show it to user? using an flash player,java applet(I don't ensure if it's possible with it) or HTML5, what is the best way to do this currently?
I hope this is clean for you. Any help is very appreciadted. Thanks in advance. :)
There are several different ways to implement this (some that require programming and others that don't). Which one you choose depends on your requirements.
Red5 is an obvious solution which will allow you to only have to focus on the web side as long as your player of choice is flash.
FlourineFx provides a similar environment for .NET with a little more effort.
I've also done this with IIS and a custom server using HttpListener with much success if you're set on a pure Windows/C# solution. The caveat I'd add here is that it isn't always simple. In an environment with limited throughput, you will have problems since HTTP doesn't have the time corrections that RTP/RTMP/RTSP have but in a decent network it works 3 9's of the time (I've only tested with a single player though).
UPDATE
If you're talking about live streaming with .NET I'd suggest looking into the DirectShow (or related DirectX) API's. There is a wrapper for it for .NET available called DirectShow.NET.
I have written a server/client application using sockets in C# for .NET 3.5. I'm interested in porting the client part to some kind of mobile device and am pondering the best way. The client is actually an underlying library and a GUI depending heavily on touch interface capabilities.
As I see it I have a few options:
Just get an EEE PC and run it on, that's kind of portable but I loose the touch part
Rebuild the library for mobile platforms and make a new, reduced, GUI app
Start a web server and make some kind of web interface to run on iPhones and what not
What would be the best route? What problems can I run into in my alternatives above? I'd really prefer alternative 1 or 2 over 3 because of how the server is currently done and the fact that I know nothing about webservers or ASP.NET. Oh and I'd like to stay with the environment I'm alredy in, that is .NET, so no Ruby on Rails suggestions please. (Not saying Ruby is bad or anything, I just don't know it and don't have the time to learn).
I'd go for option 2 then. It wont take you too long (hopefully) to port the libraries over to the Compact Framework, and providing it's just sockets, etc, you're dealing with then I'm sure the CF will handle it fine.
EDIT: The only problems you'll have with option 2 is if you use any .Net functions that are not in the CF. If that is the case, you'll usually be able to find it within OpenNETCF.
You will need to create a new GUI, but providing you've coded your libraries well, it should just be a case of assigning methods/events where applicable on your device.
I'd say though that option 3 is the best option - it expands your customer base dramatically, especially with the growing number of WM and iPhone users.
I would opt for Option 2.
Most of the members of the TcpClient Class class in System.Net.Sockets namespace are implemented in the .Net Compact Framework.
I would be interested to understand what your requirements are in selecting a mobile device. There are a lot of differences between a Windows Mobile Smartphone and EEE PC.
Niklas,
Before you decide on the technology stack to use on the client for mobile you need to work out what mobile devices they are going to have available this tends to decide the technology for you.
iPhone - Objective C
Blackberry - Java
Nokia - C/Java
Windows - .NET CF
Otherwise would it be possible to turn the client into a mobile web site, that then communicates server to server via your TCP Socket stuff ? That way you do not need to worry about the technology on the mobile.