Wie findet der Client seinen Server?

Wie findet der Client seinen Server?

Hintergrund

Es kann vorkommen, dass der timeSensor Client nach einem Update seinen Server nicht mehr findet, oder dass Kunden auf einem Testserver im gleichen Netzwerk landen, wenn der Produktivserver ausgeschaltet ist. Dieser Artikel diskutiert, wie sich 4D diesbezüglich verhält.

Reihenfolge

 

Nach dem Starten des 4D Clients benötigt dieser die IP Adresse des Datenbankservers. 4D verhält sich an dieser Stelle wie folgt:
  1. Alt-Taste gedrückt - Verbindungsdialog anzeigen
  2. EnginedServer.4DLink auslesen - wenn eine gültige Serveradresse eingetragen ist, verbinden mit dem Server
  3. Polling: der Client sucht im aktuellen Subnetz, ob er einen passenden Server findet. Falls ja, verbindet er sich automatisch mit dem Server
  4. lastServer.xml auslesen: ist im Subnetz des Clients nichts zu finden, sucht der Client nach der Datei lastServer.xml. Dort ist der zuletzt benutzte Server eingetragen - wenn eine gültige Serveradresse eingetragen ist, verbinden mit dem Server
  5. Wurde immer noch kein gültiger Server gefunden - Verbindungsdialog anzeigen
Diese Reihenfolge führt dazu, dass der Client nach einem Update möglicherweise auf dem falschen Server landet, wenn der Server seine Adresse broadcastet und in der Datei EnginedServer.4DLink kein gültiger Server eingetragen ist.

Workaround

Da wir dieses Verhalten mit programmiertechnischen Massnahmen leider zumindest kurzfristig nicht ändern können, würden wir empfehlen, das Broadcasting von Test-Servern zu unterbinden.
Dies ist möglich per Blockierung des UDP-Protokolls auf dem Port 19813 in der Firewall des Testservers.