<div dir="ltr">Dear list,<div>I have 3 interconnected nodes to which various devices connect to.</div><div>Once a device connects to one of those nodes, the related TCP socket events are handled by a device_loop process on the node that it originally connected to.<br></div><div><br></div><div>Every device is identified via its id (a binary). I need to enable communication from one device to the other based on these ids, even within different nodes. I have around 150k device processes per node (so up to 500k in total).</div><div><br></div><div>So, I basically need a global process registry. Not new, but haven't used one in a while now.</div><div><br></div><div>As far as I can tell, my main options to send messages from one device process to the other based on their id are the erlang <font face="monospace, monospace">global</font> module, ulf's <font face="monospace, monospace">gproc</font><font face="arial, helvetica, sans-serif">, or implement a custom solution based on, for instance, mnesia in ram only.</font></div><div><br></div><div><br><div>I was first thinking of leaning towards using the erlang <font face="monospace, monospace">global</font> module, since <font face="monospace, monospace">register_name/2,3</font> now also allows general terms to be used as Name. The advantages I see:</div></div><div><ul><li>It is a simple built-in mechanism.</li><li>If a node goes down, the global names registered on that node are unregistered automatically.</li><li>If a new node is added, the global names registered are propagated automatically.</li></ul><div>The cons:</div></div><div><ul><li>I always feel that process registration should be used to identify long-running services.</li><li>I don't know if 500k is an acceptable number (i.e. if the <font face="monospace, monospace">global</font> module is made to support my use case).</li></ul><div><br></div><div>I also looked into <font face="monospace, monospace">gproc</font>. The advantages I see:</div><div><ul><li>Actively maintained, it seems to have been built for my use case.</li></ul><div>The cons:<br></div></div><div><ul><li>For the distributed part it relies on <font face="monospace, monospace">gen_leader</font>. I've heard too many horror stories onĀ <span style="font-family:monospace,monospace">gen_leader</span><font face="arial, helvetica, sans-serif">. Maybe that's not a thing anymore.</font></li><li><font face="arial, helvetica, sans-serif">Not sure what happens if a node goes down / a new node is added.</font></li></ul><div><font face="arial, helvetica, sans-serif"><br></font></div></div></div><div><font face="arial, helvetica, sans-serif">I've considered a custom solution based on mnesia distributed ram-only tables that would store the pids of the device loops based on their binary id.</font>The advantages I see:</div><div><ul><li>Mnesia will take care of distributing, handling down events, etc.</li></ul><div>The cons:<br></div></div><div><ul><li>I need to reinvent the wheel and ensure that when a node goes down, all the device entries in the distributed mnesia tables related to that node are removed.</li></ul><div><br></div></div><div><br></div><div>Has someone recently implemented a distributed process registry and can shed some light for me?</div><div><br></div><div>Thank you in advance for your advice ^^_</div><div>r.</div><div><br></div><div><br></div></div>