ready-bell.com:3137 · UDP

Get results the moment they’re ready.

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.

Poll less. Know when to check.

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.

Sequence diagram of the ready-bell protocol between a Listener client, the server, and a Notifier client Listener ready-bell.com:3137 Notifier Listen uuid 30 Registered uuid ip port 30 Notify uuid Ready uuid Notified uuid 1

Try it in 10 seconds

Terminal 1 disconnected

            
Terminal 2 disconnected

            

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.

Questions, feedback or interested in using Ready Bell?

ready-bell@proton.me