Polling forces a choice: poll often and waste requests, or poll rarely and add latency.
Ready Bell tells your clients exactly when to check — with one small UDP packet.
How often should you poll for an asynchronous result?
Poll too often → waste requests.
Poll less often → increase latency.
Send a UDP packet to ready-bell.com:3137:
Listen <uuid> 60
When the operation finishes, Ready Bell sends:
Ready <uuid>
Fetch the result immediately.
Low request rate. Low latency.
Finish the work. Send one notification.
Your API starts an asynchronous operation.
When it's done, send a UDP packet to ready-bell.com:3137:
Notify <uuid>
Ready Bell finds the clients listening for that operation and sends them:
Ready <uuid>
Your backend doesn't need to know who's waiting.
One small UDP packet. Ready Bell handles the rest.
How it works
A Listener sends Listen <uuid> <seconds>. Later, a Notifier sends
Notify <uuid> when that UUID's result is ready. Ready Bell sends a
single Ready <uuid> packet to every Listener currently waiting on it.
Try it in 10 seconds
Terminal 1disconnected
Terminal 2disconnected
Click Listen in one terminal and Notify in the other.
Or try it in your own terminal
Run netcat in two terminals:
terminal 1 and 2
nc -u ready-bell.com 3137
Paste into terminal 1:
Paste into terminal 2:
Protocol reference
ready-bell speaks UTF-8 plain-text messages over UDP. Each datagram carries exactly
one command or response.
Initiator
Message
Response
Meaning
Listener client → Server
Listen <uuid> <ttlSeconds>
Registered <uuid> <ip> <port> <ttlSeconds>
Subscribe to a UUID for up to ttlSeconds seconds. The subscription is removed when the TTL expires. <ip> and <port> are the UDP source address observed by the server.
Notifier client → Server
Notify <uuid>
Notified <uuid> <n>
Notify all currently subscribed Listener clients. <n> is the number of notification packets sent.
Server → Listener client
Ready <uuid>
—
Notification sent to every Listener subscribed to the UUID, once per Notify.
Any client → Server
Invalid command
Error: <reason>
The command could not be parsed or validated.
Multiple Listener clients can subscribe to the same UUID — a Notify sends
Ready to all of them. Ready Bell runs over UDP and provides no delivery
guarantees: commands, responses, and notifications may be lost, duplicated, or
reordered. A Notified response only confirms the server attempted to send
the notification, not that it arrived — keep your regular re-check schedule running as
the fallback, and treat Ready purely as a hint to check sooner.
Code examples
Every example below talks to the live service at ready-bell.com:3137 —
nothing to run or host yourself.
Open two terminals and run this in each:
terminal 1 and 2
nc -u ready-bell.com 3137
In the first terminal, type this line and press enter:
terminal 1
Listen 3fa85f64-5717-4562-b3fc-2c963f66afa6 30
It prints Registered .... Within 30 seconds, type this in the second terminal:
terminal 2
Notify 3fa85f64-5717-4562-b3fc-2c963f66afa6
Terminal 2 prints Notified ... 1, and terminal 1 prints Ready 3fa85f64-5717-4562-b3fc-2c963f66afa6.
import java.net.*;
void main() throws Exception {
var uuid = "3fa85f64-5717-4562-b3fc-2c963f66afa6";
var address = new InetSocketAddress("ready-bell.com", 3137);
try (var socket = new DatagramSocket()) {
var bytes = ("Notify " + uuid).getBytes();
socket.send(new DatagramPacket(bytes, bytes.length, address));
var packet = new DatagramPacket(new byte[512], 512);
socket.receive(packet);
System.out.println(new String(packet.getData(), 0, packet.getLength()));
}
}
Drop-in integration for a Quarkus service, taken from the
ready-bell-demo project.
Incoming Ready notifications are fired as CDI events — handle them with
@Observes ReadyBellEvent.