Ich dachte die ganze Zeit an einen
Indy-
TCP-Server/Client. Dem Server werden commands geschickt (ähnlich wie Parameter-Übergaben bei Webseiten). Diese liest er aus und führt die jeweilige Aktion durch.
Eine einfache Architektur wäre ein zentraler Windows Server mit einem auf dem
Indy HTTP Server basierenden Service.
Darin würde ein
MySQL Connection Pool dafür sorgen, dass immer frische, knusprige Datenbankconnections vorrätig sind.
Die Clients würden dann (ebenfalls
Indy basierte) HTTP Verbindungen öffnen, Requests mit Parametern senden und die Daten dann als Anwtorten zum Beipisle JSON codiert erhalten.
Gegenüber reinem
TCP hat HTTP einige Vorteile. Es können ständig geöffnete Verbindungen verwendet werden (keep-alive, HTTP 1.1) und über long polling kann eine Verbindung auch aktiv Daten vom Server erhalten ('Server-Push'). Dazu würde dann allerdings eine separate Connection benötigt, nicht die in der die normalen blockierenden Daten-Requests stattfinden.
p.s. natürlich sind bestehende Frameworks, wenn sie denn genau zu den Anforderungen und Rahmenbedingungen passen, sehr zu empfehlen. Nur bei kleinen bis mittleren Systemen würde ich eine Eigenentwicklung erwägen. Oder wenn man "experimentierfreudig" zu seinen soft skills zählt
