They're generally useful when you need to process input and keep track of what to do "next". Here's an example where the author manages comet connections using

They're generally useful when you need to process input and keep track of what to do "next". Here's an example where the author manages comet connections using gen_fsm in Erlang: http://www.letsyouandhimfight.com/2010/01/31/comet-in-erlang-with-mochiweb-and-a-finite-state-machine/ http://www.letsyouandhimfight.com/2010/01/31/comet-in-erlang... The FSM starts in state "waiting" (waiting for a connection/request). When a request arrives, the state is transitioned to "have_request". When/if a packet arrives when there's a request connected (packet -> have_request), the data is sent to the client (that then disconnects; the nature of this comet implementation) and the next state is set to "waiting". When a packet arrives when the current state is "waiting", it's added to a buffer and the next state is set to "have_packet". When a request is made and the state is "have_packet" - as opposed to when it was in "waiting" - the packet is immediately sent to the client, and the next state is set to "waiting". There are many other states and "events" in the code, but I think this illustrates how easy FSMs make it to reason about these kind of implementations (protocols).