Bei einem Master-Slave Bus werden die am Bus angeschlossenen Module zyklisch abgefragt (Polling). Dies passiert in der Regel durch die Digitalzentrale oder einer Steuerungssoftware. Die Antwortzeit steigt mit der Anzahl der Module, weil diese alle einzeln abgefragt werden. Das passiert unabhängig davon, ob sich ein Zustand an einem Modul geändert hat.

Bei einem Peer-to-Peer Bus können sich die Teilnehmer untereinander "unterhalten", es ist kein Polling erforderlich. Ein Peer-to-Peer Bus ist auch ein Multi-Master Bus.

Beim Multi-Master, auch Producer/Consumer Bus genannt, gibt es "Produzenten" und "Verbraucher". Bei diesem Bus werden nur Ereignisse (Events) gemeldet. Es ist kein Polling erforderlich. Ändert sich an einem Modul ein Zustand, z.B. weil ein Schalter betätigt wurde oder ein Besetztmelder seinen Status ändert, wird dies über ein Ereignis auf dem Bus mitgeteilt. Alle Module, für die das Ereignis interessant ist, werden darauf reagieren.

Peer-to-Peer und Producer/Consumer können auch mit Polling abgefragt werden, beim Master-Slave Bus gibt es nur Polling. DCC mit Railcom ist eine Besonderheit, es werden im DCC Signal in einer Austastlücke Daten vom Dekoder zur Zentrale übertragen. Der Bus ist nicht ohne weiteres für Rückmelder, Schalter usw. verwendbar.

Der größte Nachteil bei einem Master-Slave Bus ist, das es immer eine zentrale Steuereinheit geben muss, die den Bus kontrolliert und die Busteilnehmer abfragt, auch wenn diese gar nichts zu sagen haben. Möchte man keine zentrale Steuereinheit, dann ist der Multi-Master Bus ideal. In diesem Falle gibt es bei der Modellbahnsteuerung zwei unterschiedliche Verfahren. Daten werden mit einer Adresse an einen anderen Teilnehmer gesandt (das kennen wir von TCP/IP Netzwerker wie das Internet) oder es werden Ereignisse auf den Bus gegeben, die von anderen Teilnehmern verarbeitet werden (CAN).