Websocket.Client 5.1.2

dotnet add package Websocket.Client --version 5.1.2                
NuGet\Install-Package Websocket.Client -Version 5.1.2                
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="Websocket.Client" Version="5.1.2" />                
For projects that support PackageReference, copy this XML node into the project file to reference the package.
paket add Websocket.Client --version 5.1.2                
#r "nuget: Websocket.Client, 5.1.2"                
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package.
// Install Websocket.Client as a Cake Addin
#addin nuget:?package=Websocket.Client&version=5.1.2

// Install Websocket.Client as a Cake Tool
#tool nuget:?package=Websocket.Client&version=5.1.2                

Logo

Websocket .NET client NuGet version Nuget downloads

This is a wrapper over native C# class ClientWebSocket with built-in reconnection and error handling.

Releases and breaking changes

License:

MIT

Features

  • installation via NuGet (Websocket.Client)
  • targeting .NET Standard 2.0 (.NET Core, Linux/MacOS compatible) + Standard 2.1, .NET 5 and .NET 6
  • reactive extensions (Rx.NET)
  • integrated logging abstraction (LibLog)
  • using Channels for high performance sending queue

Usage

var exitEvent = new ManualResetEvent(false);
var url = new Uri("wss://xxx");

using (var client = new WebsocketClient(url))
{
    client.ReconnectTimeout = TimeSpan.FromSeconds(30);
    client.ReconnectionHappened.Subscribe(info =>
        Log.Information($"Reconnection happened, type: {info.Type}"));

    client.MessageReceived.Subscribe(msg => Log.Information($"Message received: {msg}"));
    client.Start();

    Task.Run(() => client.Send("{ message }"));

    exitEvent.WaitOne();
}

More usage examples:

  • integration tests (link)
  • console sample (link)
  • .net framework sample (link)
  • blazor sample (link)

Pull Requests are welcome!

Advanced configuration

To set some advanced configurations, which are available on the native ClientWebSocket class, you have to provide the factory method as a second parameter to WebsocketClient. That factory method will be called on every reconnection to get a new instance of the ClientWebSocket.

var factory = new Func<ClientWebSocket>(() => new ClientWebSocket
{
    Options =
    {
        KeepAliveInterval = TimeSpan.FromSeconds(5),
        Proxy = ...
        ClientCertificates = ...
    }
});

var client = new WebsocketClient(url, factory);
client.Start();

Also, you can access the current native class via client.NativeClient. But use it with caution, on every reconnection there will be a new instance.

Change URL on the fly

It is possible to change the remote server URL dynamically. Example:

client.Url = new Uri("wss://my_new_url");;
await client.Reconnect();

Reconnecting

A built-in reconnection invokes after 1 minute (default) of not receiving any messages from the server. It is possible to configure that timeout via communicator.ReconnectTimeout. In addition, a stream ReconnectionHappened sends information about the type of reconnection. However, if you are subscribed to low-rate channels, you will likely encounter that timeout - higher it to a few minutes or implement ping-pong interaction on your own every few seconds.

In the case of a remote server outage, there is a built-in functionality that slows down reconnection requests (could be configured via client.ErrorReconnectTimeout, the default is 1 minute).

Usually, websocket servers do not keep a persistent connection between reconnections. Every new connection creates a new session. Because of that, you most likely need to resubscribe to channels/groups/topics inside ReconnectionHappened stream.

client.ReconnectionHappened.Subscribe(info => {
    client.Send("{type: subscribe, topic: xyz}")
});

Multi-threading

Observables from Reactive Extensions are single threaded by default. It means that your code inside subscriptions is called synchronously and as soon as the message comes from websocket API. It brings a great advantage of not to worry about synchronization, but if your code takes a longer time to execute it will block the receiving method, buffer the messages and may end up losing messages. For that reason consider to handle messages on the other thread and unblock receiving thread as soon as possible. I've prepared a few examples for you:

Default behavior

Every subscription code is called on a main websocket thread. Every subscription is synchronized together. No parallel execution. It will block the receiving thread.

client
    .MessageReceived
    .Where(msg => msg.Text != null)
    .Where(msg => msg.Text.StartsWith("{"))
    .Subscribe(obj => { code1 });

client
    .MessageReceived
    .Where(msg => msg.Text != null)
    .Where(msg => msg.Text.StartsWith("["))
    .Subscribe(arr => { code2 });

// 'code1' and 'code2' are called in a correct order, according to websocket flow
// ----- code1 ----- code1 ----- ----- code1
// ----- ----- code2 ----- code2 code2 -----
Parallel subscriptions

Every single subscription code is called on a separate thread. Every single subscription is synchronized, but different subscriptions are called in parallel.

client
    .MessageReceived
    .Where(msg => msg.Text != null)
    .Where(msg => msg.Text.StartsWith("{"))
    .ObserveOn(TaskPoolScheduler.Default)
    .Subscribe(obj => { code1 });

client
    .MessageReceived
    .Where(msg => msg.Text != null)
    .Where(msg => msg.Text.StartsWith("["))
    .ObserveOn(TaskPoolScheduler.Default)
    .Subscribe(arr => { code2 });

// 'code1' and 'code2' are called in parallel, do not follow websocket flow
// ----- code1 ----- code1 ----- code1 -----
// ----- code2 code2 ----- code2 code2 code2
Parallel subscriptions with synchronization

In case you want to run your subscription code on the separate thread but still want to follow websocket flow through every subscription, use synchronization with gates:

private static readonly object GATE1 = new object();
client
    .MessageReceived
    .Where(msg => msg.Text != null)
    .Where(msg => msg.Text.StartsWith("{"))
    .ObserveOn(TaskPoolScheduler.Default)
    .Synchronize(GATE1)
    .Subscribe(obj => { code1 });

client
    .MessageReceived
    .Where(msg => msg.Text != null)
    .Where(msg => msg.Text.StartsWith("["))
    .ObserveOn(TaskPoolScheduler.Default)
    .Synchronize(GATE1)
    .Subscribe(arr => { code2 });

// 'code1' and 'code2' are called concurrently and follow websocket flow
// ----- code1 ----- code1 ----- ----- code1
// ----- ----- code2 ----- code2 code2 ----

Async/Await integration

Using async/await in your subscribe methods is a bit tricky. Subscribe from Rx.NET doesn't await tasks, so it won't block stream execution and cause sometimes undesired concurrency. For example:

client
    .MessageReceived
    .Subscribe(async msg => {
        // do smth 1
        await Task.Delay(5000); // waits 5 sec, could be HTTP call or something else
        // do smth 2
    });

That await Task.Delay won't block stream and subscribe method will be called multiple times concurrently. If you want to buffer messages and process them one-by-one, then use this:

client
    .MessageReceived
    .Select(msg => Observable.FromAsync(async () => {
        // do smth 1
        await Task.Delay(5000); // waits 5 sec, could be HTTP call or something else
        // do smth 2
    }))
    .Concat() // executes sequentially
    .Subscribe();

If you want to process them concurrently (avoid synchronization), then use this

client
    .MessageReceived
    .Select(msg => Observable.FromAsync(async () => {
        // do smth 1
        await Task.Delay(5000); // waits 5 sec, could be HTTP call or something else
        // do smth 2
    }))
    .Merge() // executes concurrently
    // .Merge(4) you can limit concurrency with a parameter
    // .Merge(1) is same as .Concat() (sequentially)
    // .Merge(0) is invalid (throws exception)
    .Subscribe();

More info on Github issue.

Don't worry about websocket connection, those sequential execution via .Concat() or .Merge(1) has no effect on receiving messages. It won't affect receiving thread, only buffers messages inside MessageReceived stream.

But beware of producer-consumer problem when the consumer will be too slow. Here is a StackOverflow issue with an example how to ignore/discard buffered messages and always process only the last one.

Available for help

I do consulting, please don't hesitate to contact me if you need a paid help
(web, nostr, m@mkotas.cz)

Product Compatible and additional computed target framework versions.
.NET net5.0 was computed.  net5.0-windows was computed.  net6.0 is compatible.  net6.0-android was computed.  net6.0-ios was computed.  net6.0-maccatalyst was computed.  net6.0-macos was computed.  net6.0-tvos was computed.  net6.0-windows was computed.  net7.0 is compatible.  net7.0-android was computed.  net7.0-ios was computed.  net7.0-maccatalyst was computed.  net7.0-macos was computed.  net7.0-tvos was computed.  net7.0-windows was computed.  net8.0 is compatible.  net8.0-android was computed.  net8.0-browser was computed.  net8.0-ios was computed.  net8.0-maccatalyst was computed.  net8.0-macos was computed.  net8.0-tvos was computed.  net8.0-windows was computed. 
.NET Core netcoreapp3.0 was computed.  netcoreapp3.1 was computed. 
.NET Standard netstandard2.1 is compatible. 
MonoAndroid monoandroid was computed. 
MonoMac monomac was computed. 
MonoTouch monotouch was computed. 
Tizen tizen60 was computed. 
Xamarin.iOS xamarinios was computed. 
Xamarin.Mac xamarinmac was computed. 
Xamarin.TVOS xamarintvos was computed. 
Xamarin.WatchOS xamarinwatchos was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

NuGet packages (140)

Showing the top 5 NuGet packages that depend on Websocket.Client:

Package Downloads
ZoomNet

ZoomNet is a strongly typed .NET client for Zoom's API.

SlackConnector

SlackConnector initiates an open connection between you and the Slack api servers. SlackConnector uses web-sockets to allow real-time messages to be received and handled within your application.

Hypar.Client

The Hypar client.

realtime-csharp

Realtime-csharp is written as a client library for supabase/realtime.

Blazor.Ninja.Client.Local

Blazor.Ninja Local Client Package

GitHub repositories (21)

Showing the top 5 popular GitHub repositories that depend on Websocket.Client:

Repository Stars
duplicati/duplicati
Store securely encrypted backups in the cloud!
Richasy/Bili.Uwp
适用于新系统UI的哔哩
LykosAI/StabilityMatrix
Multi-Platform Package Manager for Stable Diffusion
openbullet/OpenBullet2
OpenBullet reinvented
NethermindEth/nethermind
A robust execution client for Ethereum node operators.
Version Downloads Last updated
5.1.2 152,394 6/19/2024
5.1.1 256,905 2/15/2024
5.1.0 3,070 2/15/2024
5.0.0 217,768 9/7/2023
4.7.0 56,575 9/1/2023
4.6.1 563,042 2/23/2023
4.6.0 5,896 2/21/2023
4.5.2 34,621 2/20/2023
4.5.1 644 2/20/2023
4.5.0 1,206 2/20/2023
4.4.43 956,961 11/21/2021
4.4.42 1,550 11/20/2021
4.4.40 31,806 11/20/2021
4.4.39 1,066 11/19/2021
4.3.38 224,171 8/31/2021
4.3.36 30,892 8/16/2021
4.3.35 31,585 7/21/2021
4.3.32 97,438 5/24/2021
4.3.30 163,256 2/11/2021
4.3.21 220,637 7/20/2020
4.3.15 78,102 5/13/2020
4.3.14 1,160 5/12/2020
4.3.12 13,809 4/26/2020
4.2.11 892 4/26/2020
4.2.3 42,264 3/10/2020
4.1.85 20,882 2/14/2020
4.1.83 904 2/14/2020
4.1.82 881 2/14/2020
4.1.81 1,480 2/14/2020
4.1.79 941 2/14/2020
4.1.78 97,997 1/24/2020
4.1.77 3,244 1/6/2020
4.1.76 9,878 12/18/2019
4.1.75 1,131 12/14/2019
4.1.74 3,062 12/10/2019
4.1.73 3,896 12/6/2019
4.1.70 968 12/6/2019
4.1.69 943 12/6/2019
4.0.66 4,980 12/5/2019
3.2.61 1,580 12/4/2019
3.2.59 6,309 11/21/2019
3.2.56 25,416 10/2/2019
3.2.55 883 10/2/2019
3.2.54 875 10/2/2019
3.2.52 958 9/27/2019
3.1.32 1,352 9/20/2019
3.1.29 1,816 9/19/2019
3.1.28 6,015 8/6/2019
3.1.26 7,704 8/2/2019
3.1.25 7,154 7/24/2019
3.1.24 925 7/24/2019
3.0.23 4,561 6/20/2019
3.0.20 4,748 5/13/2019
3.0.19 1,583 5/2/2019
3.0.18 12,426 3/26/2019
3.0.17 16,201 3/20/2019
3.0.15 1,716 3/12/2019
2.0.10 3,562 2/4/2019
2.0.7 1,381 2/4/2019
1.0.6 10,601 12/10/2018
1.0.5 2,051 12/7/2018
1.0.4 1,656 12/7/2018
1.0.3 1,745 12/7/2018
1.0.2 1,337 11/29/2018
1.0.1 2,042 11/29/2018

Enhancements