The reasoning below for using different port ranges for each instance, applies to both databases and ubrokers( e.g. Classic Webspeed and AppServer).
Progress 8.2A introduced parameters designed to help tighten security with Firewalls with the introduction of the database startup parameters -minport and -maxport. These parameters allow the Administrator to specify a distinct range of TP ports available, per database, for the login database broker to assign to remote servers for client/server connections. In effect, the minport and maxport setting defines a range of useable TCP ports.
When a client connects client server to a database on the Service the database Broker is listening (-S), the login broker spawns a remote server on the next available port in the minport maxport range, (if not already spawned) then assigns that client connection to that remote server or the next available remote server depending on the -Mi and -Ma database startup parameters.
There is however nothing stopping a remote client connecting directly to an existing remote server and this is one of the most important reasons that -minport -maxport need to be taken into consideration as part of the initial database configuration design.
Consider the following scenario:
CAVEAT:
The production and test databases have the same name.
The client connects client-server.
1. Production database is started with -S 3000.
2. Test database uses -S 3010.
3. Both production and test use the default -minport 3000 -maxport 5000 range.
4. The test database has since been shut down making port 3010 available.
5. The production database has a remote server spawned listening on port 3010.
If the test database were to be started at this juncture, it would fail with:
The port 3010 is already in use. (12036)
6. A user/developer decides to "do stuff" on the test database and connects client/server to the test database using the command:
CONNECT -db dbname -S 3010
The user/developer is now connected to the production database at this point and not the test database due to the -S 3010 specification. If the user/developer runs (say) a performance benchmark on a massive delete code enhancement it would impact the production database instead of the test database.
ADVICE:
- Define distinct -minport and -maxport ranges for each database in an application environment. The range needs to accommodate enough available ports to satisfy the value of -Mn (maximum remote servers), or more specifically the -Mpb (maximum remote servers per broker type).
- Keep the -S port number/service name that database brokers are started with, outside of the -minport and -maxport ranges.
- For ABL client/server connections, ensure that the -minport -maxport range is not reserved in etc/services. Refer to Article Clients unable to connect to database server when server attempts to bind to ports defined in services file.
- When the network is firewalled, ensure the port ranges are open. Refer to Article Which ports needs to be open on a firewall between a remote client and the database?
- troubleshooting
Additional reasons for specifying distinct port range for each database:
- Better performance. Each database broker that start remote servers in different port ranges will save time searching for an available port by having to scan from -minport to -maxport to find the first available port.
- Better for troubleshooting. The remote server port in question can be immediately associated with a specific database.
- When the Login Broker fails to find an available port in the minport/maxport range, a new server cannot be started but neither can new c/s connections be made. For further detail refer to Article: C/S connections fail when _mprosrv ports are exhausted error 1159
