AcuConnect Connection Logic

How the client connects to AcuConnect depends on the client application that is attempting to connect. However, some common steps are involved with any attempt, regardless of the client application. These are described here to clarify the use of the server access file and the DEFAULT_USER configuration variable.

To validate a requester's access privileges, AcuConnect does the following when a client process first makes a request to AcuConnect:

1. Opens the server access file.
2. Searches for a record that matches both the client machine name and the client user name.
3. (If no match is found) searches for a record that matches the client machine name and a "match all" (blank) client user name.
4. (If no match is found) searches for a record that has the "match all" ("*") client machine name and the client user name.
5. (If no match is found) searches for a record that has the "match all" ("*") client machine name and the "match all" (blank) client user name.
6. (If no match is found) refuses the connection.

When a match is found:

1. If the Local Username is valid, it is used.
2. If the Local Username is not valid, DEFAULT_USER is used.
3. If the Local Username is not valid and DEFAULT_USER is not valid, the connection is refused.
4. If the Local Username is valid and the password field is defined, a message is sent back to the requester asking for a password.

When a connection is established, AcuConnect invokes the runtime based on the information provided by the client making the request. AcuConnect connects that child runtime with the client and then removes itself from the communication loop between the two processes.