search

caronc / apprise

Apprise - Push Notifications that work with just about every platform!
https://hub.docker.com/r/caronc/apprise
BSD 2-Clause "Simplified" License
11.71k stars 410 forks source link

Maintain connections to servers to reduce latency #735

Open gdt opened 1 year ago

gdt commented 1 year ago

:bulb: The Idea I have been sending myself notifications over XMPP from two systems. One forks an xmpp-message process (from xmpppy) which connects (and hence negotiates TLS), logs in, sends and disconnects. The process takes 1.5s to run. Another system (with custom xmpp glue) maintains a connection and just sends messages; I think it's faster.

I think it would be nice if apprise had the ability to keep connections ready, to reduce latency.

:hammer: Breaking Feature

Obviously this is a huge architectural change, and I expect you already have your finger on the "out of scope" button by now. My suggestion does not feel entirely reasonable even to me and I am just throwing it out as a concept.

It would take a daemon that can read a config file and maintain sessions, for protocols where that's ok, and have a way to hand the message from an invocation off to the daemon. I don't have a good handle on which protocols would benefit from a persistent connection, and I don't know which ones would be ok with this. For xmpp it makes sense. Email would make sense, but it's not socially acceptable. But maybe TLS session resumption?

Feel free to hit close....

caronc commented 1 year ago

XMPP needs a full re-write; i pulled it out of Apprise a few releases ago.

amotl commented 1 year ago

Dear Greg,

your suggestion resonates very much with me. #679 is one little improvement into this direction, but I will re-attach to it and elaborate in a more general way when I can find some more time.

With kind regards, Andreas.

amotl commented 1 year ago

Obviously this is a huge architectural change.

Well, true. However, I also would like to vote to steer the architecture of Apprise into that direction. I think it will not do any harm when targeting this for one of the upcoming major releases, so that downstream users and services can adjust accordingly. On the same matter, I would like to discuss the throttling feature as well.

I did not ask Chris in detail about the reasons why he introduced it, yet [^1], but I guess he wanted to rate-limit egress traffic on some specific services, because Apprise would otherwise be flagged for abuse. However, to close the loop on this specific topic, I believe eventual flagging happened exactly because Apprise did not maintain a connection to the upstream service, and used a new connection for submitting each and every message.

The reason for that has been outlined very well in your original post: Connection setup, including TLS negotiation and running the login procedure, is an expensive process which usually gets rate-limited by upstream services, and will cause flagging when being abused too much.

It would take a daemon that can read a config file and maintain sessions.

That might be true. apprise-api would be such a service, for example. But, no matter into which service Apprise would be embedded, like Home Assistant, mqttwarn, or Kotori, I strongly believe Apprise itself should behave like a well-designed library and not come up with any surprises, following the principle of least surprise.

Attaching to my former comment, the specific rationale for improving the SMTP service plugin on this matter, can be found at https://github.com/caronc/apprise/pull/679#discussion_r1008916181.

[^1]: So I am especially happy that you started the discussion about this here.