The Perforce Broker

What is the broker?

The Perforce Broker (P4Broker) enables you to implement local policies in your Perforce environment by allowing you to restrict the commands that can be executed, or redirect specific commands to alternate (replica or edge) Perforce servers.

The Perforce Broker is a server process that mediates between Perforce client applications and Perforce servers, including proxy servers. For example, Perforce client applications can connect to a proxy server that connects to the broker, which then connects to a Perforce server. Or, Perforce client applications can connect to a broker configured to redirect reporting-related commands to a read-only replica server, while passing other commands through to a master server. You can use a broker to solve load-balancing, security, or other issues that can be resolved by sorting requests directed to one or more Perforce servers.

The work needed to install and configure a broker is minimal: the administrator needs to configure the broker and configure the users to access the Perforce server through the broker. Broker configuration involves the use of a configuration file that contains rules for specifying which commands individual users can execute and how commands are to be redirected to the appropriate Perforce service. You do not need to backup the broker. In case of failure, you just need to restart it and make sure that its configuration file has not been corrupted.

From the perspective of the end user, the broker is transparent: users connect to a Perforce Broker just as they would connect to any other Perforce Server.

System requirements

To use the Perforce Broker, you must have:

  • A Perforce server at release 2007.2 or higher (2012.1 or higher to use SSL).
  • Perforce applications at release 2007.2 or higher (2012.1 or higher to use SSL).

The Perforce Broker is designed to run on a host that lies close to the Perforce Server (p4d), preferably on the same machine.

Installing the broker

To install P4Broker, do the following:

  1. Download the p4broker executable from the Perforce website,
  2. Copy it to a suitable directory on the host (such as /usr/local/bin), and ensure that the binary is executable:

    $ chmod +x p4broker

Running the broker

After you have created your configuration file (see Configuring the broker), start the Perforce Broker from the command line by issuing the following command:

$ p4broker -c config_file

Alternatively, you can set P4BROKEROPTIONS before launching the broker and use it to specify the broker configuration file (or other options) to use.

For example, on Unix:

$ export P4BROKEROPTIONS="-c /usr/perforce/broker.conf"
$ p4broker -d

and on Windows:

C:\> p4 set -s P4BROKEROPTIONS="-c c:\p4broker\broker.conf"
C:\> p4broker

The Perforce Broker reads the specified broker configuration file, and on Unix platforms the -d option causes the Perforce Broker to detach itself from the controlling terminal and run in the background.

To configure the Perforce Broker to start automatically, create a startup script that sets P4BROKEROPTIONS and runs the appropriate p4broker command.

On Windows systems, you can also set P4BROKEROPTIONS and run the broker as a service. This involves the following steps:

C:\> cd C:\p4broker\
C:\p4broker\> copy p4broker.exe p4brokers.exe
C:\p4broker\> copy "C:\Program Files\Perforce\Server\svcinst.exe" svcinst.exe
C:\p4broker\> svcinst create -n P4Broker -e "C:\p4broker\p4brokers.exe" -a
C:\p4broker\> p4 set -S P4Broker P4BROKEROPTIONS="-c C:\p4broker\p4broker.conf"
C:\p4broker\> svcinst start -n P4Broker

svcinst.exe is a standard Windows program. P4Broker is the name given to the Windows service. For more information, see "Installing P4Broker on Windows and Unix systems" in the Perforce Knowledge Base:

http://answers.perforce.com/articles/KB_Article/Installing-P4Broker-on-Windows-and-Unix-systems

Enabling SSL support

To encrypt the connection between a Perforce Broker and its end users, your broker must have a valid private key and certificate pair in the directory specified by its P4SSLDIR environment variable. Certificate and key generation and management for the broker works the same as it does for the Perforce Server. See Enabling SSL support. The users' Perforce applications must be configured to trust the fingerprint of the broker.

To encrypt the connection between a Perforce Broker and a Perforce Server, your broker must be configured so as to trust the fingerprint of the Perforce Server. That is, the user that runs p4broker (typically a service user) must create a P4TRUST file (using p4 trust) that recognizes the fingerprint of the Perforce Server, and must set P4TRUST, specifying the path to that file (P4TRUST cannot be specified in the broker configuration file).

For complete information about enabling SSL for the broker, see:
http://answers.perforce.com/articles/KB/2596

Broker information

You can issue the p4 info to determine whether you are connected to a broker or not. When connected to a broker, the Broker address and Broker version appear in the output:

$ p4 info
User name: bruno
Client name: bruno-ws
Client host: bruno.host
Client root: /Users/bruno/Workspaces/depot
Current directory: /Users/bruno/Workspaces/depot/main/jam
Peer address: 192.168.1.40:55138
Client address: 192.168.1.114
Server address: perforce:1667
Server root: /perforce/server/root
Server date: 2014/03/13 15:46:52 -0700 PDT
Server uptime: 92:26:02
Server version: P4D/LINUX26X86_64/2014.1/773873 (2014/01/21)
ServerID: master-1666
Broker address: perforce:1666 Broker version: P4BROKER/LINUX26X86_64/2014.1/782990
Server license: 10000 users (support ends 2016/01/01)
Server license-ip: 192.168.1.40
Case Handling: sensitive

When connected to a broker, you can use the p4 broker command to see a concise report of the broker’s info:

$ p4 broker
Current directory: /Users/bruno/Workspaces/depot/main/jam
Client address: 192.168.1.114:65463
Broker address: perforce:1666
Broker version: P4BROKER/LINUX26X86_64/2014.1/782990

Broker and protections

To apply the IP address of a broker user’s workstation against the protections table, prepend the string proxy- to the workstation’s IP address.

For instance, consider an organization with a remote development site with workstations on a subnet of 192.168.10.0/24. The organization also has a central office where local development takes place; the central office exists on the 10.0.0.0/8 subnet. A Perforce service resides in the 10.0.0.0/8 subnet, and a broker resides in the 192.168.10.0/24 subnet. Users at the remote site belong to the group remotedev, and occasionally visit the central office. Each subnet also has a corresponding set of IPv6 addresses.

To ensure that members of the remotedev group use the broker while working at the remote site, but do not use the broker when visiting the local site, add the following lines to your protections table:

list    group    remotedev     192.168.10.0/24              -//...
list    group    remotedev     [2001:db8:16:81::]/48        -//...

write   group    remotedev     proxy-192.168.10.0/24         //...
write   group    remotedev     proxy-[2001:db8:16:81::]/48   //...

list    group    remotedev     proxy-10.0.0.0/8             -//...
list    group    remotedev     proxy-[2001:db8:1008::]/32   -//...

write   group    remotedev     10.0.0.0/8                    //...
write   group    remotedev     [2001:db8:1008::]/32          //...

The first line denies list access to all users in the remotedev group if they attempt to access Perforce without using the broker from their workstations in the 192.168.10.0/24 subnet. The second line denies access in identical fashion when access is attempted from the IPV6 [2001:db8:16:81::]/48 subnet.

The third line grants write access to all users in the remotedev group if they are using the broker and are working from the 192.168.10.0/24 subnet. Users of workstations at the remote site must use the broker. (The broker itself does not have to be in this subnet, for example, it could be at 192.168.20.0.) The fourth line denies access in identical fashion when access is attempted from the IPV6 [2001:db8:16:81::]/48 subnet.

Similarly, the fifth and sixth lines deny list access to remotedev users when they attempt to use the broker from workstations on the central office’s subnets (10.0.0.0/8 and [2001:db8:1008::]/32). The seventh and eighth lines grant write access to remotedev users who access the Perforce server directly from workstations on the central office’s subnets. When visiting the local site, users from the remotedev group must access the Perforce server directly.

When the Perforce service evaluates protections table entries, the dm.proxy.protects configurable is also evaluated.

dm.proxy.protects defaults to 1, which causes the proxy- prefix to be prepended to all client host addresses that connect via an intermediary (proxy, broker, broker, or edge server), indicating that the connection is not direct.

Setting dm.proxy.protects to 0 removes the proxy- prefix and allows you to write a single set of protection entries that apply both to directly-connected clients as well as to those that connect via an intermediary. This is more convenient but less secure if it matters that a connection is made using an intermediary. If you use this setting, all intermediaries must be at release 2012.1 or higher.

P4Broker options

Option Meaning

-c file

Specify a configuration file. Overrides P4BROKEROPTIONS setting.

-C

Output a sample configuration file, and then exit.

-d

Run as a daemon (in the background).

-f

Run as a single-threaded (non-forking) process.

-h

Print help message, and then exit.

-q

Run quietly (no startup messages).

-V

Print broker version, and then exit.

-v subsystem=level

Set server trace options. Overrides the value of the P4DEBUG setting, but does not override the debug-level setting in the p4broker.conf file. Default is null.

The server command trace options and their meanings are as follows.

  • server=0

    Disable broker command logging.

  • server=1

    Logs broker commands to the server log file.

  • server=2

    In addition to data logged at level 1, logs broker command completion and basic information on CPU time used. Time elapsed is reported in seconds. On UNIX, CPU usage (system and user time) is reported in milliseconds, as per getrusage().

  • server=3

    In addition to data logged at level 2, adds usage information for compute phases of p4 sync and p4 flush (p4 sync -k) commands.

For command tracing, output appears in the specified log file, showing the date, time, username, IP address, and command for each request processed by the server.

-Gc

Generate SSL credentials files for the broker: create a private key (privatekey.txt) and certificate file (certificate.txt) in P4SSLDIR, and then exit.

Requires that P4SSLDIR be set to a directory that is owned by the user invoking the command, and that is readable only by that user. If config.txt is present in P4SSLDIR, generate a self-signed certificate with specified characteristics.

-Gf

Display the fingerprint of the broker’s public key, and exit.

Administrators can communicate this fingerprint to end users, who can then use the p4 trust command to determine whether or not the fingerprint (of the server to which they happen to be connecting) is accurate.

Configuring the broker

P4Broker is controlled by a broker configuration file. The broker configuration file is a text file that contains rules for:

  • Specifying which commands that individual users can use.
  • Defining commands that are to be redirected to specified replica server.

To generate a sample broker configuration file, issue the following command:

$ p4broker -C > p4broker.conf

You can edit the newly-created p4broker.conf file to specify your requirements.

Format of broker configuration files

A broker configuration file contains three sections:

  • Global settings: settings that apply to all broker operations
  • Alternate server definitions: the addresses and names of replica servers to which commands can be redirected in specified circumstances
  • Command handler specifications: specify how individual commands should be handled; in the absence of a command handler for any given command, the Perforce Broker permits the execution of the command

Specifying hosts

The broker configuration requires specification of the target setting, which identifies the Perforce service to which commands are to be sent, the listen address, which identifies the address where the broker listens for commands from Perforce client applications, and the optional altserver alternate server address, which identifies a replica, proxy, or other broker connected to the Perforce service.

The host specification uses the format protocol:host:port, where protocol is the communications protocol (beginning with ssl: for SSL, or tcp: for plaintext), host is the name or IP address of the machine to connect to, and port is the number of the port on the host.

Protocol Behavior

<not set>

If the net.rfc3484 configurable is set, allow the OS to determine which transport is used. This is applicable only if a host name (either FQDN or unqualified) is used.

If an IPv4 literal address (e.g. 127.0.0.1) is used, the transport is always tcp4, and if an IPv6 literal address (e.g. ::1) is used, then the transport is always tcp6.

tcp:

Use tcp4: behavior, but if the address is numeric and contains two or more colons, assume tcp6:. If the net.rfc3484 configurable is set, allow the OS to determine which transport is used.

tcp4:

Listen on/connect to an IPv4 address/port only.

tcp6:

Listen on/connect to an IPv6 address/port only.

tcp46:

Attempt to listen on/connect to an IPv4 address/port. If this fails, try IPv6.

tcp64:

Attempt to listen on/connect to an IPv6 address/port. If this fails, try IPv4.

ssl:

Use ssl4: behavior, but if the address is numeric and contains two or more colons, assume ssl6:. If the net.rfc3484 configurable is set, allow the OS to determine which transport is used.

ssl4:

Listen on/connect to an IPv4 address/port only, using SSL encryption.

ssl6:

Listen on/connect to an IPv6 address/port only, using SSL encryption.

ssl46:

Attempt to listen on/connect to an IPv4 address/port. If this fails, try IPv6. After connecting, require SSL encryption.

ssl64:

Attempt to listen on/connect to an IPv6 address/port. If this fails, try IPv4. After connecting, require SSL encryption.

The host field can be the hosts' hostname or its IP address; both IPv4 and IPv6 addresses are supported. For the listen setting, you can use the * wildcard to refer to all IP addresses, but only when you are not using CIDR notation.

If you use the * wildcard with an IPv6 address, you must enclose the entire IPv6 address in square brackets. For example, [2001:db8:1:2:*] is equivalent to [2001:db8:1:2::]/64. Best practice is to use CIDR notation, surround IPv6 addresses with square brackets, and to avoid the * wildcard.

Global settings

The following settings apply to all operations you specify for the broker.

Setting Meaning Example

target

The default Perforce Server (P4D) to which commands are sent unless overridden by other settings in the configuration file.

target = [protocol:]host:port;

listen

The address on which the Perforce Broker listens for commands from Perforce client applications.

listen = [protocol:][host:]port;

directory

The home directory for the Perforce Broker. Other paths specified in the broker configuration file must be relative to this location.

directory = path;

logfile

Path to the Perforce Broker logfile.

logfile = path;

debug-level

Level of debugging output to log. Overrides the value specified by the -v option and P4DEBUG.

You can specify more than one value; see example.

debug-level = server=1;
debug-level = server=1, time=1, rpl=3;

admin-name

The name of your Perforce Administrator. This is displayed in certain error messages.

admin-name = "P4 Admin";

admin-email

An email address where users can contact their Perforce Administrator. This address is displayed to users when broker configuration problems occur.

admin-email = [email protected];

admin-phone

The telephone number of the Perforce Administrator.

admin-phone = nnnnnnn;

redirection

The redirection mode to use: selective or pedantic.

In selective mode, redirection is permitted within a session until one command has been executed against the default (target) server. From then on, all commands within that session run against the default server and are not redirected.

In pedantic mode, all requests for redirection are honored.

The default mode is selective.

redirection = selective;

service-user

An optional user account by which the broker authenticates itself when communicating with a target server.

The broker configuration does not include a setting for specifying a password as this is considered insecure. Use the p4 login -u service-user -p command to generate a ticket. Store the displayed ticket value in a file, and then set the ticket-file setting to the path of that file.

To provide continuous operation of the broker, the service-user user should be included in a group that has its Timeout setting set to unlimited. The default ticket timeout is 12 hours.

service-user = svcbroker;

ticket-file

An optional alternate location for P4TICKETS files.

ticket-file = /home/p4broker/.p4tickets;

compress

Compress connection between broker and server. Over a slow link such as a WAN, compression can increase performance. If the broker and the server are near to each other (and especially if they reside on the same physical machine), then bandwidth is not an issue, and compression should be disabled to spare CPU cycles.

compress = false;

altserver

An optional alternate server to help reduce the load on the target server. The name assigned to the alternate server is used in command handler specifications. See Alternate server definitions.

Multiple altserver settings may appear in the broker configuration file, one for each alternate server.

altserver name { target=[protocol:]host:port };

Each altserver setting must appear on one line.

Command handler specifications

Command handlers enable you to specify how the broker responds to different commands issued by different users from within different environments. When users run commands, the Perforce Broker searches for matching command handlers and uses the first match found. If no command handler matches the user’s command, the command is forwarded to the target Perforce Server for normal processing.

The general syntax of a command handler specification is outlined in the sample broker.conf:

command: commandpattern
{
# Conditions for the command to meet (optional)
# Note that with the exception of 'flags', these are regex patterns.
  flags           = required-flags;
  args            = required-arguments;
  user            = required-user;
  workspace       = required-client-workspace;
  prog            = required-client-program;
  version         = required-version-of-client-program;

  # What to do with matching commands (required)
  action  = pass | reject | redirect | filter | respond ;

  # How to go about it
  destination = altserver;            # Required for action = redirect
  execute = /path/to/filter/program;  # Required for action = filter
  message = rejection-message;        # Required for action = reject
}

The commandpattern parameter can be a regular expression and can include the .* wildcard. For example, a commandpattern of user.* matches both the p4 user and p4 users commands. See Regular expression synopsis

The following table describes the parameters in detail.

Parameter Meaning

flags

A list of options that must be present on the command line of the command being handled.

This feature enables you to specify different handling for the same p4 command, depending on which options the user specifies. Note that only single character options may be specified here. Multi-character options, and options that take arguments should be handled by a filter program.

args

A list of arguments that must be present on the command line of the command being handled.

user

The name of the user who issued the command.

workspace

The Perforce client workspace setting in effect when the command was issued.

prog

The Perforce client application through which the user issued the command. This feature enables you to handle commands on a per-application basis.

version

The version of the Perforce application through which the user issued the command.

action

Defines how the Perforce Broker handles the specified commands. Valid values are: pass, reject, redirect, filter, or respond.

destination

For redirected commands, the name of the replica to which the commands are redirected. The destination must be the name of a previously-defined alternate (replica) server listed in the altserver setting.

You can implement load-balancing by setting the destination to the keyword random. Commands are randomly redirected to any alternate (replica) server that you have already defined.

You can also set destination to the address:port of the server where you want commands redirected.

execute

The path to a filter program to be executed. For details about filter programs, see Filter programs.

message

A message to be sent to the user, typically before the command is executed; this may be used with any of the above actions.

For example, the following command handler prevents user joe from invoking p4 submit from the buildonly client workspace.

command: submit
{
    user = joe;
    workspace = buildonly;
    action = reject;
    message = "Submit failed: Please do not submit from this workspace."
}

Regular expression synopsis

A regular expression, or regex, is a sequence of characters that forms a search pattern, for use in pattern matching with strings. The following is a short synopsis of the regex facility available in command handler specifications.

A regular expression is formed from zero or more branches. Branches are separated by |. The regex matches any string that matches at least one of the branches.

A branch is formed from zero or more pieces, concatenated together. A branch matches when all of its pieces match in sequence, that is, a match for the first piece, followed by a match for the second piece, etc.

A piece is an atom possibly followed by a quantifier: *, +, or ?. An atom followed by * matches a sequence of 0 or more instances of the atom. An atom followed by + matches a sequence of 1 or more instances of the atom. An atom followed by ? matches a sequence of 0 or 1 instances of the atom.

An atom is:

  • a subordinate regular expression in parentheses - matches that subordinate regular expression
  • a range (see below),
  • . - matches any single character,
  • ^ - matches the beginning of the string,
  • $ - matches the end of the string,
  • a \ followed by a single character - matches that character,
  • or a single character with no other significance - matches that character.

A range is a sequence of characters enclosed in square brackets ([]), and normally matches any single character from the sequence. If the sequence begins with ^, it matches any single character that is not in the sequence. If two characters in the sequence are separated by -, this is shorthand for the full list of ASCII characters between them (e.g. [0-9] matches any decimal digit, [a-z] matches any lowercase alphabetical character). To include a literal ] in the sequence, make it the first character (following a possible ^). To include a literal -, make it the first or last character.

Filter programs

When the action for a command handler is filter, the Perforce Broker executes the program or script specified by the execute parameter and performs the action returned by the program. Filter programs enable you to enforce policies beyond the capabilities provided by the broker configuration file.

The Perforce Broker invokes the filter program by passing command details to the program’s standard input in the following format:

Command detail Definition

command:

user command

brokerListenPort:

port on which the broker is listening

brokerTargetPort:

port on which the target server is listening

clientProg:

client application program

clientVersion:

version of client application program

clientProtocol:

level of client protocol

apiProtocol:

level of api protocol

maxLockTime:

maximum lock time (in ms) to lock tables before aborting

maxScanRows:

maximum number of rows of data scanned by a command

maxResults:

maximum number of rows of result data to be returned

workspace:

name of client workspace

user:

name of requesting user

clientIp:

IP address of client

proxyIp:

IP address of proxy (if any)

cwd:

Client’s working directory

argCount:

number of arguments to command

Arg0:

first argument (if any)

Arg1:

second argument (if any)

clientHost:

Hostname of the client

brokerLevel:

The internal version level of the broker.

proxyLevel:

The internal version level of the proxy (if any).

Non-printable characters in command arguments are sent to filter programs as a percent sign followed by a pair of hex characters representing the ASCII code for the non-printable character in question. For example, the tab character is encoded as %09.

Your filter program must read this data from STDIN before performing any additional processing, regardless of whether the script requires the data. If the filter script does not read the data from STDIN, "broken pipe" errors can occur, and the broker rejects the user’s command.

Your filter program must respond to the Broker on standard output (stdout) with data in one of the four following formats:

action: PASS
message: a message for the user (optional)
action: REJECT
message: a message for the user (required)
action: REDIRECT
altserver: (an alternate server name)
message: a message for the user (optional)
action: RESPOND
message: a message for the user (required)
action: CONTINUE

Note

The values for the action are case-sensitive.

The action keyword is always required and tells the Broker how to respond to the user’s request. The available actions are:

Action Definition

PASS

Run the user’s command unchanged. A message for the user is optional.

REJECT

Reject the user’s command; return an error message. A message for the user is required.

REDIRECT

Redirect the command to a different (alternate) replica server. An altserver is required. See Configuring alternate servers to work with central authorization servers for details. A message for the user is optional.

To implement this action, the broker makes a new connection to the alternate server and routes all messages from the client to the alternate server rather than to the original server. This is unlike HTTP redirection where the client is requested to make its own direct connection to an alternate web server.

RESPOND

Do not run the command; return an informational message. A message for the user is required.

CONTINUE

Defer to the next command handler matching a given command.

For additional information on using multiple handlers, see:
http://answers.perforce.com/articles/KB/11309

If the filter program returns any response other than something complying with the four message formats above, the user’s command is rejected. If errors occur during the execution of your filter script code cause the broker to reject the user’s command, the broker returns an error message.

Broker filter programs have difficulty handling multi-line message responses. You must use syntax like the following to have new lines be interpreted correctly when sent from the broker:

message="\"line 1\nline 3\nline f\n\""

That is, the string must be quoted twice.

Alternate server definitions

The Perforce Broker can direct user requests to an alternate server to reduce the load on the target server. These alternate servers must be replicas (or brokers, or proxies) connected to the intended target server.

To set up and configure a replica server, see “Perforce Replication”. The broker works with both metadata-only replicas and with replicas that have access to both metadata and versioned files.

There is no limit to the number of alternate replica servers you can define in a broker configuration file.

The syntax for specifying an alternate server is as follows:

altserver name { target=[protocol:]host:port }

The name assigned to the alternate server is used in command handler specifications. See Command handler specifications.

Configuring alternate servers to work with central authorization servers

Alternate servers require users to authenticate themselves when they run commands. For this reason, the Perforce Broker must be used in conjunction with a central authorization server (P4AUTH) and Perforce Servers at version 2007.2 or later. For more information about setting up a central authorization server, see Configuring centralized authorization and changelist servers.

When used with a central authorization server, a single p4 login request can create a ticket that is valid for the user across all servers in the Perforce Broker’s configuration, enabling the user to log in once. The Perforce Broker assumes that a ticket granted by the target server is valid across all alternate servers.

If the target server in the broker configuration file is a central authorization server, the value assigned to the target parameter must precisely match the setting of P4AUTH on the alternate server machine(s). Similarly, if an alternate sever defined in the broker configuration file is used as the central authorization server, the value assigned to the target parameter for the alternate server must match the setting of P4AUTH on the other server machine(s).

Using the broker as a load-balancing router

Previous sections described how you can use the broker to direct specific commands to specific servers. You can also configure the broker to act as a load-balancing router. When you configure a broker to act as a router, Perforce builds a db.routing table that is processed by the router to determine which server an incoming command should be routed to. (The db.routing table provides a mapping of clients and users to their respective servers. To reset the db.routing table, remove the db.routing file.)

This section explains how you configure the broker to act as a router, and it describes routing policy and behavior.

Configuring the broker as a router

To configure the broker as a router, add the router statement to the top level of the broker configuration. The target server of the broker-router should be a commit or master server.

target      = commitserv.example.com:1666;
listen      = 1667;
directory   = /p4/broker;
logfile     = broker.log;
debug-level = server=1;
admin-name  = "Perforce Admins";
admin-phone = 999/911;
admin-email = [email protected];
router;

You must then include altserver statements to specify the edge servers of the commit server (or the workspace servers of the depot master) that is the target server of the broker-router.

altserver: edgeserv1
{
    target = edgeserve1.example.com:1669;
}

If you are using the broker to route messages for a commit-edge architecture, you must list all existing edge serves as altservers.

Routing policy and behavior

When a command arrives at the broker, the broker looks in its db.routing table to determine where the command should be routed. The routing logic attempts to bind a user to a server where they already have clients. You can modify the routing choice on the p4 command line using the following argument to override routing for that command.

-Zroute=serverID

Routing logic uses a default destination server, chosen at random, if a client and user have no binding to an existing edge server. That is, requests are routed to an existing altserver that is randomly chosen unless a specific destination is given.

  • To route requests to the commit server, use the destination form as follows:

    target      = commitserv.example.com:1666;
    listen      = 1667;
    directory   = /p4/broker;
    logfile     = broker.log;
    debug-level = server=1;
    admin-name  = "Perforce Admins";
    admin-phone = 999/911;
    admin-email = [email protected];
    
    router;
    destination target;
  • To cause new users to be bound to a new edge server rather than being assigned to existing edge servers, use a destination form like the following:

    target      = commitserv.example.com:1666;
    listen      = 1667;
    directory   = /p4/broker;
    logfile     = broker.log;
    debug-level = server=1;
    admin-name  = "Perforce Admins";
    admin-phone = 999/911;
    admin-email = [email protected];
    
    router;
    destination = "myNewEdge";
  • To force a command to be routed to the commit server, use an action = redirect rule with a destination target statement; for example:

    command: regex pattern
    {
        action=redirect;
        destination target;
    }

Note

You need to remove the db.routing file when you move clients to a different workspace or edge server.