What is real-time connectivity, and why is it important? Say you are waiting for an urgent email; would you want to continually refresh the page to check to see if it has arrived yet? No, you would want to be notified the moment that it enters your inbox. With real-time web technologies, we can receive new information from the server constantly. Otherwise, we would be stuck refreshing our page anytime we’d want to see new emails or chat messages. To understand how and why this works, we first need to delve into what a traditional web connection looks like.
Most web pages utilize HTTP, which is a stateless protocol. Mostly, when we navigate to a URL, a request is sent to the server. The server then receives the request, packages the needed data to send back, and returns a response to the client. That’s how the page we are visiting is rendered. After that point, the server drops the connection to the client.
Since it is stateless, it doesn’t “remember” which client it was just linked to. While this is fine for many web applications, it means that if the server has more up-to-date data for the client, it has no way of re-sending it to the client, even though it was just connected to it. The client would have to send that request all over again to check to see if the server has any new content.
This drove the need for technologies that established a connection to continue sending updated information as it became available. While there are now many viable options for establishing real-time connections, today we’ll just be focusing on ASP.NET’s real-time library: SignalR.
What is SignalR?
SignalR is a library in ASP.NET that implements several commonly used real-time connection technologies and uses the most fitting one based on the client it is connecting to.
Among these technologies is WebSocket, which is arguably one of the most popular forms of real-time connectivity. This comes from the fact that WebSocket is a persistent bi-directional connection. This means that the client can send updates to the server in real time, and visa versa. It is also full duplex, so both the client and server can transmit data at the same time. This makes it ideal for things like chat applications or games.
If WebSocket fails, SignalR utilizes Server-Sent Events. Being the predecessor to WebSocket, SSE establishes a persistent connection. However, it is only a unidirectional connection. The server can send new information to a client at any time, but if the client wanted to send updated data back to the server, it would have to make a new request. While this wouldn’t be ideal for something like a game, it would work well for news feeds, data displays or other broadcasting applications.
Next, we have the Iframe. Similar to SSE, Iframe also establishes a unidirectional connection. It allows the server to send updated information without the client having to refresh the page. It creates iframe content blocks within the HTML, which the server can push information into. This is especially useful if you only want a certain section of your webpage to update and be easily changeable, such as ads, news feeds or live reporting.
Our final option is long polling, which uses the classic idea of the request-response cycle and uses it to emulate a consistent connection. Rather than setting up a directional connection, the client begins by sending the server a request. Once the server responds, the client immediately sends another request. Instead of sending data back, the server holds this request until it has new information to send. Once it does, it sends the data, the client processes it, and then sends another request to wait for new information. While it is a less efficient, flashy technology, it works great as a backup for when other technologies won’t work.
The versatility of SignalR and the fact that it has been added to ASP.NET’s framework makes it an easy to use, a popular tool for C# developers.