FiveTech Support Forums

SMB vs. Socket – warum ein Microservice für DBF stabiler ist

Bei klassischen DBF-Anwendungen greifen die Clients über ein Netzlaufwerk (X:\ oder \\Server\Share\…) auf die Daten zu. Damit ist immer das SMB-Protokoll im Spiel:

Jeder Client öffnet die Datei direkt über den Netzwerk-Redirector.

Locks (FLOCK/RLOCK) müssen über SMB ans Server-Filesystem weitergereicht werden.

Risiken: zusätzliche Latenz, Oplocks/Leases, AV-Filtertreiber, Netzwerkaussetzer.

Anders beim Socket-basierten Microservice:

Nur ein Prozess am Server öffnet die DBF-Dateien – lokal über Laufwerksbuchstaben (D:\DATAWIN\…), also direkt über den Festplattencontroller, ohne SMB.

Alle Clients sprechen diesen Prozess über Sockets (TCP/HTTP/WebSocket) an.

Vorteile:

Kein SMB, kein Redirector → eine Fehlerquelle weniger.

Sauberes Locking: der Service entscheidet, wann FLOCK/RLOCK gesetzt und gelöst wird.

Linearisiert: konkurrierende Requests laufen in einer Queue → keine Rennbedingungen.

Robust gegen Netzabbrüche: nur der Socket bricht ab, die DBF bleibt konsistent.

Volle Kontrolle über Logging, Timeouts, Konflikt-Handling.

👉 Kurz:

SMB = viele Handles, viel Koordination, anfällig.

Socket-Service = ein Handle, eine Instanz, volle Kontrolle.

Gerade bei DBF/CDX lohnt sich der Schritt weg vom Netzlaufwerk hin zum Microservice – stabiler, schneller, einfacher zu überwachen.

SMB (Netzlaufwerk)

[Client A] -----\

             \

[Client B] -------> [SMB Redirector] -> [Netzwerk] -> [Server FS + NTFS]

             /

[Client C] -----/

• Jeder Client öffnet DBF direkt über SMB

• Jede DBF-Operation = viele Roundtrips über das Netz

• Locks (FLOCK/RLOCK) werden übers Netz verhandelt

• Viel "chatter" = langsam + störanfällig

Socket-Microservice

[Client A] ----\

            \

[Client B] -------> [Socket Service @Server] -> [NTFS lokal]

            /

[Client C] ----/

• Nur der Service hält DBF-Dateien offen (lokal D:\…)

• Clients schicken kompakte Requests (Seek, Update…) per Socket

• Wenige Roundtrips: Request -> Result

• Locks & I/O werden direkt am Server-Kernel durchgesetzt

• Stabil + oft 5–10× schneller

Damit sieht man sofort:

SMB = viele direkte Filehandles + Netzwerkverkehr

Socket-Service = ein zentraler Filehandle, minimale Netzlast, sauberes Locking

ChatGPT
Hier eine grobe Geschwindigkeits-Gegenüberstellung (Erfahrungswerte aus typischen DBF-Workloads). Annahmen: 1 Gbit LAN, 0.3–1.0 ms RTT; WAN ca. 20–40 ms RTT. Socket-Service arbeitet lokal auf D:\… und sendet nur kompakte Antworten.



Warum dieser Unterschied?

SMB: jede Klein-Operation erzeugt mehrere Roundtrips (Open/Read/Lock/Meta), Lock-Verhandlungen gehen übers Netz, AV/Redirector/Oplocks dazwischen.

Socket: ein Prozess hält die DBFs lokal offen, aggregiert Requests, führt Locking im Kernel lokal aus, überträgt nur Ergebnisdaten.

Mini-Benchmark-Ideen (realistisch, schnell messbar)

Random seek batch: 1.000 zufällige RecNos → DbGoTo() + FieldGet(); Zeit messen.

Bulk update: 10k Records RLOCK()->FieldPut()->DBCOMMIT(); Zeit messen.

Contention: 2 Clients, einer hält RLOCK-Bursts; anderer misst mittlere Wartezeit/Retry.

Tipp: messt je 3× und nehmt den Median. Auf WAN/ VPN steigen die Faktoren drastisch (häufig >20×), weil der Socket-Service RTT-Kosten eliminiert.



im Socket-Ansatz braucht das Senden der Antwort natürlich Zeit. Aber der Unterschied ist:

Bei SMB erzeugt jede Kleinoperation (Seek, Skip, RLock …) mehrere Roundtrips (Kernel ↔ Redirector ↔ Netzwerk ↔ Server ↔ NTFS). Oft 2–3 Pakete pro Operation.

Beim Socket-Microservice hast du einen Roundtrip pro Anfrage (Request → Service, Response zurück). Das Ergebnis (z. B. ein Record als JSON) muss übertragen werden – das kostet auch Zeit, ist aber minimal im Vergleich.

Konkrete Größenordnung

Antwortgröße:

Ein einzelner DBF-Record (z. B. 200 Bytes als JSON) → über 1 Gbit-LAN < 0.1 ms reine Übertragungszeit.

Selbst 10k Records (~2 MB JSON) → ca. 20 ms.

SMB-Overhead:

1.000 Random Seeks = 1.000× SMB-Roundtrips. Bei 0.5 ms RTT → allein 0.5 s Netzzeit, plus Redirector/Server-Verarbeitung.

Die Netzzeit für die Antwort ist im Benchmark also eingerechnet. In meinen Faktoren oben sind die Socket-Zeiten bereits inklusive Senden/Empfangen.

Zusammenfassung

Socket-Service: Netzzeit ≈ reine Payload (Record/Batch), 1 Roundtrip.

SMB: Netzzeit ≈ viele Roundtrips pro Record, auch für Metadaten + Locks.

Antwortsenden kostet natürlich etwas, aber der Overhead ist im Vergleich winzig.