SignalR Transports when using the .NET Client - c#

I am thinking about using SignalR in some WCF and WPF applications.
In reading about SignalR I understand it supports 4 different transport types:
WebSocket
Server Sent Events
Forever Frame
Ajax Long Polling
If I have a WPF or WCF application using the SignalR .net client talking to a normal SignalR server (like the SignalR sample), which one of these transport types are used?

The SignalR .NET client supports up to 3 transports:
WebSockets (.NET 4.5 only)
Version 2.2.0 of the SignalR client will also support the WebSocket transport in universal Windows apps.
Server-sent events
Long polling
There is also the default auto transport that will try to use the best transport available. For example, it will initially try to start a connection using WebSockets, but if that fails, the it will try to use server-sent events next and then long polling.
The .NET client will never try to use the forever frame transport because that transport is very similar to server-sent events. The main difference between the two transports is that the forever frame transport wraps its payload in HTML to support older browsers which load the payload using an iframe.
You can learn more about the .NET client and the provided transports in this guide.

Related

Hosting WebSocket stream API in ASP.NET Core (PubSub + Rate Limitting)

I want to host a WebSocket stream API, mostly for financial data, such as Deribit JSON RPC API over websocket and Binance WebSocket Stream API. I don't want to bother with SignalR because there is no SignalR client support for most of the languages.
Requirements:
The hosted endpoint should be using the WebSocket protocol, i.e. wss://...
Rate limitting capabilities such as Binance's. Speaking of it, they added Sliding Window Rate Limiting in .NET 7 (link). I also found another solution using Redis (Redis Sliding Window Rate Limiting).
If you take a look at the Binance WebSocket Stream API, you'll see that you're able to subscribe/unsubscribe to a stream which makes me think that they are using some kind of a PubSub system over WebSockets.
I did some research and found Azure Web PubSub as a solution (use case here) which is using WebSockets and it is intended for non Azure clients (non SignalR clients).
I couldn't find any websocket server frameworks for ASP.NET Core, so here is the question. What do you guys recommend in this case? Not sure if I could achieve the same using RabbitMQ or Kafka.

SignalR .NET Client connecting to wss URL - if not possible, alternative solutions

I need a ClientWebSocket wrapper in order to connect and collect data from wss://stream.binance.com:9443. The received data should be broadcasted to the UI (realtime UI) through a web socket server.
The broadcast part can be achieved using SignalR .NET Server. It is documented on MSDN.
The client web socket part is what I can't imagine. I found a SignalR .NET Client that I can use to connect to wss://stream.binance.com:9443, however I don't think it is possible, because SignalR probably has its own transport protocol. Is it correct?
If the Signal .NET Client doesn't work in my case, could you please direct me to alternative solutions? I was looking at the following
https://github.com/Marfusios/websocket-client
https://github.com/skunklab/piraeus/tree/96fcbc854d0c8d2c2cd62e457f06ef638859b6eb/src/SkunkLab.Channels/WebSocket
https://gist.github.com/xamlmonkey/4737291
It's worth stating that the ClientWebSocket subscriptions to Binance will be created for multiple API keys (unknown amount of users - based on DB user records).

SignalR and WebAPI, why use a combination of the two?

I'm trying to create a new application from the ground up. I've used SignalR and WebAPI. I believe I know a lot of the differences, but isn't SignalR faster since it uses websockets? WebAPI makes sense to me for external frameworks to be able to reuse. SignalR makes sense to me for anything I'm not necessarily going to use externally. I've done some research and I can't find anywhere it says you shouldn't. I realize this is somewhat opinion-based, but why would you use a mix of the two rather than just SignalR?
I think what I'm mostly asking is if it is wrong to use SignalR to send back to the caller, except in cases where I would send to other clients on that channel? To me SignalR can be used like WebAPI when you are just sending back to the client. Is that wrong to do? It is less code for the client calls(2 lines vs 6 or more, depending on what I'm doing with it). My thinking is I may be trying to manipulate data and send it to the caller now, but maybe I want to send it to all clients later or send a notification to all clients. I'm not a fan of using signalR calls in my webApi controllers. It just feels like the signalR calls should be in the Hub. Thanks for your help.
There is no reason why you shouldn't use them together because they target two different problems. Web-API is a means of making web services easy to target by many different kind of apps/devices whereas SignalR offers bi-directional communications in a way that the Server can call a piece of code on the client without the client having to keep polling the server for results.
E.g. Instead of having a client keep asking the Server for any new messages (like facebook notifications) with SignalR the server knows that there are new notifications for a specific client and it can send them directly without the client having to ask for them.
http://www.asp.net/web-api
ASP.NET Web API is a framework that makes it easy to build HTTP
services that reach a broad range of clients, including browsers and
mobile devices. ASP.NET Web API is an ideal platform for building
RESTful applications on the .NET Framework.
http://www.asp.net/signalr
ASP.NET SignalR is a new library for ASP.NET developers that makes
developing real-time web functionality easy. SignalR allows
bi-directional communication between server and client. Servers can
now push content to connected clients instantly as it becomes
available. SignalR supports Web Sockets, and falls back to other
compatible techniques for older browsers. SignalR includes APIs for
connection management (for instance, connect and disconnect events),
grouping connections, and authorization.
A potential problem is that while SignalR is great at targeting JavaScript code on a client, Web-Api enables connectivity with all sorts of platforms and devices. So the same techniques used through SignalR to target Web Browsers, will not necessarily work on a native Android App.
You can use them together depending on your application needs. I recommend you look at difference between HTTP and WebSockets protocols. WebApi uses HTTP(S), SignalR mostly WebSockets and in some cases others transports. They both have benefits and disadvantages. The main benefits of using SignalR are duplex bidirectional communication as mentioned above and low traffic overheads. Browsers send as a rule a few KB data in HTTP headers and cookies for every request.
It’s easier to use RESTfull services (HTTP) from browsers, HTTP clients, tools, languages and so on instead of using WebSockets. Google Chrome supports monitoring WebSockets traffic but very poorly and Microsoft Edge doesn’t.
Many tools like Google Analytics and Microsoft Azure Application Insights can monitor errors in HTTP requests but can’t do this for WebSockets. You need to implement monitoring manually. Actually WebSockets traffic is simple messages from client to server and vise versa, no additional information. SignalR has some wrappers for this - some kind of error message format.
WebSockets also use more server resources because of keeping open TCP connection and it’s harder to scale web applications that use WebSockets. For instance if you have 100K online users it means you have to be able to keep 100K TCP connections. For HTTP – not necessary. For some very simple sceneries you can replace SignalR with some kind of client polling, but be careful that’s approach may bring a lot of problems.
So, If you don’t need bidirectional communication and traffic overhead (as a rule a few KB per request) is not a big deal then use WebApi only.
If you need bidirectional communication you can use SignalR for server to client push notifications and WebApi for client to server requests simply to ease development, scaling, debugging and using API from other sources. But you also can use SignalR only if you are ok with disadvantages of it or traffic overhead is big for you.

HTTP and SignalR

I am recently learning about web sockets in .Net and have just found SignalR which seems like too good to be true in terms of the abstraction of what connection to use and it seems like there are a few signalr clients in different languages which is awesome.
In my current project different resources are being exposed through a RESTful API, and from my understanding of websockets the client needs to upgrade to a web socket connection through a HTTP request/response. Does signalR handle all this handshaking going on?
If there is an initial request/response from a GET request to retrieve a certain resource but they opt to upgrade to a socket connection, does the server give them any sort of response besides the response saying it acknowledges to open up a web socket connection or is the handshake all that occurs before the information is live updated for that particular resource?
Do you think signalR is scalable as opposed to implementing this through a protocol like STOMP where there are a large number of client libraries?
You are making things too complicated. A typical example of using signalr is:
an html file using JavaScript to connect to a signalr Server when the page is loaded. we call this signalr client.
a signalr server written in c#. it can be a winform or console or service.
the signalr Server can call any dll, or webservices or webapi located in the same server, or even in different Server.
then, the client can call any function defined in the signalr server. the server can call any function defined in the client for a particular client or for groups of clients.
also, client x can call client y functions as well.
you can actually forget about Web sockets, signalr choose the most appropriate transport protocol for you. it will choose Web sockets if it is available in both the server and the client.

Real time data update framework

Am developing client-server application for updating real time chart. Can anyone suggest me any framework/concepts for developing .Net based Server application (so that server will respond to clients very faster)
Client is not a web-based one (it will be MatLab client application). And each client will establish individual connection with server. Server needs to respond to individual client in real time.
I would look into signalR. It's a push framework that lets you maintain long running connections between client and server which enables the server to push updates to the client.
http://www.asp.net/signalr/overview/signalr-20/getting-started-with-signalr-20/tutorial-getting-started-with-signalr-20
SignalR is absolutely awesome here, and with OWIN you can host SignalR within a console app even. However, if you are not interested in learning a new framework, and are not using asp.net, you might want to use a regular Socket library provided with .NET and go from there.

Categories