Michel de Graaf
0630b548b9
Reading Nicotine+ and slskd against what was just written turned up three places where this client had the message right and the behaviour wrong. Excluded search phrases (code 160) are not a filter on the searches we send — the server already drops those. Nicotine+ applies them to the files it offers, leaving out any whose path carries an excluded phrase, and a reply with nothing left is not sent. Ours now does the same, and the local refusal of outgoing searches is gone. Serving children now follows the same rules as Nicotine+: the limit comes from the server's ParentMinSpeed and ParentSpeedRatio against the upload speed the server records for us (capped at ten, none at all below the minimum), children are refused until something feeds us the search stream and let go when it stops, a second link from a child we already carry is refused, and AcceptChildren is re-sent whenever that answer changes. Where the server has never reported our speed there is nothing to apply the formula to, so the configured cap stands, which is how slskd runs. Queued downloads now ask where they sit every five minutes, as Nicotine+ does, instead of only when a caller asks; a brokered file connection we cannot complete reports CantConnectToPeer like a control connection does; and a peer's shares can be asked for one folder at a time (peer code 36 and its reply, 37), which is what "download folder" is built on.
soulseek-rs-lib
A Rust library for implementing the Soulseek peer-to-peer protocol.
Website: https://re-invention.nl/soulseek-rs/
About
This library provides the core functionality for interacting with the Soulseek network. It can be used to build custom Soulseek clients.
Usage
Add this to your Cargo.toml:
[dependencies]
soulseek-rs-lib = "8"
Example
Simple Usage
use soulseek_rs::Client;
use std::time::Duration;
fn main() -> Result<(), Box<dyn std::error::Error>> {
// Create and connect to Soulseek server
let mut client = Client::new("username", "password");
client.connect()?;
client.login()?;
// Search for files
let results = client.search("Alex Kassian lifestream", Duration::from_secs(10))?;
// Download first available file
if let Some(result) = results.iter().find(|r| !r.files.is_empty()) {
let file = &result.files[0];
let (_download, status) = client.download(
file.name.clone(),
file.username.clone(),
file.size,
"~/Downloads".to_string(),
)?;
// `download` returns as soon as the request is queued: the transfer is
// finished when the channel says so, not when this call returns.
for update in status {
println!("{}: {update:?}", file.name);
}
}
Ok(())
}
Advanced Configuration
use soulseek_rs::{Client, ClientSettings, PeerAddress};
fn main() -> Result<(), Box<dyn std::error::Error>> {
// Create client with custom settings
let settings = ClientSettings {
server_address: PeerAddress::new("server.slsknet.org".to_string(), 2416),
enable_listen: true,
listen_port: 3000,
..ClientSettings::new("username", "password")
};
let mut client = Client::with_settings(settings);
client.connect()?;
client.login()?;
Ok(())
}
Asking about a peer
The server-backed lookups are request/poll pairs: you ask, then read the
answer once it lands. request_user_info clears any previous answer first, so
the loop below observes this request rather than the last one.
use soulseek_rs::Client;
use std::thread::sleep;
use std::time::{Duration, Instant};
fn main() -> Result<(), Box<dyn std::error::Error>> {
let mut client = Client::new("username", "password");
client.connect()?;
client.login()?;
client.request_user_info("someuser")?;
let deadline = Instant::now() + Duration::from_secs(10);
while Instant::now() < deadline {
if let Some(info) = client.user_info("someuser") {
// Presence and stats are separate replies, so each is an Option:
// a reply that never arrived is None, not "offline" or "shares nothing".
println!("{:?} {:?}", info.presence, info.stats);
break;
}
sleep(Duration::from_millis(100));
}
// Room membership is kept current from join and leave events.
println!("{:?}", client.room_members("lobby"));
Ok(())
}
ClientOperation is #[non_exhaustive]: every protocol message the client
learns to handle adds a variant, so match it with a wildcard arm. SharedFile
is too, so build it with the .. syntax rather than listing every field.