消息传递到另一个节点上的特定进程-Erlang

Question

My problem is the following

Let's say I have two Erlang nodes A and B on different machines, they were started with the same cookie value, and they're both running the same server app of mine

and let's say there are two users, user1 and user2

user1 has been connected to A, user2 has been connected to B

when user (any user) connects to Erlang node (any node, chosen by load balancer), looping function tcp_accept() spawns a separate thread for him and recursively continues , BUT the spawned PID is never registered, neither locally nor globally. rather i save the node name and PID (local for that node) as a tuple identifying the process, in some DB

An hour ago i thought that the node name and PID (local for that node name) are two sufficient credentials which let us send messages to that thread from any other distributed node (started with same cookie)

Now that i've reached this part of task, i can't figure out how to do that

Is it actually possible to send message to process running on particular node, knowing only the node name and thread PID (local for that node) ?

PS. i don't want to register PIDs because the system is aimed to accept connections from lots of users simultaneously and Erlang tutorial discourages registering every user process, since registered names are atoms which are not garbage collected so this may lead to memory leakage. rather it suggests storing <username, PID> pairs in some storage

Answer 1

The servers should keep a trace of any connected user (pid of the "user process", node, nickname ...). They also should know each other. When a user A want to connect to another user B, he will do it using its nickname, the request is sent to the local server which in turn look for this nickname locally and on remote servers. If the search succeed, it will be able to send back the connection information of user B to the user A process. Then the "direct" communication can start.

This pattern does not look very good since processes can crash, and particularly user processes (disconnection, bad entry, timeout...). I think that the usual way is to send messages to a server(s), using logical addresses (nickname for example), and the server is in charge to dispatch, store, retreive... the messages