Create an enhanced version of the rwhod protocol #9

New Issue

oysteikt · 2026-01-04T18:55:27+01:00

oysteikt commented

2026-01-04 18:55:27 +01:00

The rwhod protocol is quite limited in several ways. It has hard limits on how much data you can transfer, it has hard limits on how long the user and hostnames can be. Maybe it would be good to bump that protocol version number and let the roowho2 daemons talk an improved protocol between each other.

The old protocols still need to be supported, so that roowho can talk with other systems that use the old versions of the software.

The rwhod protocol is quite limited in several ways. It has hard limits on how much data you can transfer, it has hard limits on how long the user and hostnames can be. Maybe it would be good to bump that protocol version number and let the `roowho2` daemons talk an improved protocol between each other. The old protocols still need to be supported, so that roowho can talk with other systems that use the old versions of the software.

oysteikt added the feature request label 2026-01-04 18:55:27 +01:00

oysteikt commented

2026-01-05 18:21:42 +01:00

It would be nice if the new protocol could stop broadcasting to every single machine, and target those who are actually interested.

How about we use mdns service discovery to announce that a host has a roowho2-whod service, and then monitor for similar service entries, and then we multicast to the machines who are interested?

It would be nice if the new protocol could stop broadcasting to every single machine, and target those who are actually interested. How about we use mdns service discovery to announce that a host has a roowho2-whod service, and then monitor for similar service entries, and then we multicast to the machines who are interested?

oysteikt commented

2026-01-06 04:07:24 +01:00

Note that if we do the mdns service discovery trick, we can also optimize sending the v1 protocol, by seeing who broadcasts messages to us and multicasting to those hosts only.

However, if we were to do this now then all the roowho daemons would wait for each other to be the first one out, so it's a no go until there is an alternative discovery mechanism

Note that if we do the mdns service discovery trick, we can also optimize sending the v1 protocol, by seeing who broadcasts messages to us and multicasting to those hosts only. However, if we were to do this now then all the roowho daemons would wait for each other to be the first one out, so it's a no go until there is an alternative discovery mechanism

oysteikt added the big label 2026-01-06 10:18:33 +01:00

Sign in to join this conversation.

No Assignees

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Projects/roowho2#9