Hi,
I wanted to know what are different ways to send info from state machine to outside world. I am planning to use MSM in my project to represent connection between local computer and remote computer. This connection will be used as a channel to send data over to remote device. There can be >1 channels existing between local computer and the remote device. There will be a controller sitting at local computer monitoring all these channels. The data will be sent over connection that is idle/free at that point of time. Whenever the connection, i.e. FSM, is done sending the data, it will let the controller (which resides outside of the FSM) know that it is done sending the data and the controller will then send next lot of data over that connection. There can be 2 ways of achieving this: 1. Controller polling all the connections and knowing what "state" the FSM is in.(In this case, the outer world will need to know the current state of the state machine) 2. The FSM will proactively let the controller know that it is done with sending data. (In this case the FSM will have to send data to outside world). I would like to know about ways to implement both the cases (i.e knowing status/current state of the FSM and sending info from FSM). I would also like to know what are different ways to interact with (both to and from) FSM in general, apart from sending events.
Thanks!
Hi, I personally use mostly 2. but 1. is useful if you need to do something at some regular interval. To 1: - current_state / get_state_by_id will get you a base class of all states if you define one. - better is to use flags (http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/ch03s02.html#d0e1032) to know if your fsm fulfills some property (is in one or more states which define these flags). It's a bit like knowing in which state you are but more general. This one is my favorite. - you can use a visitor (http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/ch03s05.html#d0e2333) to let the current state "do" something. To 2: This shouts for a transition action (http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/ch03s03.html#d0e1260). An action is a functor or a function which is called when a transition fires. There is no rule written in marble, but I suggest you stick to 2. until you cannot do otherwise, it will make your fsm much more useful and readable. Plus, it mixes very well with boost.asio (I do it quite a bit myself). Every callback from asio generates some event, to which the fsm reacts by changing state and calling another action, which triggers another asio task, etc. For example, a HTTP client (http://www.boost.org/doc/libs/1_47_0/doc/html/boost_asio/example/http/client...): - fsm starts - when asked, fsm calls async_resolve - handle_resolve generates an event which triggers a transition - the transition action calls async_connect - handle_connect generates an event which triggers a transition - the transition action sends data by calling async_write etc. etc. Add some events and actions for error handling and you get a pretty complete communication handling in a fsm. To your last question, interact with a fsm, well, it's a class so you can add whatever methods or attributes you might need. HTH, Christophe