NetCom7
1.0.0
Die schnellste Kommunikation möglich.
Dies ist Version 7.2 des NETCOM -Pakets. In dieser Version ist das NetCom-Paket jetzt mehrfach Plattform! Sie können Ihre Apps unter allen Plattformen in Fironemonkey kompilieren!
Dieser Satz von Komponenten ist die schnellstmögliche Implementierung der Socket -Kommunikation in jeder Sprache. Dies ist ein extrem optimierter Code für TCP/IP -Sockets. Vergessen Sie die Verwendung eines Threads pro Verbindung: Mit dieser Suite können Sie so viele gleichzeitige Verbindungen zu Ihrem Server haben, wie Sie möchten. Threads werden pro Anforderung und nicht pro Verbindung verwendet und in einer sehr schnellen Thread -Pool -Klasse gepflegt.
Die Implementierung beginnt mit TNCTCpServer und TNCTCPClient, was die grundlegende Socket -Kommunikation implementiert. Sie können TNCTCPClient und TNCTCPServer verwenden, wenn Sie nur Standard -Socket -Comms (aber sehr schnell) implementieren möchten.
Neben den TCP/IP -Sockets wird ein leichtes Protokoll implementiert, um Puffer zu packen und auszupacken (einfaches TCP/IP streaming und keine Vorstellung von einem gut definierten Puffer). Der Satz von Komponenten, die diese Funktionalität implementieren, ist TNCServersource und TNCClientSource. Beide Komponenten implementieren ein ExecCommand (ACMD, ADATA), das ein On -HandleCommand -Ereignis auf der anderen Seite auslöst (ein Client kann zu einem Server führen, oder ein Server kann zu einem beliebigen Client führen). ExecCommand kann abhängig davon, wie Sie seinen Parameter für die Ausführung festlegen, blockieren oder nicht blockieren (ASync). Wenn Sie das Blockierungsverhalten verwenden, wird die Komponente immer noch eingehende Anforderungen von Peer (en) behandelt. Zum Beispiel könnte eine Clientsource auf einen ExecCommand zum Server warten, aber während des Wartens kann sie Execcommand -Anforderungen vom Server stellt!
Einfacher Senario: Server:
- You put a TncServerSource on your form.
If you want you can change the port it is listening to via the
Port property.
- You implement an OnHandleCommand event handler and,
depending on aCmd parameter (integer), you respond the result of
the command via setting the Result of the OnHandleCommand to
anything you like (TBytes). If an exception is raised while in
HandleCommand, it is trapped, packed, transfered accross to the
calling peer, and raised at the peer's issued ExecCommand.
This way exceptions can be handled as if they were raised locally.
- You set the Active property to true. Your server is ready.
Kunde:
- You put a TncClientSource on your form.
You can set Host and Port to whatever you want.
- You set Active property to true.
Your client is now connected to the server.
- You call ExecCommand (on your TncClientSource), with any
command number and data that you like. This will send your
command and data over to the server, call its OnHandleCommand,
pack the response, and return it as a result to your ExecCommand.
- ExecCommand is blocking (if aRequiresResult parameter is set to true),
but only for the current command issued.
The TncClientSource's OnHandleCommand still executes, so,
while waiting for a command to return, your client socket may be
processing requests from your server (a server can also
ExecCommand to a client).
- If you have forgotten to set Active to true and call ExecCommand,
the TncClientSource will first try to connect, so you can ommit
setting this property. It will also try to connect if it knows
it has been disconnected (and the Reconnect property is set to true).
Dieser Satz von Komponenten verspricht eine unvergleichliche Geschwindigkeit und das ist nicht nur in Worten:
Ein einfacher Timing -Test mit der NetComvSindy -Demo liefert die folgenden Ergebnisse:
Beginnend mit der Basiseinheit ncsockets.pas werden Sie feststellen, dass die Implementierung nicht unter Slack -Code leidet, sondern eher unmittelbar. Die Inline -Calling -Konvention wurde verwendet, wo immer er als angemessen erachtet wird. Die Kernfunktionen wurden getestet und optimiert, indem die Leistung durch das Timing großer Schleifen und die Montageprüfung überwacht wurde, um jedes letzte Stück Leistung herauszuholen.
Der größte Unterschied im Geschwindigkeitsgewinn ist jedoch auf die Architektur zurückzuführen. Im Gegensatz zu den meisten typischen Steckdosen:
Dieser Satz von Steckdosen laichen weder einen Thread pro Verbindung.
Dies bedeutet , dass Sie so viele lebende Verbindungen haben können, wie Sie möchten, und Sie werden keinen Unterschied in der Leistung sehen! Ein Thread -Pool wartet nur auf Anfragen. Wenn ein Thread pro Anforderung oder pro Verbindung erstellt werden würde, würde die Geschwindigkeit viel leiden, da das Erstellen eines Threads ziemlich schwer ist. Wenn die Anzahl der Anforderungen pro Sekunde nicht vom Thread -Pool behandelt werden kann, wird der Thread -Pool auf eine maximal definierte Größe wächst. Wenn er immer noch nicht fertig werden kann, wartet der Client nur, bis der Server einen fertigen Thread erhält, um seine Anforderung zu bearbeiten.
Besonders Aufmerksamkeit wurde auch den Verbindungsproblemen geschenkt. Zum Beispiel werden die Trennung sofort abgeholt, und wenn eine Linie so schlimm ist, dass die Trennung nicht abgeholt werden kann, wird dies durch ein Keep Alive -Paket angepasst, mit dem er den tatsächlichen Status kennen. Es gibt eine Wiederverbindung und ein Keepalive -Eigentum. Wenn ein Kunde aus irgendeinem Grund getrennt wird, versucht er, sich transparent und ohne die Leistung der Hauptanwendung zu beeinträchtigen. Auf diese Weise müssen Sie sich keine Sorgen machen, dass Ihre Kunden in Verbindung stehen.
Komprimierung und Verschlüsselung sind auch Standard mit diesen Komponenten ohne zusätzliche Bibliotheken. Natürlich können Sie Ihre eigene Komprimierung oder Verschlüsselung verwenden, wenn Sie es vorziehen, aber es ist eher praktisch, nur eine Eigenschaft zu haben, die Sie auf der Komponente festlegen können.
Diese Komponenten können sich auch mit Mülldaten befassen, die auf sie geworfen wurden. Sie wurden in riesigen, landesweiten Projekten verwendet und getestet, bei denen alle möglichen Angriffe zu sehen sind.
Der Aufwand, den ein Programmierer unternehmen muss, um diese Komponenten zu verwenden, ist im Vergleich zu anderen Frameworks minimal. In den Demos finden Sie ein besseres Verständnis für die Verwendung dieser Komponenten.
Geschrieben von Bill Anastasios Demos. Besonderer Dank geht an Daniel Mauric, Tommi Prami, Roland Bengtsson für die umfangreichen Tests und Vorschläge. Vielen Dank!
Vasdemos [at] yahoo [dot] co [dot] uk
** Delphi Regeln **
