Already i built chatting application in(Android, iOS & windows phone) & established in asp.net WebAPI, Now performance is very poor.
After googling i found, XMPP is the best & free(I am planning to use free open source tool, don't suggest paid lib)
Instead of XMPP, why we can't try with signalR?
Suggest me, which one should I go & start establishing the API.
I know compared to SignalR, XMPP have lot of features.
Of course you can do it also with SignalR, or even as a combination of XMPP and SignalR.
XMPP is a complete presence and messaging protocol with lots of features and many available extensions (also non IM features). Its in production for over a decade now. It gives you all you need to build a IM/Chat app for free. So why to reinvent the wheel and rebuild all the existing functionality on your own with SignalR when you can just install an existing XMPP server, get a client XMPP library and start coding your chat application.
Related
Sorry if this is a silly question. Has anyone managed to get the twilio stream to websocket working with SignalR (https://www.twilio.com/docs/voice/twiml/stream).
I have been trying for a while now and although I can see its hitting the server I never see it hit any of the methods.
Any help would be greatly appreciated
Thanks
Steve
I am just taking a look at Twilio Streams now that they've announced bidirectional support, I noticed that the docs indicate you have to utilize WebSockets. SignalR uses WebSockets but isn't just WebSockets. It's summed up succinctly in Jim Mc̮̑̑̑͒G's blog post How to save an audio file from Twilio Media streams to Azure storage
"SignalR is terrific, but it solves a different problem. SignalR can be thought of as a wrapper of several technologies - of which WebSockets represent a major component. It primarily serves the purpose of connecting web-browser clients to a back-end service. Other problems it solves include the maintenance of robust connections and the use of fallback techniques to enable browsers that don’t natively support WebSockets, to still benefit from real-time connections.
For Twilio Media Streams, we need to use WebSocket connections in a server-to-server configuration. SignalR isn’t the right tool for that job."
I am still thinking what is the most proper WebSockets framework to learn, which gives me all what I want.
I am C#.Net Core programmer (it is the language I want to use to write my server with). I wanted to start learning SignalR, but I didn't start yet because I am still confused about the ability of using my SignalR server from a Microcontroller client.
Is it some how possible to use transfer data between SignalR C#.Net Core server and an ARM Cortex M4 microcontroller programmed in C (without any operating system on it)?
In case that is not possible with SignalR, which WebSockets framework may be useful for my case (C# Server <-> C client)?
Any further ideas and suggesions about that? I am still very new to WebSockets and I don't understand exactly if it is possible to use SignalR (or any WebSockets framework) server from a client uses another framework (or maybe pure websockets).
If you are using SignalR for ASP.NET Core you can actually use bare websocket to connect to the server. I showed a demo where I have 3 different clients connecting to the SignalR server. The interesting part is that one of the clients was a NodeMCU based board running lua. You can find all the details in my post including code and instructions on setting things up.
What is preferable for a cross platform chat application web service, a Web Socket or a long polling or a server-sent event ?
Thanks in advance !!!
WebSocket is built for applications such as this, while long polling (however well done) is a hack. Support for WebSocket is also very broad, and you can use e.g. a flash fallback in older browsers.
Server-sent-events are only part of a solution, and you have a big support gap in IE.
(Shameless promotion of an open source project I'm connected to: take a look at WAMP (http://wamp-proto.org) and Crossbar.io (http://crossbar.io), which offer communication patterns on top of WebSocket and provide a lot of infrastructure for building a chat application.)
I used webApi for create web Service and provide Web services to mobile Android/Apple programmer. I want to send a notifications for mobile when the database has changed. I searched on the internet and found that i can use PushSharp or Signal R. Which is the best option ?
It is really depends !!
if you want Notification server for mobile app i think PushSharp is good solution it's built as Push Notification framework for mobile app it is depends on GCM (google cloud messaging API ) it's full free API from google .
I think this task is not for signalR .
signalR is a framework for building real time apps you can Implement any Scheme like pub-sub .
what i know there is a client implementation for signalr for android called :
SignalA : URL : github.com/erizet/SignalA
So if you want to send Notification to Mobile app you can use one of
those :
PushSharp
PushBots
i found pushsharp more reliable .
and has a big community .
also you must consider what your mobile app developer good at ??! .
As Khairy said, SignalR and PushSharp do very different things.
SignalR is a real-time web framework. It is best suited to real time, two-way communication between a client and a server. It requires that your client application be in constant communication with your server.
PushSharp is a push notification library. It is used to send, well, notifications. The act of sending a push notification to a client is inherently one way, and might not happen in real time.
If all you really want to do is send notifications, I see no reason why you wouldn't want to use the right tool for the job. In this case, PushSharp is the right tool for the job.
I want to develop a web application in which client calls a service on server to do some action which involves some processing. Server will do all the necessary processing and when the updated data is ready it will push that data to client. Currently I am considering two approaches: -
1. Using ASP.NET WEB API with SignalR
2. Using WebSockets with WCF in .NET 4.5.
My server will be on Windows Server 2012 but majority of my client will be IE 9 which I think do not support WebSockets.
As written in the SignalR documentation that it automatically falls to Long Polling if WebSockets support is not present without changing the application code. Whether this is also supported by WebSockets in .NET 4.5 or I have to do it manually. Means whether I have to implement both the Pull method and push method on the server.
Please guide me, which approach I will have follow.
In later use case I want to build this web application using PhoneGAP to create mobile app for iOS, Android & Windows Phone.
WebSockets does not fall back to longpolling (that doesn't really make sense). SignalR is a higher level abstraction over http transports and that's why it does the fallback and other things (like provide a nice programming model over a connection).
If you choose to use websockets on ASP.NET (not sure about WCF) you'll be programming against raw sockets (this means reading/writing array segments etc) and doing a good job at that is hard. SignalR does this for you and will fallback to several other transports (forever frame, server sent events, longpolling) if websockets isn't available on client or server.
Regarding clients, if you choose to use SignalR you'll need to use a SignalR client. We only have support for javascript and .NET (silverlight, windows phone 8, winrt, .NET 4 and .NET 4.5). Some people have written clients for other platforms including iOS and Android but we don't maintain them so I can't speak to how up to date they are.
I'd recommend you use SignalR so you can focus on your application logic instead of messing with the low level programming model of websockets.
You could start with the ASP.NET Tutorial http://www.asp.net/signalr/overview/getting-started/tutorial-getting-started-with-signalr
After this tutorials you know all the basic thing you need to know about SignalR
I can confirm that the fallback works automatically. If websockets transport can't be used, ServersentEvents transport would be used.. and so on.. the last transport protocol is longpolling.
Our SignalR server is a .NET 4.5 framework app, hosted in an ASP.NET MVC App using 4.5 dlls on a windows 2012 server. The application pool is ASP.NET 4.0.
A .NET 4.5 client on a Windows 8 or a windows 2012 server seems to use websockets.
The same .NET client on a Windows 7 machine (even with framework 4.5 installed) falls back to serversent events transport automatically.
With Signalr javascript clients on a browser, a similar thing happens:
Chrome/Safari/other browsers that support websockets seem to use websockets.
IE/other browsers that don't support websockets, but are relatively late versions seem to use serversentevents.
From experience, serversentevents is not very bad, therefore don't be put off if websockets isn't being used and certainly don't use that as the sole factor against using signalR as the benefits are many.
Hope this helps.