Protokoll für Clients....

Alle Fragen zur Netzwerkkommunikation
Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: Protokoll für Clients....

Beitrag von Warf »

pluto hat geschrieben:
Ich kenne mich mit Synapse nicht aus

Ich nutzte hierfür LNET. Synapse nutzte ich an andere Stelle.

Gut, deinem Beispiel entnehme ich, ich kann auch bei SendString bleiben. Die Methode macht es intern ganz ähnlich... Dann haben Record für mich keinen Sinn.


Der Record ist ja für dateneffizienz bei den binären Daten gemeint, binärdaten sind logarithmisch zur Basis 2 groß, das Äquivalent als String wäre logarithmisch zur Basis 10 damit ist die stringvariante bis zu einem Faktor von 3,3. du sendest also bis zu 3 mal mehr Daten als notwendig
Beispiel
10000 würde als Word 2 Byte brauchen, als String 5 Byte

Und das nur für Integer, für Floating point typen wie Single oder Double sogar noch mehr, und bei enums kann man beliebig viel Speicher verbrauchen
Beispiel
Die Befehle Start und Stop würden als Enum nur ein Byte verbrauchen, als String 5 Byte, oder

Code: Alles auswählen

TBeispielEnum = (nbeIrgendeinLangerName, nbIrgendeinAnderererLangerName); // 1 Byte, die strings c.a. 30 Byte


Außerdem fällt das Stringparsing weg, um eine Zahl zu lesen muss für jeden Char mehrere Rechenoperationen durchgeführt werden. Wenn du es als Integer liest dann allerhöchstens die Drehung der Bytes wegen der Endianess was 2 Schreiboperationen für jedes Byte wären, aber es hätte bis zu 3 mal weniger Bytes zu lesen.

Aber wie schon zu Anfang gesagt, strings sind recht bequem und vor allem flexibel und vielseitig einsetzbar, und du brauchst das für das Lokale System nicht zu optimieren, wenn du es optimieren willst ist es eben aufwendig.

pluto
Lazarusforum e. V.
Beiträge: 7178
Registriert: So 19. Nov 2006, 12:06
OS, Lazarus, FPC: Linux Mint 19.3
CPU-Target: AMD
Wohnort: Oldenburg(Oldenburg)

Re: Protokoll für Clients....

Beitrag von pluto »

Erst einmal danke, für eure Vorschläge/hinweise. Zum Verständnis:
Wenn ich ein Record habe, wo die Variablen feste Längen haben, kann ich den Record einfach versenden.
Habe ich nun Dynamischen Variablen wie z.b. ein String, muss ich ihn hinterhersenden.

Also erst sende ich den Record mit den "festen längen" und anschließend den Dynamischen Bereich. D.H. die Empfänger Routine muss dafür ausgelegt sein.

Zu den Strings:
Ich versende in der Regel Integer oder Float Werte, aber auch ein paar Strings. D.h. ich könnte im Record z.b. ValueInt, ValueF hinzufügen und ein "Record tiefer" ein ValueStr.

Aber wie schon zu Anfang gesagt, strings sind recht bequem und vor allem flexibel und vielseitig einsetzbar, und du brauchst das für das Lokale System nicht zu optimieren, wenn du es optimieren willst ist es eben aufwendig.

Das stimmt natürlich. Aber ich sehe auch die Vorteile, wenn man den "String" verkleinern kann.
Meine Idee ist jetzt folgende:

1. Ein Client meldet sich beim Server an.

2. Beim Anmelden muss der Client ein Flag mit senden: Finale Version oder noch in der Entwicklung.
Bei der Finalen Version, würde der Server die "Daten" in einer Datei speichern. Bei der Entwickler Version nicht. Dann würden die nur in der Struktur landen, wenn die noch nicht drin sind, sonst würden die hinzugefügt oder Aktualisiert.
Über das Flag könnte man auch neue Infos Anmelden.
Klar kann der Server noch eine Version Senden und der Client auch.

Ich denke, dass Spart "Bandbreite".

Der Client muss hier bei je nach Flag, eine komplette Liste alle Informationen Senden.
Der Server speichert es in einer Dynamischen Datenstruktur. Parallel dazu, legt er eine Pointer Liste an.
Diese Liste muss beim Client und beim Server gleich sein. Dann würde ich beim Senden: Ein Index senden, sowie eine ID und die eigentlichen Daten.

Die ID Dient dazu zu prüfen ob die Liste auch gleich ist, wenn nicht muss die Liste beim Client ausgetauscht werden. Wenn ich nur ein Index sende, kann ich dies nicht prüfen. Den Zeitstempel müsste ich nur Senden, wenn ein Client, die Liste der zuletzt gesendeten Informationen anfordert. Z.B. wenn sich ein Client neu Anmeldet.
Damit kann ich den "Sender String" auf ein Minimum reduzieren.

Das ganze werde ich mal in einer neuen Test Umgebung versuchen umzusetzen, bevor ich es in die eigentliche Anwendung einbauen.
MFG
Michael Springwald

Antworten