Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace long polling to receive events with Server Sent Events (SSE) #475

Open
stalniy opened this issue May 25, 2019 · 11 comments · May be fixed by matrix-org/matrix-spec-proposals#2108
Open
Labels
A-Client-Server Issues affecting the CS API feature Suggestion for a significant extension which needs considerable consideration

Comments

@stalniy
Copy link

stalniy commented May 25, 2019

Description:

Server Sent Events(SSE) is better than long polling because it creates only 1 persisted connection to server and keeps it open "forever". This technology was specifically designed to overcome challenges related to short/long polling.
SSE is built on top of HTTP protocol, so also can be used in communication between servers. Also SSE is more compliant with existing IT infrastructure like (Load Balancer, Firewall, etc), unlike WebSockets which can be blocked by some firewall.

Currently all major web browsers supports SSE (for those which don't support it's easy to do fallback to long/short polling). There are some cool features which browsers support out of the box:

  • automatic reconnection
  • remember lastEventId and send it automatically on reconnection.

Check this for reference:

@richvdh
Copy link
Member

richvdh commented May 26, 2019

this would need to be a matrix protocol change, so moving to matrix-doc.

@richvdh
Copy link
Member

richvdh commented May 26, 2019

or not, since github is giving 500 errors right now

@turt2live turt2live transferred this issue from matrix-org/synapse May 26, 2019
@turt2live
Copy link
Member

moved

@turt2live turt2live added A-Client-Server Issues affecting the CS API feature Suggestion for a significant extension which needs considerable consideration labels May 26, 2019
@stalniy
Copy link
Author

stalniy commented May 27, 2019

What can I do to push this forward? Do I need to create a proposal to protocol change as described here?

@turt2live
Copy link
Member

Yup. That'd be the first steps

@uhoreg
Copy link
Member

uhoreg commented May 27, 2019

I've thought about this a bit before, so I'll dump my thoughts here. (I don't have time to work on it right now.)

  • create a new endpoint to do sync over SSE (e.g. /sync/stream)
    • used to get the same data as continually calling /sync with the same parameters
    • accepts the same parameters as /sync, except without since or timeout
    • instead of using the since query parameter, the next batch token will be passed through the Last-Event-ID header.
  • each event will have the same format as what /sync returns. The id of each event will be the next_batch token
    • the server sends events in exactly the same way that it would send responses to /sync calls with the since parameter set to the previous next_batch

Using SSE in this way means that existing code can be reused for SSE

@stalniy
Copy link
Author

stalniy commented Jun 11, 2019

Created proposal for the change

@ell1e
Copy link

ell1e commented Jul 12, 2020

Isn't there a websocket draft already? https://github.com/matrix-org/matrix-spec/blob/main/attic/drafts/websockets.rst Wouldn't that one already serve the same purpose?

@stalniy
Copy link
Author

stalniy commented Jul 13, 2020

The important thing is that event stream is just an HTTP request and it should be easier to use it from native clients (iOS, Android) and for cross server communication

@ell1e
Copy link

ell1e commented Jul 13, 2020

Ah, so it's just easier to implement. Fair enough, I guess that is as good enough of a reason as any, in the end it doesn't really matter after all what approach is used. So I assume if this goes through that websocket draft will go unused? (It'd be a bit weird to attempt to implement both)

@ell1e
Copy link

ell1e commented Nov 29, 2020

For what it's worth, this is somewhat not only blocking F-Droid/non-gapps Android matrix clients from decent battery life, but also those on Linux mobiles like the PinePhone/PineTab/Librem 5, or new ARM64 laptops like repurposed Chromebooks with Linux or the Pinebook. (Since on those platforms, there simply isn't any Firebase or similar available either. Well, Ubuntu Touch has it, but none of all of the other linux variants.)

@richvdh richvdh transferred this issue from matrix-org/matrix-spec-proposals Mar 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Client-Server Issues affecting the CS API feature Suggestion for a significant extension which needs considerable consideration
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants