Lavalink's main goal is to distribute load between many nodes
-> switching / rebalancing nodes is a primary use case.
To this end, any state held by a Lavalink node about a connection needs to be minimized, as well as being accessible to a client.
-
Player
A player object which is as the same time an audio send handler (or very tightly coupled to one) is responsible for loading a track via lavaplayer. A player is coupled to an audio connection, but it may exist without one. An audio connection is identified by userId + guildId, therefore a player can be identified by these too. Special cases for the future: Multicasted Radio Streams. -
MagmaAPI
Handles the opening of the AudioConnection to Discord. See the link above for more information. -
SocketContext
A Lavalink node supports connections from several clients. Each connected client is represented by a SocketContext. Clients can be several shards of a single bot, or several bots, or a mix of those. It is the clients responsibility to ensure that userId/guildId combinations they represent do not overlap.
The Player knows two states:
- PLAYING
- PAUSED
Stopping a player is the equivalent to destroying it, and leads to it being cleaned up.
This means, any state, like volume, needs to be always sent along with a PLAY request.
In case the websocket connection between the server and the client is severed, a resume should be attempted. Upon successfully resuming, the server shall play back all events that happened during the disconnect.
If the client does not resume after , the server should close and clean up all connections belonging to that client.
If the server is not reachable for resuming, the client should distribute the active players of that node onto other nodes.