NetCom7
1.0.0
Les communications les plus rapides possibles.
Il s'agit de la version 7.2 du package Netcom. Dans cette version, le package Netcom est désormais multiplateforme! Vous pouvez compiler vos applications sous toutes les plates-formes de FiremonKey!
Cet ensemble de composants est la mise en œuvre la plus rapide possible des communications de socket, dans n'importe quelle langue; Il s'agit d'un code extrêmement optimisé sur les prises TCP / IP. Oubliez l'utilisation d'un thread par connexion: avec cette suite, vous pouvez avoir autant de connexions simultanées à votre serveur que vous le souhaitez. Les threads sont utilisés par demande et non par connexion, et sont maintenus dans une classe de pool de threads très rapide.
L'implémentation commence par TNCTCPSServer et TNCTCPClient qui implémente les communications de base de socket. Vous pouvez utiliser TNCTCPCLIENT et TNCTCPSServer si tout ce que vous voulez est d'implémenter des commandes de socket standard (mais très rapides).
En plus des prises TCP / IP, un protocole léger est implémenté pour pouvoir emballer et déballer les tampons (TCP / IP simple est en streaming et n'a pas de notion de tampon bien défini). L'ensemble des composants implémentant cette fonctionnalité est tncServersource et tncclientSource. Ces deux composants implémentent un Execcommand (ACMD, ADATA) qui déclenche un événement OnHandleCommand de l'autre côté (un client peut exécuter le serveur sur un serveur, ou un serveur peut exécuter le COMMAND à n'importe quel client). EXECCOMAND peut être bloqué ou non bloquant (asynchronisé) selon la façon dont vous définissez son paramètre ArequireSResult. Si vous utilisez le comportement de blocage, le composant gère toujours les demandes entrantes de ses pairs. Par exemple, un ClivitySource pourrait attendre un Execcommand vers le serveur, mais en attendant, il peut servir les demandes de commandement du serveur!
Senario simple: serveur:
- 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.
Client:
- 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).
Cet ensemble de composants promet une vitesse inégalée et ce n'est pas seulement en mots:
Un test de synchronisation simple avec la démo Netcomvsindy donne les résultats suivants:
À partir de l'unité de base, NCSOCKETS.PAS, vous verrez que l'implémentation ne souffre pas de code Slack, c'est plutôt immédiat. La convention d'appel en ligne a été utilisée partout appropriée. Les fonctions principales ont été testées et optimisées en surveillant les performances via le calendrier des grandes boucles et l'inspection de l'assemblage pour extraire chaque dernière performance.
La plus grande différence dans le gain de vitesse est due à l'architecture. Contrairement à la plupart des prises typiques:
Cet ensemble de sockets n'appartenait ni n'utilise un thread par connexion.
Cela signifie que vous pouvez avoir autant de connexions en direct que vous le souhaitez et que vous ne verrez aucune différence de performance! Une piscine de fil attend juste toutes les demandes; Si un fil devait être créé par demande ou par connexion, la vitesse en souffrirait beaucoup, car la création d'un fil est assez lourde en termes de temps. Si le nombre de demandes par seconde ne peut pas être géré par le pool de threads, le pool de threads atteint une taille définie maximale, et si elle ne peut toujours pas faire face, le client attend simplement que le serveur obtienne un thread prêt à traiter sa demande.
Une attention particulière a également été accordée aux problèmes de connexion. Par exemple, les déconnexions sont ramassées immédiatement, et si une ligne est si mauvaise que la déconnexion ne peut pas être ramassée, elle s'attaque à cela par un paquet Keep Alive par lequel il apprend à connaître l'état réel. Il existe une propriété de reconnexion et une propriété Keepalive. Lorsqu'un client est déconnecté, pour une raison quelconque, il essaie de se reconnecter de manière transparente et sans affecter les performances de l'application principale. De cette façon, vous n'avez pas à vous soucier de garder vos clients connectés.
La compression et le cryptage sont également standard avec ces composants sans bibliothèques supplémentaires nécessaires. Bien sûr, vous pouvez utiliser votre propre compression ou chiffrement si vous préférez, mais il est plutôt pratique d'avoir juste une propriété que vous pouvez définir sur le composant.
Cet ensemble de composants peut également faire face aux données de déchets qui leur sont lancées, elles ont été utilisées et testées dans d'énormes projets à l'échelle du pays où toutes sortes d'attaques peuvent être vues.
L'effort qu'un programmeur doit faire pour utiliser ces composants est minime par rapport à d'autres cadres. Veuillez vous référer aux démos pour mieux comprendre comment utiliser ces composants.
Écrit par Bill Anastasios Demos. Un merci spécial à Daniel Mauric, Tommi Prami, Roland Bengtsson pour les tests et suggestions approfondis. Merci beaucoup!
Vasdemos [at] yahoo [dot] co [dot] uk
** Règles Delphi **
