How server types handle requests

Server types differ in how they respond to user commands.

Type	Global update commands	Read-only commands	Work-in-progress commands	Note	To learn more, see ...
Standard	Local	Local	Local	A standard server can be a standalone server or the central server that has downstream replica servers.
Commit	Local	Local	Local	A commit server The innermost P4 Server in a multi-server topology that implements the protocols required by Edge Servers. is required as the central server when the topology includes edge servers, but a commit server can also be a standalone server. The commit server stores canonical archives and permanent metadata. It is not required to contain all the workspace, label, or shelf information that is held locally by edge servers. Commit servers can operate with only edge servers connecting to them, and the users only connecting to edge servers. However a commit server can also operate in a hybrid mode, where both users and edge servers connect directly to the commit server. Commit servers also support connections from other replica types, proxies, and brokers.	Commit-edge
Edge	Forward	Local	Local	Edge servers A server that is part of a commit-edge environment that is able to independently support work in progress for locally-bound clients, thereby reducing the load on the commit server. can provide excellent performance in many scenarios. For example, performance might improve when the users are geographically near the edge server but distant from the commit server. By default, edge servers handle their workspaces, labels, and file locks (non `+l` files) locally. Syncing, opening files, running merges, and viewing file history are all handled by the edge server. However, the commit server does become involved when a submit command is issued to an edge server.	Commit-edge
Replica	Reject	Local	Reject	A readonly replica A P4 Server that automatically maintains a full or partial copy of the master server's metadata and that might contain related file content. The replica copies from its master by using 'p4 pull' or 'p4 journalcopy'. A replica can be used as a backup server for disaster recovery. server processes readonly commands from users and contains all metadata that the upstream central server contains (unless it is filtered).	Read-only replica
Standby	Reject	Local	Reject	A standby server supports the same set of functionality as the read-only replica but in addition: Uses p4 journalcopy and `p4 pull -L` for metadata replication. Allows the use of the p4 failover command for failover against mandatory servers.	Standby server
Forwarding Replica	Forward	Local	Forward	A forwarding replica A P4 server that processes reporting (read) commands but forwards update (write) commands to the master server. One or more forwarding replicas can improve performance by reducing the workload of the master server. Can be used as a backup server for disaster recovery. offers a blend of the functionality of the P4 Proxy with the improved performance of a replica. A forwarding replica handles commands that only require a read from the database but forwards commands that require a database write to the upstream server.	Forwarding replica
Forwarding standby	Forward	Local	Forward	A forwarding standby provides the same functionality as a forwarding replica, but in addition: Uses p4 journalcopy and p4 pull -L for metadata replication. Allows the use of the p4 failover command for failover against mandatory servers.	Standby and forwarding-standby
Build	p4 client	Local	p4 sync	A build server offloads the workload of the automated build processes onto a separate machine. In addition to supporting read-only commands, build servers host their own local copies of certain metadata concerning workspaces and the syncing of files. Server functionality has advanced since build servers were implemented and we now recommend using edge servers (available since 2013.2). Edge servers provide additional capabilities which further reduce the load on the central server. This improves performance and adds the flexibility of being able to run write commands as part of the build or development process. To learn more, see Commit-edge.	Build server

Server type corresponds to the Services field in the server specification. To learn more, see Form fields under p4 server in the P4 CLI Reference.

User requests fall into three categories, depending on the command and command options:

Global update	Read-only	Work-in-progress
p4 branch p4 change p4 configure set p4 client p4 counter p4 depot p4 group p4 job p4 label p4 protect p4 renameclient p4 renameuser p4 server p4 stream p4 triggers p4 typemap p4 user	p4 branches p4 changes p4 configure show p4 client -o p4 clients p4 counters p4 depots p4 dirs p4 filelog p4 files p4 fstat p4 fixes p4 groups p4 interchanges p4 jobs p4 labels p4 opened p4 servers p4 streams p4 sizes p4 user -o p4 users p4 where p4 workspaces	p4 add p4 edit p4 delete p4 diff p4 integrate p4 reconcile p4 resolve p4 revert p4 shelve p4 submit p4 sync p4 unshelve

Global update

Read-only

Work-in-progress

p4 configure set

p4 configure show

p4 client -o

p4 user -o