When a connection is performed, a transport strategy must be put in place in order to properly move bits back and forth between the client and server. Let's recap them quickly:
You might have noticed that Forever Frame, which was available with the JavaScript client library, is not there. That's because this is a purely browser-dependent strategy, and it does not apply in this case. For some more detail about transport options, please have a look at Appendix B, Insights.
Let's see how we can specify the load sequence for the remaining strategies when writing a .NET client.
For this recipe, we will use the server that we used in the Setting up connection transport strategies recipe from Chapter 3, Using the JavaScript Hubs Client API, so please make sure you have already launched that server before testing the following code.
After creating a new console application, which we will name Recipe21
, following the process described in the Introduction section, we will just need to edit its code by performing the following steps:
using
directives as follows:using System; using System.Threading.Tasks; using Microsoft.AspNet.SignalR.Client; using Microsoft.AspNet.SignalR.Client.Http; using Microsoft.AspNet.SignalR.Client.Transports;
Main()
method entry and apply the trick that we already described in the previous recipe to allow us to use the async
/await
syntax, as shown in the following code:static void Main(string[] args) { Do().Wait(); } static async Task Do() { ... }
const string url = "http://localhost:39944"; var connection = new HubConnection(url);
Please check whether the port number (39944
) matches the one used by the server project we are connecting to here.
await connection.Start( new AutoTransport( new DefaultHttpClient(), new IClientTransport[] { new WebSocketTransport(), new ServerSentEventsTransport(), new LongPollingTransport(), }));
As we did in the previous recipe, we call the Start()
method exposed by the connection
object to negotiate and establish the communication channel. However, in this case, we use a more verbose overload to specify which transport strategies we want to try, and in which sequence. The verbosity is increased by the fact that this overload involves a few extra types (AutoTransport
, DefaultHttpClient
, and IClientTransport
); so, if compared with the JavaScript version, it is definitely longer. But, at the end it brings the same functionality.
Console.WriteLine("Connected, transport is: {0}", connection.Transport.Name); Console.ReadLine();
Here, we use the Transport
member of our connection to print the strategy that has been chosen by SignalR to establish the communication channel, and then we wait for the user to press Enter before exiting the application.
When launching the application, the client will connect asynchronously. It will wait for the connection to be available, and then it will print the transport that it used to establish it. Apart from the transport negotiation bits, everything else is equivalent to what we saw in the previous recipe. Therefore, please refer to it if you want some more details about what's going on.