SignalR - the latest BUZZWORD!

I love the computing industry, it is never in short supply of acronyms and buzzwords. One of the newly added ones is "SignalR" - which in its simplest form is actually a technology that allows FULL DUPLEX communication between the client and a Web server in real time.

A typical web page is driven by HTTP ( which is the protocol through which the browser communicates with the server. The protocol in this case, is analogous to a LANGUAGE that is used for communicating between the client ( browser) and the server. The server supposedly, understands a plethora of languages but the language (Protocol) of preference for serving up web pages is called HTTP).

The biggest challenge of HTTP has been its STATELESS form - which means - the SERVER ( web Server) does not maintain an open channel of communication directly with the client making a request. All it knows is that - a request came in from an address via a port, which is processed and then sent back to the address from where the request came from. While it is processing the request - there is no direct link with the originator of the request. Also, once the response is sent back - the server has no way of initiating further communications with the client except of course, the client re-initiates another request.

Okay - so where are we going with this? Good question. There are certain situations - we want spontaneity. We want to be notified immediately of some event taking place in another environment that we are interested in. There have been attempts in the past to implement something that could make the channel of communication between the client and server OPEN for the lifetime of the client being active. Specifically, piggy riding on the AJAX technology using a concept called LONG POLLING - which is basically having like a HIDDEN IFRAME in a page that is continuously making a request to the server which in turn only responds if it has anything for the client.

The Windows Communication Foundation technology - using Web services - also offers a subscription/notification model that could be used to accomplish this as well - or push/pull design model. However, WCF has been superseded by WEB API - which,supposedly, is the best thing that's ever happened since the "invention" of SLICED BREAD!

To achieve the semblance of SPONTANEITY and/or FULL DUPLEX communication between the client and the server, we can employ one or more of the possible TECHNOLOGIES available provided the prerequisites are met. The Web API to be effective - requires a Server running Windows 2012 and a client running IE 10 or so. In short, for some of these technologies to be used one must ensure that the enabling environment is present.

This is where "SignalR" comes in. It is a set of Libraries that allows a user to implement FULL Duplex of Spontaneous communication with a server without having to worry about the underlying prerequisites for implementing a particular model for that to take place. Simply put - SignalR does most of the heavy lifting and under the hood stuff for you. It basically determines if it can use Web API for FULL Duplex communication, if not - it tries the PUSH/PULL WCF method to see if it can be used and if that does not work - it defaults to the AJAX long polling method.

A pragmatic usage of SignalR is in “Data Refresh” – you can implement SignalR such that a user automatically gets NOTIFIED of a DELTA DATA CHANGE without the client (browser) initiating the REFRESH. You can always be guaranteed of discrete REAL TIME notification without the overhead of a FULL REFRESH. The other less intuitive usage is to serve as a backbone for a MESSAGE BUS or QUEUE implementation.

One final note, SignalR is not restricted to the Web platform alone – it can be used within a Windows based application or a console based application or even more, in an heterogeneous platform.

This post is not so much about the technical usage of SignalR but rather a brief literature about what the buzz is with SignalR. For more in-depth discussion about SignalR, you can visit the HOME PAGE

Comments

Post a Comment

Popular posts from this blog

Decompiling Delphi - 3

I came across this on delphi.about.com web site and thought it useful to add it a a reference here. continued from part two The art of reverse engineering has traditionally been the land of technical wizards, familiar with assembly language and debuggers. Several Delphi decompilers have appeared that allow anybody, even with limited technical knowledge, to reverse engineer most Delphi executable files. If you are interested in reverse engineering Delphi programs I suggest you to take a look at the following few "decompilers": IDR (Interactive Delphi Reconstructor) A decompiler of executable files (EXE) and dynamic libraries (DLL), written in Delphi and executed in Windows32 environment. Final project goal is development of the program capable to restore the most part of initial Delphi source codes from the compiled file but IDR, as well as others Delphi decompilers, cannot do it yet. Nevertheless, IDR is in a status considerably to facilitate such process. In co...
Read more

Decompiling Delphi - 2

I came across this on delphi.about.com web site and thought it useful to add it a a reference here. continued from part one For the moment, Borland does not offer any product capable of decompiling an executable (.exe) file or the "Delphi compiled unit" (.dcu) back to the original source code (.pas). Delphi compiled unit: DCU When a Delphi project is compiled or run a compiled unit (.pas) file is created. By default the compiled version of each unit is stored in a separate binary-format file with the same name as the unit file, but with the extension .DCU. For example unit1.dcu contains the code and data declared in the unit1.pas file. This means that if you have someones, for example, component compiled source all you have to do is to reverse it and get the code. Wrong. The DCU file format is undocumented (proprietary format) and may change from version to version. After the compiler: Delphi Reverse Engineering If you would like to try to decompile a Delphi e...
Read more

Artificial Intelligence, Oxymoron and Natural Intelligence

Image
I posted this question to a couple of online AI engines and to my surprise, none came up with the correct anwser. This is the question - "Two Americans were crossing a bridge on a bright summer morning, one was the father of the other and the other wasn't the son. So, what was their relationship?" This is a classic IQ question - supposedly, employed by Microsoft in the easrly 90s in the recruitment of top talent for its work pool. Essentially, this is a mis-direction fixation challenge. On the surface - it is a fairly straight forward question with the requisite hint at solving it. For whatever reason, most people asked this question are always fixated on the "father and son" narative, which in reality - is the hint to solving the question, but always end up getting it wrong. My point really is - the so called AI engines got the answer to the question wrong as well. The real poser is - should we still be referring to the encompassing ecosystem...
Read more