Use a fingerprint for server-client communication instead of 'worker-id', the latter will be used only as a display name in dashboard.
Fingerprint is a randomly generated string (say, 16 byte alphanumeric). After startup, the daemon looks up the 'worker-fingerprint' option in the config and if it's not present, generates and writes out a new one. Storing the fingerprint in the config allows for dashboard client statistics data continuity. Don't forget about keeping the fingerprint option intact while applying templates.
Advantages :
No merging of multiple clients with the same 'worker-id'
Wanted to do this myself at first but can't figure out how to do a config write-out yet.
Use a fingerprint for server-client communication instead of 'worker-id', the latter will be used only as a display name in dashboard. Fingerprint is a randomly generated string (say, 16 byte alphanumeric). After startup, the daemon looks up the 'worker-fingerprint' option in the config and if it's not present, generates and writes out a new one. Storing the fingerprint in the config allows for dashboard client statistics data continuity. Don't forget about keeping the fingerprint option intact while applying templates.
Advantages :
Wanted to do this myself at first but can't figure out how to do a config write-out yet.