Troubleshooting
Problem
An SQL Anywhere server is installed on a server machine connected to LAN "A". Several test projects are hosted on this server and, for better flexibility, a separate service is created for each project. All client machines on LAN "A" can always connect to their respective projects. However, in a remote location there is also LAN "B" on which client machines sometimes cannot connect to certain projects. Rebooting the server may sometimes render one project accessible but then another project cannot be reached. The symptoms would suggest that the service is stopped, though it is running and workstations on LAN "A" have no difficulties connecting to any projects.
Cause
The remote client machines do not know which TCP/IP ports should be used when communicating with the different services.
The recommended way to start a service:
-n <DBServerName> -gd all
works fine as long as there is only one service running on the same server machine. The service assumes then the default port number [2638] and its process registers as a listener on this port. However, when trying to start another service, its process cannot register as a listener on port 2638, as this port is already "booked" by "another process". In this case, a random port number will be assumed instead of the default port 2638.
On the client side, when trying to communicate with service "a" on server "x":
1. first, communication is attempted on port 2638
2. if wrong service is reached, the client machine checks its asasrv.ini file where the last known port number for this service is stored
3. if this also fails, a broadcast is sent to check on which port the required service will respond
Thus, if at the server's start-up the required service happens to be the first to be started, it will register and communicate on port 2638 and the communication from client machine will be established on this port, with no problem. However, for any other service, a random port is assigned, which is probably different than the "last known port for this service" saved in the clients' asasrv.ini file. Thus, a distant client machine will fail to reach this service on the port 2638 and on the last known port. The client machine is then forced to send the broadcast, but since it is based on the UDP packets and it does not work over WAN. This explains why the service seems to be stopped to the remote workstations while everything works fine for the workstations connected to LAN "A".
Resolving The Problem
To resolve this problem:
1. Assign explicitly distinct port numbers to each service. To achieve this, the service should start with the following command:
-n <DBServerName> -gd all -x "tcpip(host=<xx.yy.zz.ww>;ServerPort=<ppp>)"
where:
- DBServerName is the name of the SQL Anywhere server associated with the service
- xx.yy.zz.ww is the server's IP address
- ppp is the port number explicitly assigned for this service
The assigned port numbers should be selected in such a way that no conflict with other TCP/IP listeners can occur. Also, if there is a firewall between LAN "A" and LAN "B", make sure that you select open ports.
2. Now that port numbers are statically defined for all services, it is necessary to make sure that the workstations know which ports to use. To do this:
- use a workstation on LAN "A" to connect to all the projects that will be used from LAN "B"
(this workstation will send the broadcast to find the port numbers for all services and save them in the asasrv.ini file)
- copy the file: C:\applinat\euclide\rational\sqlanywhere8\win32\asasrv.ini from this workstation to the same location on all the workstations on LAN "B". Alternatively, you can edit the asasrv.ini file on each workstation and populate it with the correct information in the following format:
[dbserver_service]
Link=TCPIP
Address=213.228.0.42:49152
From now on, the remote workstations will always be able to use the right ports for the right services.
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21272425