Feedback
 
Did this article resolve your question/issue?

   

Your feedback is appreciated.

Please tell us how we can make this article more useful. Please provide us a way to contact you, should we need clarification on the feedback provided or if you need further assistance.

Characters Remaining: 1025

 


Article

Why define specific minport maxport ranges?

« Go Back

Information

 
Article Number000012081
EnvironmentProduct: Progress
Version: 8.x, 9.x
Product: OpenEdge
Version: 10.x, 11.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/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 000012067, 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 000022547, 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.
Workaround
Notes
Attachment 
Last Modified Date3/14/2019 8:08 AM