Our event communication uses a protocol called pusher.  The idea behind pusher is that:


  • parts that are interested in specific events register to be notified when they occur (listeners)
  • parts that cause the events, signal the events when they occur (signallers)
  • the Soketi Server forwards the events from the signalling part to the listening part


Currently in our usage, the events are signaled by the Resource Area.  The Mobile Client and the Web Scoring Program listen for the events.


As is illustrated in the diagram below, each Mobile Client and instance of the Web Scoring Program register with the Soketi server that they want to be notified of events on specific channels.


  • the Mobile Client's Channels are named di-test-room-<room_id> where <room_id> is the internal room_id of a room it is scoring
  • the Web Scoring Channels are named di-test-tourn-<tourn_id> where <tourn_id> is the internal tourn_id for the tournament being scored


The channels are used to direct the correct events to the correct applications.  If we have 5 appraisers scoring teams in a room at a tournament, their Mobile Clients will be listen for events for that room.  Appraisers in a different room will be listening on a different channel.


Similarly, 3 instances of the Web Scoring Program scoring a specific tournament will be listening for scoring event for that tournament.  Web Scoring Programs for another tournament will be listening on a different channel.


The Soketi Server maintains lists of all the channels where applications are listening.  When an event is triggered the Resource Area it is then channels by Soketi to the correct applications.