AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Programmieren allgemein Client/Server Architektur realisieren - Ideen
Thema durchsuchen
Ansicht
Themen-Optionen

Client/Server Architektur realisieren - Ideen

Ein Thema von TheMiller · begonnen am 5. Dez 2014 · letzter Beitrag vom 28. Dez 2014
Antwort Antwort
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#1

AW: Client/Server Architektur realisieren - Ideen

  Alt 11. Dez 2014, 00:51
Zum Thema:

Wofür soll der Windows-Dienst mit dem TCP-Server benutzt werden? Der ist mMn völlig überflüssig.

Man nehmen einen MessageQueue-Server seiner Wahl und fragt dort nach Nachrichten. Achtung, nur in einem separaten Thread, denn wenn nichts in der Queue ist, dann dauert diese Abfrage ein Weilchen.

Ist etwas in der Queue, dann bekommt man auch prompt die Antwort, wirft diese dann in der Anwendung in die Runde und wartet auf/holt sich die nächste Nachricht.

Der Rest geht mit der REST-API.
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Benutzerbild von TheMiller
TheMiller

Registriert seit: 19. Mai 2003
Ort: Gründau
2.480 Beiträge
 
Delphi XE7 Architect
 
#2

AW: Client/Server Architektur realisieren - Ideen

  Alt 11. Dez 2014, 09:13
Moin!

Wofür soll der Windows-Dienst mit dem TCP-Server benutzt werden? Der ist mMn völlig überflüssig.
Ja, da gebe ich dir zwar Recht. Der Server soll aber noch andere Dinge übernehmen, als nur die DB-Anbindung zu verwalten. Ich möchte einen kleinen Realtime-Chat realisieren, eine eigene Datensicherung nur für den Notfall, Benachrichtigungen über den Online-Status der Benutzer etc. Ein weiteres Beispiel: Benutzer 1 - 4 haben das Plugin A offen. Benutzer 1 ändert jetzt einen Eintrag. Der Server soll dann gleich alle anderen Benutzer (2-4) benachrichtigen, dass neue Daten vorliegen, damit dort die Listen neu geladen werden können.

Diese und andere kleine Aufgaben soll der Server bewerkstelligen. Ich denke, es ist nicht verkehrt, einen solchen zu implementieren. Zur Kommunikation bin ich jetzt gedanklich dabei stehengeblieben, ein Record zu versenden. Ist das okay?

Das Record soll mindestens den Timestamp, Absender und die Anfrage (json_string) beinhalten. Mir fällt leider nichts anderes als ein json_string ein. Und da sehe ich ein Problem:

Manchmal muss es sein, dass 500+ Einträge aus der DB geladen werden. Jeder Eintrag ist ein Objekt - sagen wir mal, ein Adressen-Objekt. Diese Liste nun in einen json-String zu konvertieren dürfte ziemlich aufwendig / unperformant sein, oder? Welche Möglichkeit gibt es noch, Objekte/Objectlists über das Netzwerk zu versenden?

Danke!
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#3

AW: Client/Server Architektur realisieren - Ideen

  Alt 11. Dez 2014, 11:05
Manchmal muss es sein, dass 500+ Einträge aus der DB geladen werden. Jeder Eintrag ist ein Objekt - sagen wir mal, ein Adressen-Objekt. Diese Liste nun in einen json-String zu konvertieren dürfte ziemlich aufwendig / unperformant sein, oder?
Wir leben im Zeitalter von GHZ-Prozessoren mit mehreren Kernen und 39+GB RAM (oder von mir aus auch nur 4 GB).

500.000.000 Objekte sind ein Problem, aber doch keine 500. Das macht mein Telefon sogar schon in <0.1ms (leicht übertrieben ausgedrückt).

Die Überlegungen sind grundsätzlich richtig (Ich hatte ähnliche bei meinem ersten N-Tier Projekt, wo ich dachte, XML würde alle Grenzen sprengen), daher mein Tipp:

Mach einfach Messungen. Prüfe, ab welchem Bereich Du meinst, Performanceprobleme zu bekommen. Versuche dann, diese Probleme zu bewerten: Sind diese im Betrieb derzeit erreichbar? Oder in absehbarer Zeit? Welche Maßnahmen kannst Du ergreifen (z.B. die Objekte zu cachen)? etc.
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#4

AW: Client/Server Architektur realisieren - Ideen

  Alt 11. Dez 2014, 12:29
Egal ob Chat oder irgendwelche sonstigen Benachrichtigungen, dafür eine extra Service-Anwendung zu bauen und die Komplexität zu erhöhen halte ich für unklug.

Die REST-API weiß, ob eine bestimmte Aktion eine Benachrichtigung erfordert. Wenn, dann trägt diese das in die entsprechenden MessageQueues ein. Diese MessageQueues werden vom Client selber überwacht/abgefragt (Long Polling).

Ob diese Benachrichtigung nun eine Chat-Nachricht oder eine Änderung an dem Datensatz X betrifft spielt doch keine Geige. Das muss der Nachrichteninhalt hergeben.

Was du mit dem Änderungszeitpunkt anfangen möchtest ist mir auch noch nicht klar.

In einem System (speziell einem asynchronen) sollte jede Änderung (Nachricht vom Client an die API) den Zeitpunkt des Auftretens (ocurred) beinhalten. Die API fügt dann noch den Zeitstempel ein, wann das empfangen wurde (received) und trägt die Information ein.

(Muss ich erwähnen, dass die Zeitbasis immer UTC-bezogen sein sollte?)

Jetzt kommen wir zum eigentlichen Kern:

Gibt es in der API schon einen Eintrag, mit einem jüngeren ocurred, dann hat sich der Datensatz nicht verändert - die Historie hat sich sehr wohl verändert - und zieht somit keine weitere Aktionen der anderen Clients nach sich, es sei denn, die schauen sich die Historie an.
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:54 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz