Client/Server Architektur realisieren - Ideen

[Dejan Vu]

Optimierung kosten Zeit. Programmierzeit. Wenn Du genügend davon hast, wunderbar. Andere müssen damit rechnen, haushalten etc. Bei professionellen amateurhaften Softwareentwicklern spielt die Resource 'Zeit' nun mal eine Rolle.

Und wenn ich dem Kunden sage: "Dein Tool verschickt nur noch 5kb anstatt vorher 15kb, kostet aber dafür einen Tagessatz mehr", dann schaut dieser mich etwas verdutzt an, knallt mir die Spec ins Gesicht, dreht sich um und sagt: "Das wars dann wohl". Wenn er freundlich ist.

In der professionellen amateurhaften Softwareentwicklung macht man genau das, was der Kunde will. Wer noch eins draufsetzt, macht es gut. Wer noch eins draufsetzt, macht es nachhaltig.

Steht in der Spec: Bitte Bandbreite optimieren, wird das gemacht. Steht es dort nicht, wird es nicht gemacht. Steht dort: Muss bei einer 100kbit-Leitung in 10 Sekunden durchrauschen, wird es gemacht. Steht dort nichts, schaut man sich um, was so usus ist ("allgemeiner Stand der Technik" oder fragt nach) und setzt dann ggf. nach Rücksprache um.

Wo ist da ein OMG, oder 'selten so einen Blödsinn gelesen'?

Edit: Noch ein kleines...

Zitat von Donald E. Knuth, 1974:

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

[Mavarik]

Zitat von Dejan Vu:

Optimierung kosten Zeit.

Ich will Dir nicht schon wieder ein OMG schreiben... denn im Prinzip hast Du recht! Mein Standpunkt ist ein anderer.

Ich sage: Optimierung kostet keine Zeit wenn man beim programmieren einfach mal den Kopf zusammen hält.

Ein "Beginupdate, EndUpdate" einer Liste bringt einen enormen Geschwindigkeitszuwachs und kostet keine Zeit.
Und stört auch nicht bei debuggen...
oder stört die Lesbarkeit des Codes...

Mavarik

[mkinzler]

Ich meine mal, das diese Optimierungen hier nicht gemeint sind.

[Dejan Vu]

Zitat von Mavarik:

Ich sage: Optimierung kostet keine Zeit wenn man beim programmieren einfach mal den Kopf zusammen hält.

Ein sehr schönes Thema für einen eigenen Thread.

[Mavarik]

Zitat von Dejan Vu:

Zitat von Mavarik:

Ich sage: Optimierung kostet keine Zeit wenn man beim programmieren einfach mal den Kopf zusammen hält.

Ein sehr schönes Thema für einen eigenen Thread.

Stimmt.. Hat hier nix zu suchen

[TheMiller]

Guten Morgen!

Nachdem ich den Thread nochmal komplett gelesen und mir über das Wochenende viele Gedanken gemacht habe, möchte ich nochmal zusammenfassen und konkrete Umsetzungsvorschläge anbringen:

* Auf dem Datenbank-Server wird eine REST-API eingerichtet. (Diese habe ich zum Glück schon aus einem anderen Projekt fertig). Die API deshalb, weil wir tatsächlich planen, noch andere Plattformen zu bedienen und die Wartung ist viel einfacher (Queries nur auf einer Plattform aktualisieren/erstellen). Long-Polling kann umgesetzt werden.

* Auf dem Windows-Server wird ein Server-Dienst laufen. Dieser dient auch als Zwischenschicht zwischen Clients und Datenbank-Server. Die Verbindung wird über TCP-Server/TCP-Client von Indy realisiert. Der Server-Dienst nimmt requests entgegen und verarbeitet sie. Diese Requests sind vom Typ TRecord und haben mindestens folgende Felder: Absender, Empfänger, Timestamp, request_id, request_str (json_string). So sollte eine exakte Zuordnung und Verarbeitung der Nachricht möglich sein (genauer ist das noch nicht durchdacht). Je nachdem, was der TRequest dem Server aufträgt, führt er die Aktion durch (Aktion mit anderen Clients oder Anfrage an die DB). Danach sendet er an den ursprünglichen Absender oder einen "Broadcast" TResponse zurück.

* Der Server-Dienst prüft die Erreichbarkeit des Datenbank-Server (vllt. Ping, oder über eine UniDAC-Methode (weiß ich noch nicht)). Ist er mal nicht erreichbar, sendet er einen "Broadcast" (eher eine TCP-Nachricht an alle Clients), dass der Server weg ist. Diese zeigen es dann in der GUI an. Vllt. empfängt der Dienst Datenbank-Anfragen, die er zurückhalt, bis die Verbindung wieder aktiv ist. Weitere Aufgaben der Windows-Dienstes sind zeitgesteuerte kleinere Backups (kein Image o.ä.)/Aufräumarbeiten, Benachrichtigungssysteme etc.

* Benachrichtigungssysteme:
- User A und B haben Modul-1 offen. User B ändert Daten über Modul-1. Nun sendet der Dienst eine TCP-Nachricht an alle User, die Modul-1 offen haben, damit sie aktuelle Daten laden können. Bzw, der Server lädt einmal die aktuellen Daten und sendet sie schon an den User.
- Ein wichtiges Modul ist gerade nicht geöffnet. Es wurden aber von B wichtige Daten für A hinterlegt. So wird User A vom Server benachrichtigt, dass wichtige Daten vorliegen.

* Optimierungen: Da z.T. auch über außenstellen gearbeitet wird, ist VPN sehr wichtig (sensible Daten und einfachere Kommunikation). Die Daten sollen also klein gehalten werden. Ein Zwischending zwischen den hier genannten Vorschlägen wird einzuhalten sein. Wenn man gut plant, mitdenkt und den rest durch ausprobieren ermittelt, dann wird es kein Thema sein.

Soweit bin ich erstmal. Hab nur eine Frage zum Format der TCP-Anfragen. Wie soll ein Kommando an den Server aussehen? Es wird ja vermutlich ein String sein. Soll er wie Parameter in URLs aussehen (module=abc&action=getImportantData&dataId=123), soll er in URL-Form sein (/ABC/getImportantData/123), oder soll es ein Record sein TParams (Modul: abc, Action: xyz...). Was macht da Sinn? Man müsste immer mit Explode etc. arbeiten. Habt ihr dazu noch weitere Vorschläge?

Vielen Dank für die rege Anteilnahme!

[Mavarik]

Zitat von DJ-SPM:

Wie soll ein Kommando an den Server aussehen?

Immer ein Record nehmen... Da hast Du alle Felder getrennt und musst nicht extra wieder einen String analysieren.

Mavarik

[Sir Rufo]

Wenn die REST-API LongPolling kann wofür in Gottes Namen dieser Windows-Dienst?

Mehr Komplexität?

Und der Service soll auch noch direkt mit dem Datenbank-Server sprechen, also an der REST-API (Zwischenschicht) vorbei?

Respekt, so kann man viele Vorteile der Zwischenschicht auch gleich wieder mit dem Hintern einreissen

Ich hätte ja noch verstanden, wenn man, aus welchen Gründen auch immer, den Windows-Service per LongPolling mit der Zwischenschicht verbindet. Aber so ist das ein tolles Beispiel, wie man so etwas nicht machen sollte.