Composant Delphi Server Socket

Question

Nous avons une application C/S entièrement écrite en Delphi (client et serveur ou middleware si vous le souhaitez) Pour la partie client, nous utilisons Indy. Pour le serveur, nous utilisons DXSock.

Depuis que DXSock est mort pendant un moment, nous étudions des alternatives pour la partie serveur.

Je veux entendre quelques commentaires sur le meilleur composant alternatif Server Socket pour Delphi. Le système actuel a généralement des dizaines de connexions permanentes fonctionnant chacune sur son propre thread mais pourrait être des hundreads dans le futur (cela devrait être amélioré si possible).

Answer 1

Si vous souhaitez obtenir les meilleures performances possibles, vous devez utiliser des sockets en mode non bloquant ou en utilisant completion ports. IPWorks est implémenté comme cela, ainsi que iocp. Autant que je sache, Indy ou Synapse ne les implémente pas (au moins officiellement).

Nous avons utilisé des ports d'achèvement et un pool de threads dans notre unité open source SynCrtSock, utilisée dans notre Synopse SQLite3 framework.

Voici quelques références de cette solution, allant de Delphi 6 à Delphi XE. Je ne dis pas cela est le « meilleur élément », mais c'est un travail et un rapide (chaque demande est d'environ 4 Ko de données JSON):

• client Http garder en vie (par exemple une connexion HTTP/1.1 client maintenu en vie pendant les requêtes): premier en 7.87ms, fait en 153.37ms soit 6520/s, en moyenne 153us
• Http client multi-connexion (ie une nouvelle connexion client HTTP/1.0 créée pour chaque requête - celle-ci utilise des ports d'achèvement et un pool de threads): d'abord en 151us, en fait 305.98ms ie 3268/s, moyenne 305us

Pour une vitesse compa Rison, voici les autres protocoles de communication dans notre cadre:

• accès au tuyau nommé: d'abord en 78.67ms, fait en 187.15ms-à-dire 5343/s, moyenne 187us
• messages de fenêtre locale: premier à 148us , fait en 112.90ms-à-dire 8857/s, moyenne 112us
• directe dans l'accès aux processus: premier à 44us, en fait 41.69ms-à-dire 23981/s, moyenne 41us

Nous utilisons le protocole HTTP/1.1 sur TCP/IP, parce que je C'est très peu de surcharge sur TCP/IP, et c'est un protocole bien géré pour les firewalls et autres, et permet à notre framework d'être utilisé par une application AJAX, alors que son but principal est de servir les clients Delphi.À mon humble avis, il n'y a pas de «meilleur composant alternatif de socket serveur pour Delphi», cela dépend quel est le but de votre application serveur. Le goulot d'étranglement principal sera dans le noyau Windows lui-même. Peut-être un accès direct à la HTTP Kernel-Mode Driver (Http.sys) de Windows pourrait aider. Envisagez d'utiliser un serveur optimisé dédié au lieu d'un serveur Delphi, comme lighttpd ou Cherokee en utilisant FastCGI pour gérer les demandes via une application Free Pascal (ou CrossKylix), sous Linux. Je suppose que ce sera la meilleure performance possible.

Answer 2

J'utilise des composants Indy pour le travail côté serveur et le jeu de composants est assez solide (9 ou 10). Mes serveurs ont des millions de connexions par jour sans problèmes.

J'ai utilisé DXSock il y a plusieurs mois. Il optimisait toujours, mais ne semblait jamais le finir. Il semble avoir une autre version.

Si vous souhaitez bénéficier d'une assistance commerciale, je vous recommande IPWorks de nSoftware.