Which package is the feature request for?
ws
Feature
The code has been cleaned up and restructured to make it simpler.
The gateway will not expose an adapter due to the complexity of the gateway and users are urged to implement the existing solution in addition to the handler.
In the future, the concept of platforms and transports will be added.
Platforms will be systems (such as adapters) to manage and route usage, while transports will be communication strategies between processes/workers.
- @biscuitland/ws should be better documented and factored some code.
- @biscuitland/ws will not be able to be exposed in a pre-finished form and will require the use of platforms and transporters.
- @biscuitland/ws because of the complexity of the library has been preferred to have a more readable code than the rest of the biscuitland libraries.
- @biscuitland/ws everything done to make
[Connecting - STEP 1]
- Client should immediately receive an Opcode 10 Hello payload [READY].
- Client can start sending Opcode 1 Heartbeat payloads after heartbeat_interval * jitter [NOT READY].
- The gateway may request a heartbeat from the client in some situations by sending an Opcode 1 heartbeat . When this occurs, the client should immediately send an Opcode 1 Heartbeat without waiting for the remainder of the current interval. [READY]
- Each time the client sends a heartbeat, the gateway will respond with Opcode 11 Heartbeat ACK [READY].
- If a client does not receive a heartbeat acknowledgement between its attempts to send heartbeats, this may be due to a failed or "zombie" connection. Then, the client should immediately terminate the connection with a closing code other than 1000 resume<Resume>. [READY]
[identifying - STEP 2]
- If the payload is valid, the gateway will respond with a ready<Ready> event. [READY]
- Limited by maximum concurrency the gateway will respond with an Opcode 9 Invalid Session [READY].
[resuming - STEP 3]
- Disconnects occur, especially with persistent connections. [READY]
- Due to Discord's architecture, this is a semi-regular event [READY].
- Your client must store the session_idy resume_gateway_url of the ready<Ready> [READY].
- When your client detects that it has disconnected, it should close the connection completely and open a new one [SEMI-READY]
- (following the same strategy as Connecting / STEP 1) [READY] [READY]
- resume_gateway_url Once the new connection has been opened, the client must send a Resume Gateway<Resume> [READY].
- the client must send a Gateway resume<Resume> [READY].
- If successful, the gateway will respond by replaying all the lost events in order [NOT READY]
- ending with a resumed<Resumed> event to indicate that playback is complete and all subsequent events are new [NOT READY].
- In which case the client will receive an invalid opcode 9 session and is expected to wait a random amount of time, between 1 and 5 seconds, and then send a new opcode 2 ID [NOT READY].
- If not respected, it is resume_gateway_url possible that your client will be forced to reconnect after a short period of time. [NOT READY]
[Disconnections - INT]
- If the gateway ever issues a disconnect to your client, it will provide a shutdown event code that you can use to properly handle the disconnect. A complete list of these shutdown codes can be found in the Response Codes documentation. [READY]
- When you close the connection to the gateway with close code 1000 or 1001, your session will be invalidated and your bot will appear offline. If you simply close the TCP connection or use a different close code, the bot session will remain active and timeout after a few minutes. This may be useful for a reconnection, which will resume the previous session. [NOT READY]
[Tracking Status - INT]
- Most of a client's status is provided during the ready<Ready> [READY] event.
- Discord expects clients to locally cache as many relevant object states as possible and update them as gateway events are received. [READY]
[Advanced Fragmentation - INT]
- Fragmentation formula (shard_id = (guild_id >> 22) % num_shards) [READY].
- Note that num_shards does not relate to or limit the total number of potential sessions: it is only used to route traffic. As such, sessions do not have to be identified in an evenly distributed manner when fragmenting [READY]
- [shard_id, num_shards]or sessions with different num_shardsvalues. This allows you to create sessions that will handle more or less traffic than others for tighter [READY] load balancing
- orchestrate "zero downtime" scaling/upgrading by transferring traffic to a new implementation of sessions with a higher or lower num_shardscount that are prepared in parallel. [READY]
[Maximum concurrency]
- rate_limit_key = shard_id % max_concurrency [READY].
- This puts your shards into "buckets" of max_concurrencysize. When you start your bot, you can start with max_concurrencyfragments at a time, and you must start them by "bucket" in order. [READY]
Ideal solution or implementation
The ideal solution is basically planned and implemented.
it is necessary to add some types, better comment the code and allow advanced customizations to @biscuitland/ws
technical tests performed on the @biscuitland/ws library conclude a negligible use of resources.
Tested on a bot with 250,000+ guilds and more than 200 shards the constant consumption has been 120mb / 250mb and the CPU usage has remained below 2% at all times.
The @biscuitland/ws does not hold any cache currently. And it will be projected to go through @biscuitland/cache for the use of the platforms.
- @biscuitland/ws has been tested and is functional.
- @biscuitland/ws is tested in heavy event usage
Alternative solutions or implementations
No response
Other context
No response
Feature Future major
6 Dec 19, 2022
89 Dec 20, 2022
14 Dec 12, 2022
5 Dec 27, 2022
6 May 19, 2022
3 Dec 2, 2022
1 Dec 5, 2022
3 Mar 19, 2022
8 May 19, 2022
16 Oct 26, 2022
5 Sep 6, 2022
12 Apr 15, 2022
65 May 7, 2022
77 Dec 30, 2022
31 Dec 14, 2022
5 May 20, 2022
10 Nov 12, 2022
48 Dec 21, 2022