[PR #753] [MERGED] Add basic websocket support #1061

New issue

Closed

opened 2026-02-27 20:01:00 +03:00 by kerem · 0 comments

kerem commented

2026-02-27 20:01:00 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/librespot-org/librespot/pull/753
Author: @Johannesd3
Created: 5/23/2021
Status: ✅ Merged
Merged: 5/26/2021
Merged by: @Johannesd3

Base: new-api ← Head: new-api

📝 Commits (1)

1ade02b Add basic websocket support

📊 Changes

11 files changed (+1040 additions, -68 deletions)

View changed files

📝 Cargo.lock (+136 -0)
📝 core/Cargo.toml (+2 -1)
📝 core/src/apresolve.rs (+18 -16)
📝 core/src/connection/mod.rs (+2 -46)
➕ core/src/dealer/maps.rs (+117 -0)
➕ core/src/dealer/mod.rs (+586 -0)
➕ core/src/dealer/protocol.rs (+39 -0)
📝 core/src/lib.rs (+8 -3)
📝 core/src/session.rs (+2 -2)
➕ core/src/socket.rs (+35 -0)
📝 core/src/util.rs (+95 -0)

📄 Description

(Copied from https://github.com/librespot-org/librespot/discussions/734#discussioncomment-772619)

So, here's my first attempt of websocket support: https://github.com/Johannesd3/librespot/tree/new-api/core/src/dealer

It uses tungstenite and tokio-tungstenite as websocket library.
There's a Builder struct to register handlers before a connection is established.
After the Builder is created, there are two ways to launch the Dealer:
- Builder::launch: Attempts to connect, returns a Dealer on success and an error otherwise.
- Builder::launch_in_background: Returns immediately a Dealer and behaves as if it would be reconnecting (see below).
Reconnecting: If the connection is closed or the server doesn't react on pings, there's an attempt to reconnect every 10 seconds (but all replies sent in between are lost). It calls a closure to get a new token, in case it expires.
Message handling: It's possible to subscribe to any uri an arbitrary number of times. Every message sent to a "sub-uri" will be received.
Request handling: One can add exactly one RequestHandler per uri. Currently, these handlers indicate success by returning a bool. But that's easy to change.
The handlers are stored in custom tree structs, hierarchally by uri components. Maybe it's too complicated - or maybe such a tree would also be useful for mercury.
Messages and requests are parsed with serde/serde_json.
Request payloads are gzip-decoded if necessary (using flate2). I was not able to test whether it works, I didn't receive a gzipped request (I didn't receive a request at all).

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/librespot-org/librespot/pull/753 **Author:** [@Johannesd3](https://github.com/Johannesd3) **Created:** 5/23/2021 **Status:** ✅ Merged **Merged:** 5/26/2021 **Merged by:** [@Johannesd3](https://github.com/Johannesd3) **Base:** `new-api` ← **Head:** `new-api` --- ### 📝 Commits (1) - [`1ade02b`](https://github.com/librespot-org/librespot/commit/1ade02b7ad1c20de775d10c0f0a0c48e0ca25038) Add basic websocket support ### 📊 Changes **11 files changed** (+1040 additions, -68 deletions) <details> <summary>View changed files</summary> 📝 `Cargo.lock` (+136 -0) 📝 `core/Cargo.toml` (+2 -1) 📝 `core/src/apresolve.rs` (+18 -16) 📝 `core/src/connection/mod.rs` (+2 -46) ➕ `core/src/dealer/maps.rs` (+117 -0) ➕ `core/src/dealer/mod.rs` (+586 -0) ➕ `core/src/dealer/protocol.rs` (+39 -0) 📝 `core/src/lib.rs` (+8 -3) 📝 `core/src/session.rs` (+2 -2) ➕ `core/src/socket.rs` (+35 -0) 📝 `core/src/util.rs` (+95 -0) </details> ### 📄 Description (Copied from https://github.com/librespot-org/librespot/discussions/734#discussioncomment-772619) So, here's my first attempt of websocket support: https://github.com/Johannesd3/librespot/tree/new-api/core/src/dealer * It uses [tungstenite](https://crates.io/crates/tungstenite) and [tokio-tungstenite](https://crates.io/crates/tokio-tungstenite) as websocket library. * There's a [`Builder`](https://github.com/Johannesd3/librespot/blob/ad92db0c24f74d0f103ba091b89ce830f9f423a7/core/src/dealer/mod.rs#L116-L194) struct to register handlers before a connection is established. * After the `Builder` is created, there are two ways to launch the [`Dealer`](https://github.com/Johannesd3/librespot/blob/ad92db0c24f74d0f103ba091b89ce830f9f423a7/core/src/dealer/mod.rs#L253-L312): * [`Builder::launch`](https://github.com/Johannesd3/librespot/blob/ad92db0c24f74d0f103ba091b89ce830f9f423a7/core/src/dealer/mod.rs#L178-L193): Attempts to connect, returns a `Dealer` on success and an error otherwise. * [`Builder::launch_in_background`](https://github.com/Johannesd3/librespot/blob/ad92db0c24f74d0f103ba091b89ce830f9f423a7/core/src/dealer/mod.rs#L170-L176): Returns immediately a `Dealer` and behaves as if it would be reconnecting (see below). * Reconnecting: If the connection is closed or the server doesn't react on pings, there's an attempt to reconnect every 10 seconds (but all replies sent in between are lost). It calls a closure to get a new token, in case it expires. * Message handling: It's possible to subscribe to any uri an arbitrary number of times. Every message sent to a "sub-uri" will be received. * Request handling: One can add exactly one [`RequestHandler`](https://github.com/Johannesd3/librespot/blob/ad92db0c24f74d0f103ba091b89ce830f9f423a7/core/src/dealer/mod.rs#L93-L96) per uri. Currently, these handlers indicate success by returning a bool. But that's easy to change. * The handlers are stored in [custom tree structs](https://github.com/Johannesd3/librespot/blob/new-api/core/src/dealer/maps.rs), hierarchally by uri components. Maybe it's too complicated - or maybe such a tree would also be useful for mercury. * [Messages and requests are parsed with `serde`/`serde_json`](https://github.com/Johannesd3/librespot/blob/new-api/core/src/dealer/protocol.rs). * Request payloads are `gzip`-decoded if necessary (using [flate2](https://crates.io/crates/flate2)). I was not able to test whether it works, I didn't receive a gzipped request (I didn't receive a request at all). --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

kerem

2026-02-27 20:01:00 +03:00

closed this issue
added the
pull-request
label

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/librespot#1061

No description provided.

Rows
Columns