精通ASP.NET SignalR：实时Web开发与案例实战

需积分: 0 176 浏览量更新于2024-07-17 收藏 8.42MB PDF 举报

《Pro ASP.NET SignalR (英文高清原版)》由Keyvan Nayyeri 和 Darren White 合著，专为那些希望深入理解和利用最新实时技术的 ASP.NET 开发者设计。本书聚焦于 ASP.NET SignalR，一种强大的框架，旨在简化在 Web 应用程序中实现双向通信，从而实现实时互动。该书分为多个章节，引导读者从基础到高级逐步掌握 SignalR。首先，第一章介绍实时 Web 的概念和 ASP.NET SignalR 的核心理念，让读者了解其在现代 Web 开发中的重要性。第二章概述了 SignalR 的架构和工作原理，包括其主要组件和设计理念。第三章详细讲解如何使用 Hubs（中心节点）开发 SignalR 应用，这是构建实时应用的关键组件，负责处理客户端与服务器之间的消息传递。第四章则深入探讨了持久连接的应用，这对于保持用户连接并提供连续服务至关重要。第五章涵盖了故障排查技巧，帮助开发者解决在实际项目中可能遇到的问题，确保应用程序的稳定运行。第六章介绍了支持 SignalR 的客户端库，这些客户端可以是浏览器端、移动应用或桌面应用，扩展了 SignalR 的适用范围。第七章讨论如何扩展和自定义 SignalR 功能，以适应特定业务需求。第八章涉及配置、部署和安全性方面，帮助开发者理解如何优化 SignalR 环境，保障数据安全和系统的高效运行。接下来，书中的两个案例研究提供了实战经验：第一个是股票 ticker 示例，展示了如何通过 SignalR 实现即时更新的金融信息展示；第二个是协作绘图应用，展示了如何利用 SignalR 构建多人协同的实时应用场景。最后，书后附有详尽的索引，方便读者快速查找特定主题。《Pro ASP.NET SignalR》是一本实用且全面的指南，无论你是初学者还是经验丰富的开发者，都能从中获得深入理解和实践经验，提升实时 Web 开发技能。

Chapter 1 ■ IntroduCtIon to the real-tIme Web and aSp.net SIgnalr

ASP.NET SignalR Architecture

As discussed in the last section, ASP.NET SignalR is a set of different libraries for different platforms. Although the

server side of SignalR is bound to the .NET Framework or Mono (the open-source Linux implementation of the .NET

Framework), the client libraries are very independent and can be implemented for any platform. At a high level,

ASP.NET SignalR as a technology consists of a server implementation that serves a set of various types of clients

hosted on different platforms (see Figure 1-6).

Figure 1-6. High-level view of ASP.NET SignalR as a technology

With this background, when we talk about architecture, we refer to the architecture of the server side of ASP.NET

SignalR because the general high-level architecture for the whole SignalR technology is a server-client architecture.

Client libraries would not have a unified architecture per se, although all these clients need to have some kind of

support for transports to connect to the server-side transports discussed later in this chapter.

But the server side of the SignalR library consists of a stacked architecture (Figure 1-7) that uses one of the four

common transport options discussed in the next section. Depending on the network infrastructure and availability,

one of these four transports is used in order of priority. If hub APIs are used, they are the points of connection for

clients to simplify the logic and call the underlying persistent connection APIs in SignalR. If persistent connection

APIs are used directly, developers need to take care of receiving the raw data from clients and extracting metadata to

respond to these requests.

Chapter 1 ■ IntroduCtIon to the real-tIme Web and aSp.net SIgnalr

Main Challenges for Real–Time Web Development

HTTP is a stateless protocol that does not provide any callback mechanism for servers and clients. This is the main

challenge for real–time web development when we want to push information from servers to clients whenever it

arrives. Most efforts of building real–time web development frameworks are dedicated to tackling this challenge.

To solve this problem, different techniques are used to put the content from server(s) on client(s). These

techniques can be categorized into two groups:

• Traditional approaches: Rely mostly on using hacks and tricks to achieve this goal. These

approaches are built based on the concept of long-held HTTP connections between servers

and clients that are also known as Comet.

• Modern approaches: Rely on new features introduced in HTML5.

Four transport options that fall into these two categories are discussed in the next section: long polling, forever

frame, server-sent events, and WebSockets.

The other related challenge for real–time web development is the resource use caused by traditional approaches

(i.e., Comet) because long-held HTTP connections can drain the battery power on mobile devices and consume

other resources on the client and server. Therefore, the implementations of Comet approaches are critical for

maximum efficiency.

Although such a challenge exists for traditional Comet approaches, newer approaches based on HTML5 also

have limitations with the current state of the Internet. For example, the use of WebSockets is dependent on hardware

and software support between client and server. So the whole network infrastructure between client and server must

support WebSockets, and the software infrastructure in the hosting operating system must also support them at the

same time. Currently, WebSockets is a supported feature only in Windows Server 2012.

The last challenge for real–time web development is to implement hard real time. Assuming that all these

challenges are resolved, content from server to client has to be delivered in a very short period of time (usually

less than 1 second) to imply a real-time behavior. Such a constraint mandates developers to build lightweight and

efficient implementations.

Server

Hub

Persistent Connection

Transports (WebSockets, long-

polling, etc).

Client (Web)

Hub

Persistent Connection

Transports

Client (iOS)

Hub

Persistent Connection

Transports

Client (Android)

Hub

Persistent Connection

Transports

Figure 1-7. ASP.NET SignalR server architecture

Chapter 1 ■ IntroduCtIon to the real-tIme Web and aSp.net SIgnalr

Transport Options

As discussed in the previous sections, ASP.NET SignalR relies on transport layers to make communication possible

between client(s) and server(s). These four transport layers are categorized in two groups: Comet approaches and

modern HTML5 approaches. Each transport option is discussed in turn, followed by a discussion of how SignalR

implements these transport layers.

Long Polling

This famous Comet approach is one of the most common ways to achieve real–time web development in today’s

Internet. It relies on using JavaScript (or other technologies and techniques) to make a lightweight HTTP connection

to a server and keep it open for a period of time (e.g., 30 seconds). In this interval, if new data becomes available on

the server, it puts the data in the currently open HTTP connection and then closes it. The client receives this data and

opens a new long poll connection immediately. If there is no data in that period of time, the client establishes a new

long poll connection and continues this as long as the page is open and active in a web browser.

Long polling follows this simple model and reduces the overhead of opening several connections to servers that

could be introduced by an interval polling approach. Interval polling is the traditional approach in which the server

is checked at regular intervals (e.g., every 10 seconds) for new content. This approach is not efficient; opening and

closing HTTP connections to web servers create overhead. Long polling tries to reduce this overhead.

Forever Frame

Another Comet approach that is less common than long polling is Forever Frame (also known as hidden iframe),

which is an approach specific to Internet Explorer. In this approach, a hidden iframe element is attached to each web

page that is kept open for the whole duration of the request (the period of time that a user stays on the page). As data

becomes available on the server, it is filled with JavaScript codes in a stacked manner, and because browsers execute

these scripts in order, they can provide the desired behavior needed.

Server-Sent Event

This approach is a modern HTML5 transport that enables web browsers to receive events from servers through an

HTTP connection.

The main limitation of server-sent events (like any other approach based on HTML5) is browser support.

Although the most recent versions of common browsers support server-sent events, Internet Explorer does not

support them, which leaves a big gap for those interested in using these events for real–time web development.

WebSockets

The other HTML5 approach that has better browser support is WebSockets, which provides two-way communication

channels over a TCP connection. WebSockets is not limited to HTTP, although it can also be used in that context.

The use of WebSockets is dependent on the support by the underlying operating system (among Microsoft server

technologies, only Windows Server 2012 supports them, although it is also available on Windows 8 and 8.1) and

the whole network infrastructure between the client and server. Of course, browser support is also needed to take

advantage of WebSockets, and recent versions of most common web browsers support it.

Chapter 2

Overview of SignalR

When learning a brand-new code library, you might initially think that it is great and you will use it for every project

going forward. Although sometimes the new library will work in your latest project, it is probably not the best solution.

This chapter discusses the technologies on which ASP.NET SignalR is built. These are the technologies that enable

SignalR to support a wide range of server and client platforms. Because you’ll be eager to try SignalR, you will write

your first SignalR application. After creating the first application, the focus is on when it is best to use SignalR.

To get even more out of SignalR, we go over what you can customize, extend, and scale to fit your project needs.

But with all good things there are limitations, and we discuss a few of SignalR’s limitations, too.

In summary, the following topics are discussed in this chapter:

Technologies behind SignalR•

Supported server and client platforms•

Getting started with SignalR•

When to use SignalR•

Extensibility of SignalR•

Limitations of SignalR•

Technologies Behind SignalR

There are a few technologies that stand out in SignalR that give it the strength and flexibility that make real-time web

applications easy. These technologies help applications be flexible so they are not dependent on a specific host. They

also make it easy to connect to a wide number of clients without having to worry about the client-specific transports.

As well, these technologies allow your application to be highly customizable and to scale.

Open Web Interface for .NET (OWIN)

Many developers know that most ASP.NET projects are built with a dependency on the System.Web assembly that was

built primarily for Internet Information Services (IIS). The first break away from the dependency to System.Web came

with the release of Web API in 2012. With the System.Web dependency removed, developers could self-host Web API

much more easily, which created a new issue in which there could be multiple hosted implementations (Web API,

static pages, MVC, and others), all running in their own process with separate hosts. To handle this problem, web

developers came up with a common interface that enables decoupling of the web applications from web servers. This

common interface is OWIN, which enforces a structure and process for the HTTP requests and responses. The OWIN

interface is very simple (see Listing 2-1).

剩余346页未读，继续阅读

tubolao888

粉丝: 1
资源: 10

精通ASP.NET SignalR：实时Web开发与案例实战

Pro ASP.NET MVC 5 (精通ASP.NET MVC5框架) 中文+英文+配套源代码

Pro ASP.NET SignalR Real-Time Communication in .NET with SignalR 2.1（pdf原版）

Pro ASP.NET SignalR(Apress,2014)

Asp.Net SignalR Hub中的上下文对象

设置Asp.Net SignalR Hub 的Context

asp .net core signalr

.net core signalr winform

asp.net core signalr

asp.net执行js代码的所有方式

pro asp.net 4 in c# 2010 4th中文版

最新资源