element-hq / element-hq/synapse

Servers can end up on a long backoff and may not have an excuse to poke each other to be 'woken'

Open
#8,346 0 comments 0 reactions 0 assignees View on GitHub
A-Federation T-Enhancement z-p2
Dominant language
Python
Stars
4.6k
Forks
600
Avg merge
5d 22h
Merged PRs (30d)
51

Description

This issue has been migrated from [#8346](https://github.com/matrix-org/synapse/issues/8346).

---

My recent work involving Catch-up after Federation is all well and good, but one little thing remains that niggles me a bit:

If a (probably) small server goes offline for a while, other servers will more or less give up on it — it will get a long backoff.

If that server ever comes online again, other servers won't retry sending to it for either a long time, or until they hear from that server in the first place.

Problem is, 'hearing' from that server may not happen if there is nothing to be heard about — presence EDUs are a good excuse for a transaction (which is kind of funny when a user sees all their rooms backfill as they log in, but oh well) but some servers have presence disabled.

I guess we want some way of making our server poke others to let them know we are online.

Problems with this:

- when?
- how? (empty `/send`?)
- This seems to be very Synapse-centric — i.e. it kind of relies on knowing that Synapse will 'wake' us if we poke it — but other server implementations may act differently. I guess it would want some spec recommendations...

Contributor guide

Open the contributing guide

Research direction

The issue names no files, tests, or entry points. Start by reading Synapse's federation catch-up and server backoff behavior, then determine when and how an online server should notify peers, including whether an empty /send is appropriate. Done means the timing and mechanism are defined, with any needed Matrix federation specification recommendations.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
distributed-systems, networking
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.