Finally, it is important to remember that instead of using “localhost” to access the local computer from the client, we must specify the IP address that we have configured.
Consumption of services from other platforms
Both the SignalR team and the user community are developing client implementations that allow consumption of hub or persistent connection services environments other than Windows, and even from those not based on the .NET Framework.
For developers of native applications for Windows, the SignalR team is working on a pure C++ client so that these systems can also benefit from the consumption of real-time services.
The following example shows how to access a persistent connection from a C++ client:
auto connection = make_shared<MicrosoftAspNetSignalRClientCpp::Connection>(
U("http://localhost:40476/raw-connection")
);
connection->SetReceivedCallback([](string_t message)
{
wcout << message << endl;
});
connection->SetStateChangedCallback([](StateChange stateChange)
{
wcout << ConnectionStateString::ToString(stateChange.GetOldState())
<<" => "
<<ConnectionStateString::ToString(stateChange.GetNewState())
<<endl;
}); connection->SetErrorCallback([](exception& ex)
{
wcerr << U("========ERROR==========") << endl; wcerr << ex.what() << endl;
wcerr << U("=======================") << endl;
}); connection->Start().wait(); connection->Send("Hi!").wait();
For .NET developers, the easiest option to implement native clients on platforms such as Linux or Mac OS is via the use of Mono and tools such as MonoDevelop, Xamarin Studio4, or Visual Studio extensions created by the same company. The SignalR .NET client libraries are valid on these platforms.
4 Official Xamarin Studio website: http://xamarin.com/studio |
|
Real-time multiplatform applications Chapter 7 |
149 |
www.it-ebooks.info
It is also possible to create native applications for iOS or Android using the languages to which we are accustomed with the set of multiplatform solutions provided by Xamarin. To access SignalR services from them, we will simply need to use the same client libraries as usual.
There are also unofficial libraries that are being created by the community, for Android and iOS native environments, Java, C++ on QT (Windows and Linux), NodeJS, and others.
150 Chapter 7 Real-time multiplatform applications
www.it-ebooks.info
C H A P T E R 8
Deploying and scaling SignalR
If we had to summarize the deployment process in one sentence, we could say that it is the set of actions that need to be performed to install software in environments where it can be put to use
by users, be it during staging or in the production phase. Within the context of SignalR applications, deployment scenarios can vary a lot because of the large number of platforms that we can find on both the client side and the server side and the combinatorial explosion of these platforms. Obviously, deploying SignalR services inside an ASP.NET application executed on IIS is not the same as doing it in an operating system service or in a Windows Azure worker role. Nor is the deployment procedure of a Windows Phone 8 application that uses the SignalR client to access real-time notifications the same as the deployment process of an application for Windows 8 or a simple JavaScript client.
Each of these platforms has its own deployment procedures, which will remain intact with SignalR. That is, including SignalR components in a server-side application has no effect at all on the way in which it has to be deployed, nor does it affect the client side.
For example, in classic web systems, deployment consists of installing the application on the server, usually in the following ways:
■■Using publishing tools integrated in the development environment, such as the Visual Studio publishing utility
■■In the case of automated processes, using Web Deploy1 or FTP, for example
■■Manually, using any type of transfer protocol allowing us to directly copy the files to the server
However, usually there are no specific actions to facilitate the deployment of components to the client side. They will be distributed on demand when accessing the different pages or features provided, and they will be executed on the user’s browser.
In web applications with SignalR, it is exactly the same. In fact, because all the server components of SignalR applications are compiled (hubs, persistent connections, configuration classes, and so on), it is sufficient to follow whatever publishing process we normally use to get our real-time services working on the operation environments. The client components—basically JavaScript files—will be included in the installation package and will be entered into the application as static files.
We frequently encounter ASP.NET applications deployed in this way, with the structure shown in Figure 8-1.
1 http://www.iis.net/downloads/microsoft/web-deploy
151
www.it-ebooks.info
FIGURE 8-1 Usual deployment of web applications with SignalR.
Our application can be written using frameworks such as ASP.NET MVC, ASP.NET Web Forms, or Web API, whose pages load the SignalR client components to consume services provided via the hubs or persistent connections defined in compiled classes inside the application itself. Of course, it could be accompanied by other assemblies, such as visual components, utility functions, model classes, or any type of content, but the schema would still be the same. This is the simplest deployment architecture that we can find.
Growing pains
Well, after endless hours of work, many weeks with virtually no rest and sleepless nights, we have finally launched our revolutionary social system in which, of course, we have employed SignalR to implement spectacular features that use push and real-time communications as mankind has never known before. Now we just have to reveal it to the world and begin to attract users by the hundreds. One might say that our problems are over. (Or you could say that they have just begun.)
From this point, basically two things could happen, intermediate states aside. In the first case, our super application would turn out not to be as necessary as we thought, or perhaps users would not understand its true value, and it would end up being used by no one and ultimately fading into oblivion.
Or we could have the exact opposite case: our application is a real hit. Attracted by the novelty and the promise of finally getting their lifelong-awaited online experiences, users begin registering timidly. Word of mouth and fast spread through social networks causes the number of registrations to grow exponentially after a few weeks. Users begin to number in the hundreds, then thousands, and
152 Chapter 8 Deploying and scaling SignalR
www.it-ebooks.info
then come the first complaints of slowness and problems with the service. This effect is often called
“death by success,” and it is the reason for the demise of many interesting projects. It is a delicate moment, and the survival of our creature will depend largely on our ability to resolve these issues.
It is time to scale—that is, to find ways to provide quality service to a growing number of users.
Fortunately, it is always possible to extend the server that we have rented to host our application, so our first approach in this case is normally to invest there: maximizing RAM, installing as many processors as the board or the virtual machine allows, and improving persistent storage in terms of speed and space. This way of increasing the capacity of our infrastructure to support more users is called vertical scalability. (See Figure 8-2.) It requires virtually no software changes or special precautions during development; it simply involves buying or renting more metal or adding more resources to our VM.
Note Scaling using this approach is often called a scale-up.
FIGURE 8-2 Vertical scaling of a server.
The more optimistic members of the team might think that this large investment in hardware would overcome the problem. And it would...at least for some amount of time. The problem with vertical scalability is that it is inherently limited: however much we want to extend a server, there will be a point beyond which it is physically impossible to increase its capacity. Here we would switch to a server whose architecture allowed for more expansion, but given the growth rate of our super app, this would serve only to give us some breathing space while we look for a more definitive solution.
And we should not forget the cost either: adding memory or CPU to a system tends to be expensive, and normally there is a rather limited return on investment. It is also not a very flexible option. If we know that our users connect primarily in office hours, during the rest of the day all the power and resources of the server will be underused, so we will not be getting the most from our investment.
In short, vertical scalability is valid for closed or tightly controlled environments, such as corporate applications or systems that have a low number of users because of the very nature of the service and its context. After all, we are unlikely to need much more if we are creating a chat application for the die-hard fans of the synchronized swimming infant team of the local neighborhood—opting for more complex solutions in this scenario might be considered oversizing, over-engineering, or just overkill.
Deploying and scaling SignalR Chapter 8 |
153 |
www.it-ebooks.info
When vertical scalability is not enough, the solution comes via a much more powerful approach: horizontal scalability. Scaling horizontally consists in increasing the number of servers until they can respond to user demand.
Note Scaling using this approach is often called a scale-out.
In traditional web environments, the ideal solution is to introduce a mechanism to automatically distribute the load among various nodes in a way that is fully transparent to the user, acting for all intents and purposes as if the application worked on a single server, although each request (even those from the same user) can be processed by a different node in the network. These elements, called load balancers, are located at the entrance to a server farm and redirect requests to the least busy server to be processed there. See Figure 8-3.
FIGURE 8-3 Transparent horizontal scalability.
And, thanks to currently existing technologies, we could even use cloud services like those provided by Windows Azure2 to dynamically adapt the number of servers to the actual demand at each time, thus obtaining the assurance that our application will always be available to serve its users, as well as achieving great ease of management of infrastructure and a good level of fault tolerance.
Also, to reduce latency and boost performance, it is possible to bring contents and services closer to the users who consume them, using CDN3 (Content Delivery Networks) or strategically located servers. The main advantage in comparison to scaling up is that in scale-out there is a priori no
2Windows Azure: http://www.windowsazure.com
3CDN: Content Delivery Network.
154 Chapter 8 Deploying and scaling SignalR
www.it-ebooks.info