You just downloaded a new device manual and it says “Modbus client” and “Modbus server.” Your RS-485 documentation says “master” and “slave.” Your PLC code has variables named slaveId. Which is right? Do you need to change your code? Are these different protocols?
Short answer: no. The protocol is identical. The terminology depends mostly on the transport you are using. Modbus over serial (RTU / ASCII) has traditionally used master/slave. Modbus over Ethernet (TCP) uses client/server. Every function code, register address, and packet format works exactly the same either way. What you learned about serial Modbus is still true for Modbus TCP. You just need to know the translation.
This article gives you that translation, explains why the two vocabularies exist, and shows you what to expect when you encounter mixed terminology in real-world documentation.
Table of Contents
The translation table
If you remember only one thing from this article, remember this table:
| Serial (RTU / ASCII) | Ethernet (TCP) | Notes |
|---|---|---|
| Master | Client | The device that initiates requests |
| Slave | Server | The device that responds to requests |
| Slave ID | Unit ID (sometimes Server ID) | The 1-byte address of the target device |
| Slave address | Server address | Same as Server ID / Unit ID |
| Master-slave | Client-server | The communication model |
| Master/slave protocol | Client/server protocol | The overall description |
That’s it. The entire vocabulary difference fits in one small table. Anyone who understands the serial terms understands the Ethernet terms — they map 1:1.
What actually changes between the two
Nothing about the protocol. The current Modbus Application Protocol Specification (Version 1.1b3) and newer Modbus Organization documentation increasingly use client/server terminology while defining the same protocol behavior:
- Same function codes (0x01, 0x03, 0x06, 0x10, etc.)
- Same register model (coils, discrete inputs, holding registers, input registers)
- Same frame formats (RTU, ASCII, TCP)
- Same MBAP header structure for Modbus TCP
- Same CRC for RTU
- Same behavior on errors and exceptions
The difference is entirely in the terminology used to describe the communication roles. That is all.
No firmware updates, configuration changes, or protocol migrations are required to move between the two vocabularies. Devices using master/slave documentation and devices using client/server documentation remain fully interoperable because the communication protocol is unchanged.
What actually stays the same
Just to be clear about what does NOT change between the two vocabularies:
- The wire protocol on both serial and Ethernet
- All function codes and their behavior
- Register addressing and mapping
- Exception codes and error handling
- Serial line configuration (baud rate, parity, stop bits)
- Modbus TCP port numbers (502 for standard, 802 for Modbus TCP Security)
- All existing devices and existing code
- All existing SCADA integrations
Your PLC program does not need updating. Your HMI configuration does not need updating. Your engineering documentation does not need rewriting.
Why the two vocabularies exist
The vocabulary difference comes from the transport, not the Modbus protocol itself.
Serial Modbus grew up with master/slave
Modbus was created by Modicon in 1979 for serial buses. On RS-485, one device polls many. That polling device controls the timing and the conversation — the other devices only speak when spoken to. Master/slave was the natural language for this arrangement, and it was standard terminology for industrial serial protocols of that era.
For decades, Modbus RTU and Modbus ASCII documentation used master/slave exclusively. Most existing serial Modbus devices, manuals, and training materials use these terms.
Ethernet Modbus grew up with client/server
Modbus TCP was standardized in 1999. It operates over TCP/IP, where one endpoint establishes connections and the other accepts them. This is fundamentally a client-server model — TCP itself uses that terminology at the transport layer.
Modbus TCP naturally fits the client/server communication model. Even when the Modbus Organization’s specification still used master/slave, engineers working on Modbus TCP tended to say “client” and “server” naturally because that is how TCP works.
The 2020 documentation update
In 2020, the Modbus Organization officially updated its terminology from master/slave to client/server across all documentation, including serial line documentation. The update reflects two forces: alignment with the client/server terminology already common in Ethernet contexts, and the tech industry’s broader move away from master/slave language in favor of more neutral vocabulary (Git, MySQL, Redis, PostgreSQL made similar changes around the same period).
The specification change did not modify the protocol. It aligned serial Modbus documentation with the client/server terminology already common in Modbus TCP environments.
| Year | Event |
|---|---|
| 1979 | Modbus introduced by Modicon (master/slave) |
| 1999 | Modbus TCP standardized (client/server terminology fits naturally) |
| 2020 | Modbus Organization terminology officially updated to client/server across all docs |
Where you will actually see each vocabulary
Field reality diverges from official documentation:
Ethernet contexts (Modbus TCP) — client/server dominates:
- Modbus TCP device manuals
- Modbus TCP client libraries (pymodbus, libmodbus, etc.)
- Wireshark dissector labels
- Cloud IoT platform Modbus integrations
- SCADA driver documentation for Modbus TCP
- The current Modbus specification
Serial contexts (RTU/ASCII) — master/slave still dominates in practice:
- Legacy device manuals (anything pre-2020)
- Many RS-485 device datasheets even today
- Existing PLC function block libraries (Siemens
Modbus_Master, Rockwell MSG blocks, CODESYSMODBUS_MASTER) - Field engineers with 20+ years of experience
- SCADA HMI screens designed years ago
- Configuration tools for legacy hardware
Mixed contexts — both appear:
- Modbus TCP-to-RTU gateway manuals (they bridge both worlds)
- Newer training materials that cover both transports
- Community forums (users mix freely)
- Company internal documentation being modernized gradually
Neither vocabulary is wrong. Both refer to the same protocol roles. The gap between “serial habits” and “Ethernet conventions” will persist for years — probably decades in some industrial environments.
Reading mixed-terminology documentation
You will regularly encounter documentation that uses both vocabularies. Some patterns to expect:
A modern Modbus TCP-to-RTU gateway manual. The Ethernet side of the gateway is documented as “Modbus TCP server” and the serial side as “Modbus RTU master.” Both terms describe the same physical device — its role is just different on each interface.
A newer device manual with legacy examples. The overall documentation may use client/server, but example code snippets or reference tables kept from earlier editions still use master/slave. Treat both terms as equivalent.
A vendor supporting multiple product generations. A vendor’s website may describe new Modbus TCP products with client/server terminology and older RTU products with master/slave. Same protocol family, different vocabulary per generation.
Tools with mismatched UIs. Configuration software may use master/slave in the UI (following legacy convention) but generate code with client/server variable names. This is a UI update lag, not a protocol issue.
Community forums. Forum discussions typically mix terminology freely. Do not assume anything about a poster’s background based on which term they use.
The key skill: mentally translate between the two vocabularies. Master = client. Slave = server. Everything else is identical.
Modbus TCP gateway terminology
Modbus TCP-to-RTU gateways create interesting terminology situations. A single gateway acts as both:
- Modbus TCP server — accepts TCP connections from clients on the Ethernet side
- Modbus RTU master — polls slaves on the RS-485 serial side
In fully modern terminology, the serial side would be called the Modbus serial client. But many gateway manuals still label this role as the RTU master because that vocabulary is standard in serial-Modbus context. Gateway documentation often mixes these terms because the gateway’s role differs on each side.
Read gateway manuals with this in mind: the same device can be a “server” on one interface and a “client” (or master) on the other.
For deeper coverage of gateway behavior, see our Modbus RTU vs Modbus TCP article.
The Unit ID field
Modbus TCP uses one additional term worth clarifying: Unit Identifier (or Unit ID).
The Unit ID is a 1-byte field in the MBAP header that identifies the target device. In serial Modbus, this same field was called the Slave ID or Slave address. In modern client-server terminology, you may also see it called the Server ID or Server address.
All these names refer to the same field with the same values (0 for broadcast, 1-247 for individual devices, 248-255 reserved):
- Unit ID (standard Modbus TCP terminology)
- Slave ID / Slave address (serial Modbus terminology)
- Server ID / Server address (client-server terminology)
For details on this field, see our Modbus TCP MBAP Header article.
Writing new documentation
If you are producing new Modbus documentation today, use client/server for these reasons:
Consistency with the current specification. The official Modbus Application Protocol Specification uses client/server. Your documentation should match unless you have a specific reason not to.
Alignment with other protocol documentation. If you also document OPC UA, MQTT, or EtherNet/IP integrations, they all use client/server. Consistency across your documentation portfolio helps readers.
Future-proofing. Documentation lifetime often exceeds device lifetime. Client/server terminology will remain current for decades. Master/slave will feel increasingly dated.
Inclusive language expectations. Many organizations now have style guides requiring client/server terminology. Aligning proactively avoids later rewrites.
If your audience is deeply used to master/slave — long-tenured industrial engineers, for example — you can introduce both terms in the first paragraph and then use client/server consistently. This bridges the vocabulary gap without confusing readers.
Impact on existing code
There is no technical reason to rename existing variables such as slaveId or masterPoll. Existing code continues to work correctly because the protocol behavior is unchanged. If new code is being written, using client and server terminology helps keep the code aligned with current documentation.
Some situations where code renaming might be worth it:
- Public API changes. If you publish a library with
masterIdandslaveResponsein the public API, consider whether the API should use current terminology. - Documentation-driven code. If your codebase’s documentation uses one vocabulary and the code uses another, aligning them helps readability.
- New code in an old codebase. New modules can use new terminology even if the existing codebase uses old terminology. Comment the mixing clearly.
Widespread renaming across production code carries real risk (bugs, merge conflicts, regression testing) that usually outweighs the terminology benefit. Update naturally as code evolves, not all at once.
The broader industry context
Modbus is not the only protocol where terminology diverged along transport lines or shifted over time. The industry-wide picture:
| System | Old terminology | Current terminology |
|---|---|---|
| Git | master (branch) | main (branch) |
| MySQL | master/slave | primary/replica or source/replica |
| Redis | master/slave | primary/replica |
| PostgreSQL | master/slave | primary/standby |
| Modbus (serial) | master/slave | master/slave (traditional), client/server (modern docs) |
| Modbus (Ethernet) | client/server (from the start) | client/server |
| MQTT | (always used broker/client) | (unchanged) |
| OPC UA | (always used client/server) | (unchanged) |
Protocols designed after the mid-2000s generally started with client/server or similar neutral terminology. Older protocols updated their vocabulary in the 2020s to match modern conventions.
What does not fit the client/server model well
Some Modbus scenarios do not fit cleanly into client/server language:
Peer-to-peer serial buses. On an RS-485 bus with multiple devices, one device is the client (poller) and others are servers (responders). But some systems have devices that switch roles — sometimes polling, sometimes being polled. Client/server language handles this awkwardly; you have to describe each direction of communication separately.
Push notifications. Modbus is a polling protocol — the client always initiates. There is no native concept of a server pushing data to the client. Some vendor extensions add push behavior, but they usually work by having the “server” act as a client for the push messages, which is confusing regardless of vocabulary.
Broadcast writes. When a client sends a broadcast to Modbus address 0, all servers on the bus process it silently. This is technically still client-server (the client initiates), but the “server” role is unusual because no server actually replies. For details, see our Modbus Broadcast Function Codes article.
These edge cases exist regardless of which vocabulary you use to describe them.
Summary
If you encounter both “master/slave” and “client/server” in Modbus documentation, remember that they describe the same communication roles. Serial Modbus (RTU / ASCII) traditionally uses master/slave. Ethernet Modbus (TCP) uses client/server. The protocol, frame formats, function codes, and device behavior are unchanged. The vocabulary difference reflects transport conventions and modern documentation practices — not any change to how Modbus actually works on the wire.
Common questions
What is the difference between Modbus master-slave and client-server?
There is no functional difference — same protocol, same behavior, different vocabulary. Serial Modbus (RTU / ASCII) traditionally uses master/slave terminology. Ethernet Modbus (TCP) uses client/server terminology. The Modbus master is the same role as the Modbus client (initiates requests). The Modbus slave is the same role as the Modbus server (responds to requests). Modern Modbus Organization documentation uses client/server across all transports, but master/slave remains common in serial contexts.
Is Modbus TCP client-server or master-slave?
Modbus TCP uses client/server terminology. This fits naturally because Modbus TCP operates over TCP/IP, where one endpoint establishes connections (the client) and the other accepts them (the server). Modbus TCP device manuals, client libraries, and configuration tools consistently use client/server. If you encounter master/slave in a Modbus TCP context, it usually means the documentation is older or was translated from serial-Modbus material.
Is Modbus RTU master-slave or client-server?
Modbus RTU has traditionally used master/slave terminology because it operates on RS-485 serial buses where one device polls many. The 2020 Modbus Organization documentation update officially calls the same roles client and server, but master/slave remains standard in most existing RTU device manuals, PLC libraries, and field engineering practice.
What is a Modbus client?
A Modbus client is the device that initiates communication. It sends requests and receives responses. In Modbus TCP, the client opens the TCP connection. In serial Modbus documentation using modern terminology, the client is the same role as the traditional master. Both terms describe the polling device that controls the conversation.
What is a Modbus server?
A Modbus server is the device that responds to requests. In Modbus TCP, the server accepts TCP connections. In serial Modbus documentation using modern terminology, the server is the same role as the traditional slave. It listens for requests addressed to it and sends responses (or processes broadcast requests silently).
What is the difference between Modbus master and client?
There is no functional difference. Master is the traditional terminology used mostly in serial Modbus (RTU / ASCII) contexts. Client is the modern terminology used in Modbus TCP contexts and in the current Modbus specification. Both refer to the device that initiates requests. The protocol behavior, function codes, and packet formats are identical regardless of which term you use.
What is the difference between Modbus slave and server?
Same relationship as master vs client. Slave is the traditional serial Modbus terminology. Server is the modern terminology used in Modbus TCP and current specification documents. Both refer to the device that responds to requests. Identical protocol behavior.
When did Modbus change from master-slave to client-server?
The Modbus Organization officially updated its terminology in 2020. This coincided with an industry-wide shift toward neutral technical vocabulary across many protocols and systems (Git, MySQL, Redis, and others). The current Modbus Application Protocol Specification (Version 1.1b3) uses client/server terminology throughout. However, in practice, serial Modbus documentation and field practice still commonly use master/slave.
Do I need to update my Modbus code because of the terminology?
No. Existing Modbus code continues to work exactly as before. Variable names like slaveId or masterPoll still function correctly. The terminology difference is purely cosmetic — the protocol wire format, function codes, and behavior are unchanged. You can rename code variables for consistency with modern terminology if you wish, but this is a preference, not a requirement.
Does Modbus TCP use Unit ID or Slave ID?
Both terms refer to the same field. Unit ID is the standard Modbus TCP terminology for the 1-byte device identifier in the MBAP header. Slave ID or Slave address is the traditional serial Modbus terminology. Server ID or Server address is the modern client-server terminology. All these names refer to the same field with values 0 (broadcast), 1-247 (individual devices), and 248-255 (reserved).
Should I use master-slave or client-server in new documentation?
Use client-server in new documentation. This aligns with the current Modbus specification, matches modern network protocol conventions, and future-proofs your documentation. If your audience is used to master-slave (typical for RTU-heavy field environments), you can introduce both terms early in your documentation and then use client-server consistently.
Are Modbus master and Modbus client different protocols?
No. They are the same protocol role with different names. A Modbus master device and a Modbus client device do exactly the same thing: initiate requests and receive responses. The only difference is the term used to describe them. All the underlying protocol behavior — function codes, register formats, timing, error handling — is identical.
Why do serial and Ethernet Modbus use different terminology?
Because they grew up in different eras. Serial Modbus was designed in 1979 when master/slave was the standard terminology for industrial buses. Modbus TCP was designed in 1999 to work with TCP/IP, which naturally uses client/server language at the transport layer. The two vocabularies coexisted for two decades. In 2020 the Modbus Organization unified its documentation around client/server, but field practice still varies by transport.
Will old device manuals still work with new Modbus documentation?
Yes. The protocol has not changed, so old device manuals (using master/slave) describe the same protocol behavior as current documentation (using client/server). You may need to mentally translate between the two vocabularies as you read, but the technical content is fully compatible. The Modbus terminology update was a documentation change, not a protocol change.
Can I use master-slave and client-server interchangeably?
Yes. They are interchangeable in every technical sense. Master and client are identical roles. Slave and server are identical roles. The only reason to prefer one vocabulary over the other is audience expectation and consistency with surrounding documentation — not any protocol-level difference.