Skalierbarkeit und binäre Daten bei Indys

[Schwedenbitter]

Hallo,

falls diese Frage schon gestellt/beantwortet wurde, würde ich mich über Links freuen:

Kann mir jemand sagen, ob die Indys (z.B. TIdTCPServer/TIdTCPClient) grundsätzlich geeignet sind, eine leistungsfähige Server/Client-Anwendung zu bauen?
Konkret geht es mir dabei um die Fragen der Skalierung von Hause aus und die Übertragung von Binärdaten anstelle von Text.

Ich habe eine entsprechende Anwendung, die auf dieser Anleitung basiert. Eine geplante Neuentwicklung soll/muss am Ende aber unter Linux/wine laufen. Leider ist aber in den TServerSocket/TClientSocket die VCL derart fest verankert, dass das nicht ohne größere Klimmzüge möglich ist. Zudem wurde von Narses für die Skalierbarkeit (umständlich) ein QoS eingebaut. Aktuell läuft das ganze in einer VM mit Windows. Und die soll - so der Plan - wegrationalisiert werden. Dieser etwas ältere Beitrag bringt mich nicht wirklich weiter und ich habe die Hoffnung, dass gute 10 Jahre später auch die Indys weiterentwickelt wurden. Und die von mir gefundene evtl. Alternative ICS basiert wiederum auf der VCL und wäre damit für meinen Zweck ebenfalls nicht einsetzbar.

Gruß und Dank, Alex

[Bernhard Geyer]

Indy ... Hmmmmm.
Wenn ich mir so da die Homepage ansehe (http://www.indyproject.org/index.de.aspx) so würde ich in 2018 nichts mehr mit diesen Anfangen.
Seit ein paar Versionen ist auch Indy nicht mehr die #1 Bibliothek für Netzwerkaufgaben. Hier wurde in Delphi eine neue Implementierung durchgeführt die auch unter anderen Plattformen läuft.
Also wenn du schon mit Delphi und Linux liebäugelst, sollte es schon ein richtige Linux-Anwendung werden und nicht nur eine WINE-Lösung.
Leider wirst du dann aber (für die ersten Jahre?) eine Enterprice-Version benötigen.

Aber schau dir aber auch wenn du schon Windows-Fremdgehst auch mal https://fmxlinux.com/ an.

[Zacherl]

Gut skalierbar auf Windows und Linux (würde hier definitiv auch kein WINE empfehlen): Boost ASIO (C++).

Für Delphi kenne ich leider keine Lib, die auch nur annähernd so gut ist. Großes Manko der Indys unter Windows ist beispielsweise der fehlende Support für IOCP Server. Unter Unix gibt es da vergleichbare Funktionalität (ebenfalls nicht in der Standard Socket Spezifikation). Auch hier wage ich zu bezweifeln, dass die Indys das implementieren.

Allerdings sollte man Skalierbarkeit etwas näher spezifizieren:

1. Soll die Anwendung über mehrere PCs/Server verteilt laufen?
2. Erwartest du eine riesige Menge an gleichzeitig verbundenen Clients?
3. ... etc?

Trifft zum Beispiel Punkt 2 nicht zu, dann solltest du auch ohne IOCP und co. keine Probleme haben.

[mjustin]

Clientseitig ist WinHTTP (die "neue" Netzwerkbibliothek, die Windows Funktionalität kapselt) eine Verbesserung gegenüber WinINet, es ist performanter, und kann auch auf Windows Server Betriebssystemen eingesetzt werden.

Wie der Name allerdings schon sagt, geht es dabei um Client/Server Anwendungen die über HTTP kommunizieren. Andere oder selbst definierte Protokolle lassen sich damit nicht verwenden. Da HTTP aber auch in der Lage ist Binärdaten zu übertragen, ist HTTP nicht 'schlechter', solange man Client und Serverseite kontrolliert.

WinHTTP ist allerdings eine reine Client-Implementierung. Einen HTTP Server würde man daher weiterhin anders, zum Beispiel mit IIS, implementieren müssen.

Indy unter Linux
Bei der Entwicklung des Indy-basierten Daraja HTTP Frameworks habe ich auch Tests unter Linux durchgeführt, die Leistung der Indy TIdHTTPServer Komponente war damals - vor ca. drei Jahren - deutlich schwächer als unter Windows. Woran das im Detail lag habe ich damals nicht weiter untersucht. (Unter Linux wurde die Anwendung mit Free Pascal erstellt, unter Windows mit Delphi 2009)

[Schwedenbitter]

Danke für Eure zahlreichen und ausführlichen Antworten. :dp: Mit so viel Power hätte ich nicht gerechnet!

Mein Problem besteht darin, dass die Clients alle auf Windows 10 basieren, weil Software im Einsatz ist, die nur unter Windows läuft. Selbst große Hersteller wie Olympus (Digitale Diktate), Brother, Fujitsu (Scanner) usw. unterstützen Linux nicht wirklich. Die Server wiederum laufen auf Basis von Linux/Samba.

Bzgl. der Skalierbarkeit war die Nachfrage schon richtig. Es geht mir in der Tat darum, dass ich heute nicht weiß, wie viel Clients es werden könnten. Der Traffic sollte sich in Grenzen halten, da es im wesentlichen nur um Steuerdaten geht. Den Einwurf mit HTTP muss ich mir mal genauer ansehen.

Ich hatte die Indys ins Auge gefasst, weil ich dort schon angefangen hatte, einen Konsolenserver zu basteln, der mit wine läuft. Bevor ich aber weiter alles implemetiere und zig Stunden investiere, wollte ich eben mal nachfragen. Und die hier geäußerten Bedenken zeigen, dass das richtig war!
Ungeachtet dessen schaue ich mir gerade doch mal ICS an. Bei den Demos fehlt aber leider der BinTcpSrv, so dass ich die betreffende Demo mit den Binärdaten nicht testen kann.

[Zacherl]

Zitat:

Zitat von Schwedenbitter (Beitrag 1395739)

Bzgl. der Skalierbarkeit war die Nachfrage schon richtig. Es geht mir in der Tat darum, dass ich heute nicht weiß, wie viel Clients es werden könnten. Der Traffic sollte sich in Grenzen halten, da es im wesentlichen nur um Steuerdaten geht.

Schwer einzuschätzen. Wenn sich der Traffic UND der Aufwand (CPU, IO, etc.) zum Vorbereiten der Daten in Grenzen hält, könntest du - selbst bei vielen konkurrierenden Clients - auch mit einem normalen (nicht-threaded) Server davonkommen. Generell ist bei vielen Clients aber ein IOCP basierter Server auf jeden Fall mit Abstand die beste Möglichkeit unter Windows. Im MSDN hatte ich hierzu auch irgendwann mal ein rein auf der Windows API basierendes Beispiel gesehen, welches nicht wirklich komplex war (vielleicht kommst du also ganz ohne Fremdkomponenten weg?). Wie die Performance vom IOCP Ansatz aussieht, wenn das über WINE emuliert wird, kann ich dir allerdings auch nicht sagen.

Was du auf Clientseite verwendest ist im Grunde ziemlich egal, behaupte ich einfach mal.