Feedback
Did this article resolve your question/issue?

   

Article

Why define specific minport maxport ranges?

« Go Back

Information

 
TitleWhy define specific minport maxport ranges?
URL NameP127410
Article Number000128010
EnvironmentProduct: Progress
Version: 8.x, 9.x
Product: OpenEdge
Version: 10.x, 11.x, 12.x
OS: All supported platforms
Question/Problem Description
Why define distinct minport maxport ranges?
Can databases share the same minport maxport range for client-server connections?
What are the -minport -maxport database login broker startup parameters used for?
Considerations in using default -minport -maxport ranges for all remote database connections across all databases.
Steps to Reproduce
Clarifying Information
Error Message
Defect Number
Enhancement Number
Cause
Resolution
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 TCP 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:
  1. 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).
  2. Keep the -S port number/service name that database brokers are started with, outside of the -minport and -maxport ranges.
  3. 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.
  4. 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? 
  5. Extent this logic to Ubroker port ranges (srvminport, srvmaxport).
Additional reasons for specifying distinct port range for each database:
  1. 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.
  2. Better for trouble shooting. The remote server port in question can be immediately associated with a specific database.
  3. 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
Workaround
Notes
Last Modified Date1/4/2021 2:51 PM
Attachment 
Files
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.