We Keep Coding

Which socket serverside software for video conferencing?

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.

Implementing a Web Service Server in Windows CE 2013

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.

converting c#.net application to android

I know this is very vaque question but still I am asking.
Is there any one I can convert my existing WinForm built in c#.net and DB as SQLSERVER 2008, to andorid application ?
If no, then is thr any easier way to built an app as I am not familiar with any Mobile Application tools.

Generally, no. The languages are somewhat similar, but the way the UI is built is vastly different and will have to be rewritten from scratch. Also, database access differs. I actually doubt that Android have libraries required to "talk" to SqlServer. Even if it managed to talk over some generic ODBC layer, still the DB-access will also differ very much. I assume this would consist of more than 80% of your application - so it can safely be estimated that whole application cannot be converted, and a new application has to be written. Of course, some SQL queries might be reused, some application classes might be usable too (if written in an enough platform-independent way, so they can be translated to Java)..

No there is no way to do that in easy way.
Android development is similiar in UI level to WPF (you can find some simliarities) + you have completely different behavior model as you're talking about mobile development.
In short, if you want to continue with C#, you may think of picking Mono Droid.
It's payed.

This is not easy as far as I know. If you want the conversion for free you should rewrite it in Java using the Android SDK (run on Dalvik - a custom VM). As stated above, you will have little effort learning it if you already know C#, you could also use Mono Droid or hire a developer if you have the possibility to do so.

TCP/IP vs Web Services for iPhone chat app

How to create a NATIVE chat app for the iPhone? So far we have been exploring a few options:
Creating a web service using php or other web based language and have the app connect to that. Only problem is we can't figure out how to create "push" messaging with this, where the user will not have to refresh the conversation constantly.
Hosting an application on a server such as Windows Azure which will communicate to the iPhone app using TCP/IP. This way it seems like "push" messaging could be achieved by simply sending a packet to the iPhone. However, we have never done this before and don't know if we would run into any unforeseen potholes.
Have any of you made such an app before? If so how did you go about doing it? If not, what method would you recommend?
Thank you in advance!
EDIT:
To tell you exactly what we're trying to do: we need to make an app where a user can join a chat room and send/ receive messages from that chat room. There will also be custom features like that users will have their own profiles, etc. We would also like to make this as flexible as possible, so that we can integrate it on other platforms like android and blackberry later on.
So essentially the part that I'm stuck on is the send/ receive messages from a chat room. What technology should we use server side?

Something with an open socket, like Socket.IO could work. Node.js is a good server-side framework to explore. Here's an related SO question: iPhone Objective-C socket communication with Socket.IO
EDIT:
Question has changed since posting this answer -- originally question asked about web apps. ALso, originally the question was not clear that you wanted answers about the server side more than the client side.
On the server side, I would still recommend Node.js -- sounds like you want to use C# though, which makes me wonder why you're asking again about what server side tech to use. Most languages will provide you with ways to connect a socket to a client and access a database, which are the two main requirements of the app that it sounds like you want to make. Use whatever language you're comfortable with. However, some are going to come with libraries that may come in handy for this type of communication -- Node.js and Ruby on Rails (more useful if you want to do a polling-based solution)
Look at http://code.google.com/p/cocoaasyncsocket/ for a good library for doing socket communication from the iPhone without having to delve too deep into the low-level functions.

I've done this several times. Scaling to 100K concurrent users is non-trivial. If you want an off-the-shelf system I suspect ejabberd may do what you want. although the protocol IMHO is too verbose and uses far more bandwidth than necessary.
If you want to write your own solution and have the flexibility to write your own protocol and have the maximum possible scalability in the future then use a language that allows you to distribute the application across several servers. It is easier to allow that from the get go rather than writing a single server solution then have to retroactively make it distributable.
Having written servers like this in c++, Java and Erlang I would say the easiest and most relevant tool was Erlang. It makes good use of multi core processors and with a good design it facilitates distributing across several servers. C++ was the hardest!
I have also used Java with tools like JETTY and RabbitMQ to write a highly scalable system that required using HTTP as the protocol.
Personally I prefer a custom binary protocol as it allows you to reduce bandwidth to a minimum, and avoids DOS attacks and such as the protocol is well defined and lengths are sent before the packet, where as non binary protocols need to be parsed as they come in, with no idea of how big the packets may be.

Why not try XMPP protocol first? XMPP is based on TCP/IP.
There are several OpenSource server solution, clients, and application libraries. XMPP already supports chat room like service. You can define extension easily.

How do you write for *all* phones/mobile devices simultaneously?

We create non-game programs that run on mobile devices; iPhones, Windows Mobile, Android, Palm WebOS and the like. Our main program is written in C# for Windows Mobile and we've been asked to port it to iPhone. We are not looking forward to:
The learning curve to pick up
Objective-C, XCode, and Cocoa Touch.
The pain of maintaining two
sets of code to keep the product in
sync on two different platforms.
We've decided that as a strategy we want to create all new products on as many mobile platforms as possible simultaneously, a formidable task.
We know we'll have to bend on these, but we'd prefer to:
Avoid forcing our users to be
connected to the web to use a product.
Not have a bunch of different sets
of source code.
Support as many mobile platforms as
we can.
My question is this; What is your suggestion for the best strategy to develop for the 2 - 5 most popular mobile platforms?
EDIT: Based on the comments, I wanted to clarify that we have a product that we well-received on both PalmOS and Winmobile. It works exactly the same on both platforms, making it easy for a user to switch handhelds and still use it.
Now we're on the verge of creating many new business apps and want to expand that to other hardware/OSes. What are your suggestions to deploy on many new platforms with the minimum of pain?

Consider implementing your applications via the web. This violates your preference for "avoiding your users to be connected to the web", but consider the web for the following reasons:
If your C# applications were written the right way, you could expose a web front-end to these applications by reusing your existing libraries.
Web 2.0 is supported by nearly all modern mobile platforms.
Your developers could continue writing in the language they're used to (C#).
There are many advantages to writing web apps vs platform-specific apps.

Consider Appcelerator Titanium, Rhomobile's Rhodes, PhoneGap, xmlvm.org, or other cross-device toolkits.

I make the assumptions that you have already done your market research and actually knows that all platform will be profitable, and not just drain your resources developing for one or two.
There is no great answer unless you break the "no connect to internet" rule. But there is a good answer; plain old C.
Implement all application logic in plain old C. Then;
iPhone - Objective-C is a strict superset of C, so just use the code as is. And write a UI in Objective-C using Cocoa Touch.
Android - Android's Java have JNI for calling native code written in C. Write a thin glue layer, and implement your UI with normal Java for Android.
Windows Mobile - You can call native code from any .NET application. So write another thing glue layer, and implement your UI using C# or your prefered .NET language.
Symbian - Symbian uses a variant of C++, so just like on iPhone you can call your C code as is. Write your UI using C++ and Symbian API:s.
If you break the "no connect to internet" rule then implementing the server with your existing C# code and exposing it as a web service using HessianC# is a snap. And then Hessian implementations are available for every phone that you can install an application on, that has been sold since 2002 or so.

I suggest you to separate the core of your application and the GUI. So you can continue to develop your applications in C# for Windows mobile and iPhoneOS (thanks to monoTouch). With this strategy you have only to develop the specific GUI on Windows mobile (C#) and iPhone (Cocoa Touch).
For other mobile os you can not use a cross platform dev env (for now). You need to redevelop all you application.
So:
Windows Mobile: Core(C#) & GUI(C#)
iPhone: Core(C#) & GUI(Cocoa Touch)
Android: Core(Java) & GUI(Java)
Other: depends on OS

Virtualization
Depending on your hurry I heard that VMWare is working on a mobile virtualization product that would make it possible to unify platforms into a single execution point within VM on a mobile device. It will almost certainly support majority of smartphone platforms (Windows Mobile, Android, Symbian, Blackberry and maybe even iPhone). They (and we) would definitelly benefit the most when they'd support all of them.
If you're not in a hurry, maybe wait a bit.

With a c# application for the Iphone check out Monotouch. Its the OSS version of the .net framework for the iphone.

I'll go against the grain and give you some tough love instead of simply answering the question you asked.
My thought is, why would you want to make 2-5 versions of your application that will receive, at best, a lukewarm reception across all platforms? Because that is what you are going to get.
If you want to make applications that are well received and make users excited to use them, make them take advantage of the platform. iPhone apps should have well thought out user input and take advantage of as many platform features as possible, like mutl-touch, easy data storage, accelerometers, camera and so on.
Palm apps work great in the background so write something that takes full advantage of that. it might even be more than one app to keep to Palm's simple and small approach to apps.
Android apps can integrate much more tightly with the system, so let them do just that to the benefit of the user.
Your main benefit with any app should be that you understand the domain completely, and can describe what aspects of the problem domain work best with the strengths of any given device. Mobile apps are small(ish) and any small gain you get from trying to share code across devices (and how does that work exactly across Java/Obj-C much less Android to Blackberry library differences?) is totally lost in the distortion of your understanding through the prism of accommodation.

Try using PhoneGap! All you need to know is web technologies.

A bit late to your question. But you can use Rhodes (http://rhomobile.com/products/rhodes) to write for every major smartphone OS. Tens of thousands of other developers do. Rhodes was the first smartphone app framework and the only one to provide the benefits of Model View Controller enjoyed by web developers to native smartphone development.