<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hello, Matthew.</div>
<div> </div>
<div>I'm a beginner, too. I just perked my ears when you wrote about the "which_children()" call...</div>
<div> </div>
<div>The gen_xyz() modules all follow a similar startup logic that allow you to register the child under an ID. The way you see used in "Learn you some Erlang good" is the easiest one, the local registration ({local, <name>}) where <name> must be an atom. You can, however, use other registries - like "global". Google "man erlang global" for more details about that registry. There an arbitary expression is good enough as a name.</div>
<div> </div>
<div>This is hugely advantageous for many applications, including your own, as you can use something like {<atom>, <number>} or {<atom>, <string>} as process name. With global:whereis_name you can ask for the needed PID to send messages to. It returns undefined if it doesn't exist. So, instead of asking the supervisor about the children, you just call whereis_name with the computed ID you would be looking for, like {user, "DanWahlberg69" } and if you get something else but undefined, you can directly talk to the worker you are looking for. This should keep your supervisors simple.</div>
<div> </div>
<div>All you need is a scheme to generate unique names and you are set. </div>
<div> </div>
<div>Hope this helps,</div>
<div>Oliver</div>
<div>
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b> Dienstag, 22. März 2016 um 04:06 Uhr<br/>
<b>Von:</b> "Matthew Shapiro" <me@mshapiro.net><br/>
<b>An:</b> erlang-questions@erlang.org<br/>
<b>Betreff:</b> [erlang-questions] Beginner trying to figure out idiomatic OTP architecture</div>
<div name="quoted-content">
<div>
<div>I am trying to learn Erlang in order to create an application that seems to check off all the boxes of the Beam VM (low latency requirements, extremely concurrent, long lasting connections making hot code swapping desirable for upgrades, etc...). In order to learn I've gone through most of Learn You Some Erlang For Great Good, and so far have really been enjoying the process.</div>
<div> </div>
<div>I am now at the point where I want to test some of this knowledge out, and I thought a good idea was to create a (basic) IRC server (as I've written them in the past in other languages, and it seemed like a good use case for Erlang). Basic idea is to support allowing users to connect, set a nickname, connect to channels, send messages to channels, and send messages to users.</div>
<div> </div>
<div>However, I am a bit confused on the proper way to architect an OTP application and hoping that my current idea of how to architect this is correct or not. Also, I find rubber ducking helps :)</div>
<div> </div>
<div>The high level supervision tree I have floating in my head is to have:</div>
<div> </div>
<div>* application</div>
<div>** app_supervisor</div>
<div>*** tcp_listener</div>
<div>*** handshake_supervisor</div>
<div>**** handshake servers (dynamic)</div>
<div>*** user_supervisor</div>
<div>**** user servers (dynamic)</div>
<div>*** channel_supervisor</div>
<div>**** channel servers (dynamic)</div>
<div> </div>
<div>My thinking is the tcp_listener, handshake, user, and channel modules would each be gen_servers, and the 4 supervisors would be standard otp supervisors. The app_supervisor would have a one_for_one spec while user_supervisor, chandshake_supervisor and channel supervisor would have simple_one_for_one spec since they can spin children up and down dynamically based on users connected and channels with at least one user in it.</div>
<div> </div>
<div>The flow I have in my head is:</div>
<div> </div>
<div>1) tcp_listener is a server that waits for connections, accepts them and tells the handshake_supervisor to spawn a new handshake server for the accepted socket (and changes ownership of the socket to the handshake server.</div>
<div>2) The handshake server handles the IRC handshake, and when the user requests a nickname it asks the user_supervisor if any children exist with the id matching the requested nickname. </div>
<div>3) If the nickname is available, the handshake server tells the user_supervisor to start a new user server with the accepted socket and nickname, sets the user server as the socket owner, and then the handshake server terminates</div>
<div>4) When the user server is started, the user_supervisor would set its id of the child spec to be the user's nickname.</div>
<div>5) When the user joins a channel, the user module sends the accepted socket and the users nickname to the channel_supervisor and asks it to send it to the correct channel. The channel_supervisor will look for a child process with the id matching the name of the channel, and if none exists it will create a new child with the channel name as the id in the child spec. It will then send the child process with the matching id/name a message with the users nickname.</div>
<div>6) When the user leaves a channel it will call on the channel_supervisor to send a message to the child process with a matching id/name with the nickname of the user leaving the channel (or disconnecting).</div>
<div>7) The channel server will keep a state with a list of connected users, and when a join, leave, or channel message is received it will modify the client list as needed. </div>
<div>8) When required (user joins, user leaves, someone says something, etc....) The channel server will send a message to a specific user by calling the user_supervisor to send a string to a child process with an id matching the nickname of the user, and send that child process an erlang message with the irc message to send to the user. The user server will then take that, translate it into the IRC protocol and send it to the socket.</div>
<div>9) On client disconnection, the user server will announce to the channel supervisor that it has disconnected, and the channel supervisor will tell all children it no longer is connected to the channel.</div>
<div> </div>
<div> </div>
<div>So the problem I have on this architecture is it requires a lot of logic in the supervisors (which I am not sure is a good or bad thing). It also seems to invite myself to race conditions due to all the supervisor:which_children() calls that would be required to identify the correct child process to send a message to, since theoretically a child process could die between a which_children() and actually sending the message. It also means going through several layers of supervisors in order to find the process another process needs to communicate with (for example, user server would have to ask the user_supervisor to ask the app_supervisor what process the channel_supervisor is, which would then have to ask the channel_supervisor what process the correct channel server is). This seems hacky but I am unsure of how to work around that.</div>
<div> </div>
<div>Am I on the correct path with this? Is there an easier way to facilitate servers talking to other servers managed by other supervisors?</div>
<div> </div>
<div>Thanks.</div>
</div>
_______________________________________________ erlang-questions mailing list erlang-questions@erlang.org <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a></div>
</div>
</div></div></body></html>