Change Details

Currently, if a WS client subscribed to multiple scripts / token IDs and then a tx is received that matches the scripts / token IDs multiple times, it would be send to the WS client multiple times. This is almost never what the user expects, and wastes bandwidth, especially for HD wallets that subscribe to many addresses. We add a simple deduplication by keeping track of the last binary WS message sent to a WS client, and skipping sending the msg if the last msg is identical, in binary encoding. Note that we have to match only to `Binary` messages because otherwise we would deduplicate pings, which is not what we want. Depends on D15389.

Currently, if a WS client subscribed to multiple scripts / token IDs and then a tx is received that matches the scripts / token IDs multiple times, it would be send to the WS client multiple times. This is almost never what the user expects, and wastes bandwidth, especially for HD wallets that subscribe to many addresses. We add a simple deduplication by keeping track of the last binary WS message sent to a WS client, and skipping sending the msg if the last msg is identical, in binary encoding. Note that we have to match only to `Binary` messages because otherwise we would deduplicate pings, which is not what we want. The implementation here still wastes some compute resources by building & serializing etc. the msg in the first place; however, the way the subscription system is designed makes it very difficult to deduplicate messages earlier. This here solution is extremely simple, memory friendly and easy to maintain. Depends on D15389.

Currently, if a WS client subscribed to multiple scripts / token IDs and then a tx is received that matches the scripts / token IDs multiple times, it would be send to the WS client multiple times. This is almost never what the user expects, and wastes bandwidth, especially for HD wallets that subscribe to many addresses. We add a simple deduplication by keeping track of the last binary WS message sent to a WS client, and skipping sending the msg if the last msg is identical, in binary encoding. Note that we have to match only to `Binary` messages because otherwise we would deduplicate pings, which is not what we want. The implementation here still wastes some compute resources by building & serializing etc. the msg in the first place; however, the way the subscription system is designed makes it very difficult to deduplicate messages earlier. This here solution is extremely simple, memory friendly and easy to maintain. Depends on D15389.