A frequent area of confusion in GemStone/S is the use of ports for the NetLDI when starting a remote gem. The Gem startup process is somewhat complex; describing it takes an hour or so of the Advanced Configuration class. I’ll see if I can condense it…

  1. A GCI client (Topaz, GemTools, Jade, VW/VA, etc.) contacts the NetLDI on a host/port. The port can be specified by number (e.g., 50377) or by name (e.g., gs64ldi) in which case it should be in the client and server services file with the same name/number. This port is defined implicitly by the name provided to the startnetldi command. If no name is provided, then the default of ‘gs64ldi’ is assumed. This port is unrelated to the port range provided as an optional argument (described later).
  2. The GCI client requests a service from the NetLDI; generally this is a new Gem using the script ‘gemnetobject’. The NetLDI puts the GCI client “on hold” while it starts up the new Gem. This conversation resumes at step #8.
  3. The NetLDI listens on a new random port for a callback (see #5).
  4. The NetLDI starts the Gem and passes it the port number from #3.
  5. The Gem calls the NetLDI on the port from #3 to request further instructions.
  6. The NetLDI tells the Gem that a GCI client wishes to make contact and that it should listen for the GCI client. If a port range is specified, then the NetLDI will select a port from the range and tell the new Gem to listen on that port. If no port range is specified then the Gem will allow the OS to pick a port at random.
  7. Using the connection established in #5, the Gem tells the NetLDI which port it is listening on (from #6). The connection from #5 is then closed.
  8. The NetLDI returns to the GCI client (using the connection established in #1 and put “on hold” in #2) and tells it what port to use to contact the Gem (the port number from #6). The connection between the GCI client and the NetLDI is then closed.
  9. The GCI client initiates a call to the Gem on the same host as the NetLDI but on a different port–the port on which the Gem is listening. That port number will be one selected by the NetLDI if a port range is specified or one selected by the OS if no port range is specified.
  10. The Gem accepts the connection from the GCI client and the GCI client provides login information (Stone NRS, userID, password, etc.).

Note that there are three (3) connections involved: (1) from the GCI client to the NetLDI; (2) from the Gem to the NetLDI; and, (3) from the GCI client to the Gem. The first connection is on the official NetLDI port that should be in the services file for each machine (gs64ldi/50377). The second connection is on a random port and there are no naming issues because it is completely self-contained in one host. The third connection is the one that can be random or can be limited to a particular range (using the -p50378:50378 argument to the startnetldi command). If there is a firewall on the server, then the ports for connections 1 and 3 need to be open to calls initiated from outside the server.

There are additional complexities. If the GCI client and the NetLDI are on the same host, then the named NetLDI does not need to be in the services file. Also, in steps 9/10 there are actually two connections, a primary one and an “out-of-band” connection. Furthermore, I could have gotten some of this wrong, but I think there is enough right to explain the difference between the number in the services file and the number in the port range.