Merge pull request #3574 from jaliyaudagedara/patch-1
Minor: Typo fix "Communcation" => "Communication"pull/3578/head
commit
bb03200659
|
@ -131,7 +131,7 @@ The string constants for specifying transports are defined as follows:
|
|||
|
||||
The SignalR API contains two models for communicating between clients and servers: Persistent Connections and Hubs.
|
||||
|
||||
A Connection represents a simple endpoint for sending single-recipient, grouped, or broadcast messages. The Persistent Connection API (represented in .NET code by the PersistentConnection class) gives the developer direct access to the low-level communication protocol that SignalR exposes. Using the Connections communication model will be familiar to developers who have used connection-based APIs such as Windows Communcation Foundation.
|
||||
A Connection represents a simple endpoint for sending single-recipient, grouped, or broadcast messages. The Persistent Connection API (represented in .NET code by the PersistentConnection class) gives the developer direct access to the low-level communication protocol that SignalR exposes. Using the Connections communication model will be familiar to developers who have used connection-based APIs such as Windows Communication Foundation.
|
||||
|
||||
A Hub is a more high-level pipeline built upon the Connection API that allows your client and server to call methods on each other directly. SignalR handles the dispatching across machine boundaries as if by magic, allowing clients to call methods on the server as easily as local methods, and vice versa. Using the Hubs communication model will be familiar to developers who have used remote invocation APIs such as .NET Remoting. Using a Hub also allows you to pass strongly typed parameters to methods, enabling model binding.
|
||||
|
||||
|
|
Loading…
Reference in New Issue