//States we can be in at any point in timetypedefenum {STATE_PRIMARY =1,//Primary, waiting for peer to connectSTATE_BACKUP =2,//Backup, waiting for peer to connectSTATE_ACTIVE =3,//Active - accepting connectionsSTATE_PASSIVE =4//Passive - not accepting connections
} state_t;

struct _bstar_t {zctx_t *ctx;//Our private contextzloop_t *loop;//Reactor loopvoid*statepub;//State publishervoid*statesub;//State subscriberstate_t state;//Current stateevent_t event;//Current eventint64_t peer_expiry;//When peer is considered 'dead'zloop_fn *voter_fn;//Voting socket handlervoid*voter_arg;//Arguments for voting handlerzloop_fn *master_fn;//Call when become mastervoid*master_arg;//Arguments for handlerzloop_fn *slave_fn;//Call when become slavevoid*slave_arg;//Arguments for handler
};//The finite-state machine is the same as in the proof-of-concept server.//To understand this reactor in detail, first read the CZMQ zloop class.

//We send state information every this often//If peer doesn't respond in two heartbeats, it is 'dead'
#define BSTAR_HEARTBEAT1000//In msecs

//---------------------------------------------------------------------//Binary Star finite state machine (applies event to state)//Returns -1 if there was an exception, 0 if event was valid.

//The zloop method returns the underlying zloop reactor, so we can add//additional timers and readers:

zloop_t *bstar_zloop (bstar_t *self)
{return self->loop;
}

//The voter method registers a client voter socket. Messages received//on this socket provide the CLIENT_REQUEST events for the Binary Star//FSM and are passed to the provided application handler. We require//exactly one voter per bstar instance: