[GH-ISSUE #158] UDP-based polling #129

New issue

Closed

opened 2026-05-05 03:49:34 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 03:49:34 -06:00

Owner

Originally created by @FedericoCeratto on GitHub (Mar 12, 2022).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/158

It would be nice to have UDP-based notification with a polling mechanism.

Use-cases:

FOSS Linux phones often put the CPU in deep sleep and are unable to wake up to process incoming notifications over TCP. They might also be unable to handle TCP keepalive packets to keep the TCP connection open.
Some mobile carriers aggressively tear down long-lived TCP connections.
On unreliable connections, mobile devices might frequently switch between GSM and WiFi, requiring to set up new TCP connections every time.

Proposed solution:

A client sends an encrypted query over an UDP port when the device CPU wakes up. This could happen at higher or lower frequency depending user preference VS battery saving etc.
The query is contains a list of (topic, timestamp) pairs. The timestamp is from the latest previous notification for that given topic.
A notifications server listens for incoming queries on a UDP port. It responds with a sequence of notifications (ordered by timestamp) in one encrypted+signed packet.
I'm assuming that 99% of the time a single-packet reply is enough.
- The server could add a flag to notify the client if a second query is needed.
- Alternatively it could reply with multiple packets with an incremental counter and a flag on the last packet, but this requires a slightly smarter client to handle reordering and retransmission.
The client ignores packets with an incorrect signature or notifications with a timestamp older that the current stored "latest" timestamp.

Perhaps this kind of implementation is off-topic for Ntfy?
Alternatively, UDP-based notification could instead be implemented on a DHT like https://github.com/savoirfairelinux/opendht

Originally created by @FedericoCeratto on GitHub (Mar 12, 2022). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/158 It would be nice to have UDP-based notification with a polling mechanism. Use-cases: - FOSS Linux phones often put the CPU in deep sleep and are unable to wake up to process incoming notifications over TCP. They might also be unable to handle TCP keepalive packets to keep the TCP connection open. - Some mobile carriers aggressively tear down long-lived TCP connections. - On unreliable connections, mobile devices might frequently switch between GSM and WiFi, requiring to set up new TCP connections every time. Proposed solution: - A client sends an encrypted query over an UDP port when the device CPU wakes up. This could happen at higher or lower frequency depending user preference VS battery saving etc. - The query is contains a list of (topic, timestamp) pairs. The timestamp is from the latest previous notification for that given topic. - A notifications server listens for incoming queries on a UDP port. It responds with a sequence of notifications (ordered by timestamp) in one encrypted+signed packet. - I'm assuming that 99% of the time a single-packet reply is enough. - The server could add a flag to notify the client if a second query is needed. - Alternatively it could reply with multiple packets with an incremental counter and a flag on the last packet, but this requires a slightly smarter client to handle reordering and retransmission. - The client ignores packets with an incorrect signature or notifications with a timestamp older that the current stored "latest" timestamp. Perhaps this kind of implementation is off-topic for Ntfy? Alternatively, UDP-based notification could instead be implemented on a DHT like https://github.com/savoirfairelinux/opendht

gitea-mirror

2026-05-05 03:49:34 -06:00

closed this issue
added the
enhancement

android-app
labels

gitea-mirror commented

2026-05-05 03:49:37 -06:00

Author

Owner

@binwiederhier commented on GitHub (Mar 12, 2022):

This is a wild idea. If I were to implement this, I'd suggest we do a simple "are there new messages since" approach, instead of sending back the messages themselves.

Like this:

Device -> server: 
{event:poll, topics: {mytopic:XfJgsn1hg, topic123: jksjHTIa}}

Server -> device:
{event:poll_response, topics:{mytopic:true}}

And then after that the device would have to poll via http, but only topic mytopic, since the server didn't indicate that there are new messages.

This approach avoids ever having to split up messages, and reordering, and even encryption.

@binwiederhier commented on GitHub (Mar 12, 2022): This is a wild idea. If I were to implement this, I'd suggest we do a simple "are there new messages since" approach, instead of sending back the messages themselves. Like this: ``` Device -> server: {event:poll, topics: {mytopic:XfJgsn1hg, topic123: jksjHTIa}} Server -> device: {event:poll_response, topics:{mytopic:true}} ``` And then after that the device would have to poll via http, but only topic mytopic, since the server didn't indicate that there are new messages. This approach avoids ever having to split up messages, and reordering, and even encryption.

gitea-mirror commented

2026-05-05 03:49:38 -06:00

Author

Owner

@FedericoCeratto commented on GitHub (Mar 12, 2022):

@binwiederhier are you concerned about the size of the notifications? In the examples I had in mind they were less than a hundred bytes each (before compression).

In any case authenticated encryption is still advisable to protect confidentiality of the topics.

@FedericoCeratto commented on GitHub (Mar 12, 2022): @binwiederhier are you concerned about the size of the notifications? In the examples I had in mind they were less than a hundred bytes each (before compression). In any case authenticated encryption is still advisable to protect confidentiality of the topics.

gitea-mirror commented

2026-05-05 03:49:39 -06:00

Author

Owner

@binwiederhier commented on GitHub (May 22, 2022):

I gotta be honest I have no intention of implementing this. This seems a little bit like an oddball request. I think I'd be happy to accept code for it, but I don't think I want to implement it.

I hope you understand that I cannot implement every feature that people wish for. Please keep the ideas coming and thank you for discussing it with me.

@binwiederhier commented on GitHub (May 22, 2022): I gotta be honest I have no intention of implementing this. This seems a little bit like an oddball request. I think I'd be happy to accept code for it, but I don't think I want to implement it. I hope you understand that I cannot implement every feature that people wish for. Please keep the ideas coming and thank you for discussing it with me.