Comments on: An introduction to gen_fsm: ErlyBank’s ATM http://spawnlink.com/articles/an-introduction-to-gen_fsm-erlybanks-atm/ Linking You to Erlang Sun, 22 May 2011 00:00:29 +0000 http://wordpress.org/?v=2.6.1 By: Matt http://spawnlink.com/articles/an-introduction-to-gen_fsm-erlybanks-atm/#comment-3065 Matt Thu, 05 Mar 2009 16:06:21 +0000 http://spawnlink.com/?p=52#comment-3065 Simple, concise easy to understand article. Thank you Simple, concise easy to understand article.

Thank you

]]>
By: John Bender http://spawnlink.com/articles/an-introduction-to-gen_fsm-erlybanks-atm/#comment-1069 John Bender Tue, 16 Dec 2008 18:20:15 +0000 http://spawnlink.com/?p=52#comment-1069 Mitchell, What are you using for your syntax highlighting? Mitchell,

What are you using for your syntax highlighting?

]]>
By: Denis Laprise http://spawnlink.com/articles/an-introduction-to-gen_fsm-erlybanks-atm/#comment-801 Denis Laprise Thu, 20 Nov 2008 19:05:26 +0000 http://spawnlink.com/?p=52#comment-801 Hello, Unusual question, but what did you use to draw your sequence diagram? :) Thanks! Hello,

Unusual question, but what did you use to draw your sequence diagram? :)
Thanks!

]]>
By: Mitchell http://spawnlink.com/articles/an-introduction-to-gen_fsm-erlybanks-atm/#comment-140 Mitchell Mon, 29 Sep 2008 23:09:56 +0000 http://spawnlink.com/?p=52#comment-140 David, From what I've found, when in doubt, just spawn a new process :P Erlang processes are extremely lightweight and spawn extremely fast. But under extremely heavy traffic, OTP can get a bit heavy. From what I've experienced, however, its better to just stick to the standards rather than grow-your-own solution. After hitting the OTP "limit" I would scale horizontally by distributed your Erlang application rather than worry about rewriting the whole thing w/o OTP. Mitchell David,

From what I’ve found, when in doubt, just spawn a new process :P Erlang processes are extremely lightweight and spawn extremely fast. But under extremely heavy traffic, OTP can get a bit heavy. From what I’ve experienced, however, its better to just stick to the standards rather than grow-your-own solution. After hitting the OTP “limit” I would scale horizontally by distributed your Erlang application rather than worry about rewriting the whole thing w/o OTP.

Mitchell

]]>
By: David Weldon http://spawnlink.com/articles/an-introduction-to-gen_fsm-erlybanks-atm/#comment-134 David Weldon Mon, 29 Sep 2008 19:02:55 +0000 http://spawnlink.com/?p=52#comment-134 Going back to the multiple FSMs idea from David C: lets say I have a system where I have thousands of live transactions and each one only lives for a few seconds. The nature of each transaction is an FSM, so using gen_fsm makes sense. Like the ATMs, each transaction has its own state so I'd need thousands of little servers. Does it make sense that I spawn a new gen_fsm server for each transaction, or should I use some kind of static pool of available servers? Going back to the multiple FSMs idea from David C: lets say I have a system where I have thousands of live transactions and each one only lives for a few seconds. The nature of each transaction is an FSM, so using gen_fsm makes sense. Like the ATMs, each transaction has its own state so I’d need thousands of little servers. Does it make sense that I spawn a new gen_fsm server for each transaction, or should I use some kind of static pool of available servers?

]]>
By: Alain O'Dea http://spawnlink.com/articles/an-introduction-to-gen_fsm-erlybanks-atm/#comment-76 Alain O'Dea Mon, 15 Sep 2008 01:22:15 +0000 http://spawnlink.com/?p=52#comment-76 I have not had a chance to comment up until now, but now that I do... This is a brilliant series. It is really helping me dig in on OTP. I think I have had a pretty solid grasp of Erlang the language for, but my grasp of Erlang/OTP as a platform was much less solid. Through articles provide a really good launch point for getting "over the hump" between knowing Erlang and knowing Erlang/OTP. Thanks :) I have not had a chance to comment up until now, but now that I do…

This is a brilliant series. It is really helping me dig in on OTP. I think I have had a pretty solid grasp of Erlang the language for, but my grasp of Erlang/OTP as a platform was much less solid. Through articles provide a really good launch point for getting “over the hump” between knowing Erlang and knowing Erlang/OTP. Thanks :)

]]>
By: David Cabana http://spawnlink.com/articles/an-introduction-to-gen_fsm-erlybanks-atm/#comment-75 David Cabana Sun, 14 Sep 2008 21:03:53 +0000 http://spawnlink.com/?p=52#comment-75 Thank, Mitchell, I will keep asking questions! I am not a total beginner at Erlang, but I have never gotten to use it professionally, only some late night dabbling when the kids are asleep. I want to get my head around OTP, and have found there is a severe lack of approachable, simple examples out there, especially of parts other than gen_server. Your gen_fsm example was most appreciated. I look forward to the rest of your series. I had in mind one bank, one ATM server, and many ATM terminals. Your suggestion of one ATM per ATM terminal makes perfect sense. Thank, Mitchell, I will keep asking questions! I am not a total beginner at Erlang, but I have never gotten to use it professionally, only some late night dabbling when the kids are asleep. I want to get my head around OTP, and have found there is a severe lack of approachable, simple examples out there, especially of parts other than gen_server. Your gen_fsm example was most appreciated. I look forward to the rest of your series.

I had in mind one bank, one ATM server, and many ATM terminals. Your suggestion of one ATM per ATM terminal makes perfect sense.

]]>
By: Mitchell http://spawnlink.com/articles/an-introduction-to-gen_fsm-erlybanks-atm/#comment-74 Mitchell Sun, 14 Sep 2008 19:38:04 +0000 http://spawnlink.com/?p=52#comment-74 Hi David, Great questions! Really great! I'll answer them one at a time... So to answer your first question: I don't quite remember (and it's far too early for my lazy self to look ;) ) if I mentioned it in this article or the last, but I did mention this security issue. There are a number of ways to solve it. Your idea about not registering the server is one option, but then assuming the malicious user has access to the system, there are always easy ways to look up the PID of a running process. :( The solution I would use would be to return a session hash after calling eb_server:authorize. The server would maintain a hashmap to map a hash to a given account. In subsequent withdrawal/deposit methods, eb_server would require the hash be sent in instead of the account name. Additionally, hashes should expire after a set amount of time. This is pretty basic security, not at all meant for a true to life bank application. I don't want anyone to think that I've ever actually meant for this to be a very secure application, as its just meant to show off the features of OTP. :) To answer your second question: I'm only thinking of one ATM terminal in this example, but I do fail to mention that. If there are multiple ATM terminals then the gen_fsm would have to exist in multiple running processes: one for each terminal. I would do this by creating an "ATM server" for lack of better words. When each ATM terminal boots up, it'd register itself with the server, and the server would spawn off a process of eb_atm (not registered), and return the PID to the calling ATM terminal. Then, the terminal can send all requests to this PID. Using this method, it is very easy to add and remove multiple ATM terminals without changes to the code. Hopefully my answers were straightforward enough... the two issues you brought up are very insightful but also not truly meant for the beginner-scope of this series. But I enjoy discussing them, so feel free to ask any more :) Mitchell Hi David,

Great questions! Really great! I’ll answer them one at a time… So to answer your first question: I don’t quite remember (and it’s far too early for my lazy self to look ;) ) if I mentioned it in this article or the last, but I did mention this security issue. There are a number of ways to solve it. Your idea about not registering the server is one option, but then assuming the malicious user has access to the system, there are always easy ways to look up the PID of a running process. :( The solution I would use would be to return a session hash after calling eb_server:authorize. The server would maintain a hashmap to map a hash to a given account. In subsequent withdrawal/deposit methods, eb_server would require the hash be sent in instead of the account name. Additionally, hashes should expire after a set amount of time. This is pretty basic security, not at all meant for a true to life bank application. I don’t want anyone to think that I’ve ever actually meant for this to be a very secure application, as its just meant to show off the features of OTP. :)

To answer your second question: I’m only thinking of one ATM terminal in this example, but I do fail to mention that. If there are multiple ATM terminals then the gen_fsm would have to exist in multiple running processes: one for each terminal. I would do this by creating an “ATM server” for lack of better words. When each ATM terminal boots up, it’d register itself with the server, and the server would spawn off a process of eb_atm (not registered), and return the PID to the calling ATM terminal. Then, the terminal can send all requests to this PID. Using this method, it is very easy to add and remove multiple ATM terminals without changes to the code.

Hopefully my answers were straightforward enough… the two issues you brought up are very insightful but also not truly meant for the beginner-scope of this series. But I enjoy discussing them, so feel free to ask any more :)

Mitchell

]]>
By: David Cabana http://spawnlink.com/articles/an-introduction-to-gen_fsm-erlybanks-atm/#comment-73 David Cabana Sun, 14 Sep 2008 17:04:48 +0000 http://spawnlink.com/?p=52#comment-73 Mitchell, I hope you won't mind another question. I'm trying to understand the concurrency aspects of your example, and also trying to understand the role of the State parameter. As you pointed out, there is an unfortunate overloading of the concept of state in gen_fsm. A finite state automaton has a set of transition states (T-states). In your example these are the states {unauthorized, authorized, thank_you}. In gen_fsm there is another concept of state, a piece of data which I'll call a D-state. The starting state of eb_atm is the pair of {T-state, D-state} == {unauthorized, nobody}. Suppose a user called "Joe" authenticates. The machine state goes from {unauthorized, nobody} to {authorized, "Joe"}. Joe is standing at the ATM trying to make up his mind about how much money to withdraw, maybe calling his wife to ask her. What is happening to incoming authentication messages from other users? It looks to me like every clause which handles messages while eb_atm is in the "authorized" T-state requires the message to provide a D-state parameter matching "Joe". Presumably that match does not occur, or authentication is broken. Does this mean the messages are piling up in the process mailbox? If so, isn't the whole authentication mechanism in effect blocking while Joe goes about his business? Thanks, David Mitchell,

I hope you won’t mind another question. I’m trying to understand the concurrency aspects of your example, and also trying to understand the role of the State parameter.

As you pointed out, there is an unfortunate overloading of the concept of state in gen_fsm. A finite state automaton has a set of transition states (T-states). In your example these are the states {unauthorized, authorized, thank_you}. In gen_fsm there is another concept of state, a piece of data which I’ll call a D-state. The starting state of eb_atm is the pair of {T-state, D-state} == {unauthorized, nobody}.

Suppose a user called “Joe” authenticates. The machine state goes from {unauthorized, nobody} to {authorized, “Joe”}. Joe is standing at the ATM trying to make up his mind about how much money to withdraw, maybe calling his wife to ask her. What is happening to incoming authentication messages from other users?

It looks to me like every clause which handles messages while eb_atm is in the “authorized” T-state requires the message to provide a D-state parameter matching “Joe”. Presumably that match does not occur, or authentication is broken. Does this mean the messages are piling up in the process mailbox? If so, isn’t the whole authentication mechanism in effect blocking while Joe goes about his business?

Thanks,
David

]]>
By: David Cabana http://spawnlink.com/articles/an-introduction-to-gen_fsm-erlybanks-atm/#comment-72 David Cabana Sun, 14 Sep 2008 16:08:19 +0000 http://spawnlink.com/?p=52#comment-72 Mitchell, My compliments on an outstanding series of posts. Let me ask a question concerning the relationship between this post's authorization mechanism and the previous post's bank account mechanism. I'm trying to understand the big picture here. Imagine a potential bad guy is trying to make an unauthorized withdrawal. The security mechanism as illustrated works if the bad guy uses eb_atm:authorize/2 and eb_atm:authorize/1 API. On the other hand, the bad guy could just call eb_server:withdraw/2 and make off with the goods. I understand the system as written is a prototype for didactic purposes. What I am wondering is how one would go about locking it down (I have not read ahead in the series, maybe you address this later). My guess is that one would not register the name of eb_server, and instead allow access to it only by its PID, and then take care that only eb_atm and other authorized processes had access to that PID. Is this the correct approach? David Mitchell,

My compliments on an outstanding series of posts. Let me ask a question concerning the relationship between this post’s authorization mechanism and the previous post’s bank account mechanism. I’m trying to understand the big picture here.

Imagine a potential bad guy is trying to make an unauthorized withdrawal. The security mechanism as illustrated works if the bad guy uses eb_atm:authorize/2 and eb_atm:authorize/1 API. On the other hand, the bad guy could just call eb_server:withdraw/2 and make off with the goods.

I understand the system as written is a prototype for didactic purposes. What I am wondering is how one would go about locking it down (I have not read ahead in the series, maybe you address this later). My guess is that one would not register the name of eb_server, and instead allow access to it only by its PID, and then take care that only eb_atm and other authorized processes had access to that PID. Is this the correct approach?

David

]]>