Master/Slave vs Client/Server

I just wanted to clarify if the terms master/slave and client/server are implemented based upon conventions or distinct features.

Mostly, I have noticed Ethernet based protocols use client/server (e.g. Modbus TCP) whereas serial based protocols use master/slave (e.g. Modbus RTU). By that logic, is it possible to indiscriminately call all devices based on their physical layer, regardless of their application layer protocol?

Another interesting distinction I've stumbled across is the exclusive capability of servers sending unsolicited messages. Based on my experience, I do attest that is true but by that logic Modbus TCP should still use master/slave naming convention.

Anyway, I was hoping someone could provide clarity to my clouded judgement.

(Hoping this is not off topic )

I don't think it's solely around the physical layer. For example, I think EtherCat uses Master/Slave terminology, even though it is based on Ethernet. I think it is partially coincidence that new terminology started being used at the same time as Ethernet was starting to be adopted. Mostly I think it references different communication schemes.

Generally, Master/Slave means that the master is in charge of the bus, and is the only one to initiate communication. No one can talk without the master's permission. This is helpful on token ring networks, which is typical of Serial communication. Generally the PLC would be the master, and the IO would be the slave.

Client/Server and Producer/Consumer are two new communication models that are often used in Ethernet based systems. In a client/server setup, the server has data, and the client can access/change it. The server is usually sitting there waiting for a client to connect and make requests, and the server can also often accept multiple clients simultaneously. The PLC would typically be the client, and the IO would be the server.

Producer/Consumer is slightly different from client/server in that once the consumer subscribes to the producer, it continuously sends the data until it decides to stop. Here, both the PLC and IO are both producers and consumers. The IO produces the input data, and the PLC consumes it. The PLC produces the output data, and the IO consumes it.

Unless you're getting deep into the details, the communications scheme is mostly just semantics. The IO still changes hands, regardless.

Based on your response I think its more related to additional features such as server-server communication, unsolicited messaging, multiple clients, etc. that defines a server. However, these features vary based on protocol and hence my confusion, as I thought all of them were inherent features of any server.

Anyway, thanks for your input mk42.

Salman S. said:

Based on your response I think its more related to additional features such as server-server communication, unsolicited messaging, multiple clients, etc. that defines a server. However, these features vary based on protocol and hence my confusion, as I thought all of them were inherent features of any server.

Anyway, thanks for your input mk42.

Click to expand...

It's mostly related to those features, but I've also seen master slave systems with at least some of those features. Profibus can have slave-slave communication, for example, and the diagnostic messages are unsolicited, even if the device still has to wait for it's turn to talk on the bus.

It's often easy to create an "ideal" system definition for a communication type, Once you see real world systems, they all end up being pretty close to one another, at least in a practical sense.

mk42 said:

Producer/Consumer is slightly different from client/server in that once the consumer subscribes to the producer, it continuously sends the data until it decides to stop. Here, both the PLC and IO are both producers and consumers. The IO produces the input data, and the PLC consumes it. The PLC produces the output data, and the IO consumes it.

Click to expand...

Please treat me as Producer/Consumer illiterate here. I am.
--Trying to learn. Could you define the highlighted it above?

Am I to read this it as
"the producer continuously sends the data until the Consumer decides to stop" -- as in unsubscribes
or
"the producer continuously sends the data until the Producer decides to stop"
I would hope that a Producer cannot decide to stop producing for a Subscribed Consumer without a powerful overriding reason.

Thank you.

kwade said:

Please treat me as Producer/Consumer illiterate here. I am.
--Trying to learn. Could you define the highlighted it above?

Am I to read this it as
"the producer continuously sends the data until the Consumer decides to stop" -- as in unsubscribes
or
"the producer continuously sends the data until the Producer decides to stop"
I would hope that a Producer cannot decide to stop producing for a Subscribed Consumer without a powerful overriding reason.

Thank you.

Click to expand...

Sorry for the confusion. I probably meant that the consumer decides to unsubscribe; as you suggest, that's the one that makes sense in the context of IO.

Hypothetically, though, it could be the producer stopping of it's own accord. It could be something as simple as a power outage, but there might be situations where the producer could intelligently decide to end communication on its own, perhaps a module connected to a UPS that wants to cleanly end comms instead of just failing. I don't know if this is actually implemented in protocols using this model though.

mk42 said:

Sorry for the confusion.

Click to expand...

NP. thanks for the follow-up.

Salman S. said:

I just wanted to clarify if the terms master/slave and client/server are implemented based upon conventions or distinct features.

Click to expand...

Good luck in finding clarity in the use of the term "master/slave". The master/slave terminology was already implemented in a variety of fields prior to the existence of serial communications or networks.

I don't see master/slave versus client/server as representing a simple dichotomy. A network need not be one or the other. Nor do I view the terms as being interchangeable. When I hear "master/slave" used to describe a network, I think of proprietary networks in which a bus controller acts as the "master", and no messages are transferred between nodes unless and until the master node instigates the message transfer. Of course, this description is clouded by the fact that some master/slave network models will allow slave nodes to sometimes also take the role of master and transmit an unsolicited message.

I see the opposite of master/slave as peer to peer, when it comes to networking, and Ethernet is basically a peer to peer network, since all network nodes are allowed to transmit messages at any time without permission from a master node. To me, the term "client/server" refers more to database storage and information sharing than to internodal message transfers. Any given network node may function as a server of information, a client requesting information, or as both a client and a server simultaneously.

Of course, I'll admit that I'm no expert when it comes to networking. I began my career implementing electromechanical automation prior to microprocessor based controllers, serial communications and networking becoming a significant aspect of the automation landscape. And so, I've learned whatever I've needed to know with regard to networks as has been required in order to implement industrial automation solutions within an ever evolving environment. The only thing that I can say with confidence regarding networking is that what I don't know > what I do know.

The only thing that I can say with confidence regarding networking is that what I don't know > what I do know.

Click to expand...

AMEN!

The differences (using Modbus, anyway) between RTU (serial) and TCP (Ethernet) are significant. The thing that bugs me more than the little annoyances, like address offset, is that many devices are slave / server only.

Being able to have several Modbus Masters (Clients) on a network is one of the big advantages of Modbus/TCP (Ethernet). I'm sure there is a good reason it doesn't work on Modbus/RTU (Serial), but it's frustrating. I'm sure it has something to do with Ethernet's inherent traffic control.

Gene Bond said:

Being able to have several Modbus Masters (Clients) on a network is one of the big advantages of Modbus/TCP (Ethernet). I'm sure there is a good reason it doesn't work on Modbus/RTU (Serial), but it's frustrating. I'm sure it has something to do with Ethernet's inherent traffic control.

Click to expand...

You're pretty much right, when you mention Ethernet's traffic control. Complicated details follow:

A big part of that is what is known as the "Collision Domain" of the traffic.

RS485 (for Modbus) is what is known as a "shared medium", which basically means that it only works right if only one device is sending at a time. The collision domain is the entire network; every device sees the exact same electrical signals. Its like walkie talkies (with only one channel). The devices are also Half Duplex, which means that can't send and recieve simultaneously. A device needs to listen to be sure that no one else is talking before it starts. Most serial protocols use the master/slave setup to simplify this: the master controls all communication, and the slaves don't speak unless spoken to. This makes it easy to avoid trouble.

Ethernet (at least the modern 10/100/1000 full duplex) is a switched medium, which means there is essentially no collision domain. The Ethernet cables go from the device to the switch, and the electrical signals are processed instead of propagated out to the rest of the network. The switch has a buffer to store all the communication to/from each cable. In addition, because it is Full Duplex, the devices can send and receive at the same time. Switched Medium + Full Duplex = everyone can talk at the same time, and still receive messages.

However, if you use Ethernet HUBS instead of switches, then the Ethernet network becomes a shared medium and it suddenly has the same communication hassles as RS485: only one person can talk at a time.