Je sors les options architecturales pour un projet qui rendra des mises à jour en direct (telles que Facebook) des activités utilisateur - Logins, photos, etc. Deux composants d'interface utilisateur principale de ceci sont une zone de défilement automatique des nouvelles notifications seront énumérés (photos, etc.) et une barre d'outils qui mettra à jour avec des éléments tels que les chiffres de messages mis à jour, etc.
Les prétendants pour cela sont les technologies de Jabber / Comet / XMPP et WebSocket.
Camp Comet:
WebSockets Camp:
Étant donné que cette infrastructure existante est une pile Microsoft, je préférerais ne pas introduire de serveurs Java dans le mélange. En disant cela, il laisse (très attrayant) WebSync (comète) et superwebsocket (Webockets). Cependant, l'intégration DLL de Pokein est assez transparente dans un projet .NET aussi.
Y a-t-il des initiatives de Websockets plus réelles de niveau de production pour .NET? Est-il trop tôt pour adopter des webockets sur une pile Microsoft et devrais-je aller en faveur de quelque chose comme Kazing?
J'attends toujours un rapport sur les types de navigateur et les versions du navigateur de nos utilisateurs actuels (vérification de la compatibilité HTML5). Je soupçonne que ce nombre sera faible (base d'utilisateurs plus anciens). Si tel est le cas, l'option Comet serait le gagnant.
Quelles sont d'autres choses à considérer?
En regardant certaines des initiatives .NET telles que des sockets.io et d'autres, je pense que cela pourrait être trop à sa balance encore, pour appliquer à un système de production à grande échelle.
Puis-je obtenir des commentaires de quiconque a utilisé l'une des technologies et des produits énumérés ci-dessus?
merci.
Je chasse toujours de bons serveurs Websocket fiables sur un niveau de production. J'ai ajouté Xsockets et Signalr au camp WebSockets après les avoir récemment trouvés. Hoewver, il reste encore deux prétendants principaux à ce moment-là. Cela pourrait être juste à cause du fait qu'ils disposent d'équipes de marketing étonnamment de grandes grandes équipes de marketing, disponibles pour les développeurs - API et vidéos. Beaucoup d'autres implémentations semblent toujours être dans des phases de nouvelle naissance, où des exemples sont donnés de connectivité avec seulement quelques clients. Bien que cela démontre la technologie, ces démonstrations ne sont pas sauvegardées avec des données importantes de la charge utile / de la capacité de charge. Kaazing et Lightectreamer répondent aux exigences ci-dessous.
Xsockets a de bons exemples, mais encore une fois, il manque des métriques de production réelles.
Il ne semble pas que SignalR n'a pas encore été testé dans un véritable environnement de production. Une solution d'échelle est en développement mais n'apparaît pas encore stable. Hâte de voir comment ce projet fait à l'avenir.
Les exigences principales sont:
5 Réponses :
Le gain de performance que vous obtenez avec WebSockets sur les solutions de comètes traditionnelles est dans la plage de grandeurs multiples; Je vais certainement aller avec le camp WebSockets. ici La comparaison du vendeur de la comète traditionnelle de Les deux technologies, mesurant un facteur de plus de 150x en faveur de Webockets (700 ms contre 3 ms à 50 000 utilisateurs).
Quelques notes sur le nom de Kaazing:
Kaazing est entièrement pris en charge sur Microsoft en tant que plate-forme de serveur. De plus, comme vous le souhaitez, Kaazing prend en charge une variété de bibliothèques et de technologies clientes, y compris la pile Microsoft: .NET et Silverlight, utilisée avec bonheur par nombre de nos clients.
De plus, Kaazing propose des protocoles d'entreprise riches sur des webkets, vous permettant de "parler" XMPP directement dans votre code client.
À propos de la prise en charge du navigateur: Kaazing fournit une émulation de Websocket exceptionnellement bonne, en prenant en charge tous les navigateurs, y compris les anciens navigateurs, tout le chemin du retour à IE6. Vous pouvez en savoir plus à ce sujet dans Ce blog post .
Concernant la maturité: la passerelle Kaazing Webocket est expédiée depuis 2009 et dispose d'un grand nombre de clients de profil élevé dans de nombreuses industries, y compris de la finance, de la logistique, du jeu et de la vente au détail; Plate-forme très mature avec support supérieur en cran.
Peter, je lis aussi un autre de vos commentaires ( Stackoverflow. com / questions / 9167564 / ... ), la possibilité de sélectionner automatiquement la couche de transport appropriée est importante (navigateurs hérités), ce que je suppose que vous faites allusion à «... vous permettant de« parler »XMPP ... ". Quelques très bons points. Connaissez-vous des implémentations de serveur basées sur .NET à comparer? :)
Désolé, je ne connais pas les serveurs Websocket .NET.
Sur XMPP: Nous soutenons la messagerie XMPP sur des sketkets. Donc, au lieu de vous développer contre les API de sites Web relativement basse de niveau, vous pouvez utiliser des protocoles / API de messagerie de niveau de niveau supérieur, assis sur des skockets natives (ou dans le cas de navigateurs plus âgés, des sites Web.
Peter, il est clair pour moi comment utiliser LightStreamer dans un environnement complètement .NET. Ce n'est pas du tout clair comment, du côté serveur, d'intégrer Kaazing.
Jonesome - Kaazing prend en charge diverses technologies clientes différentes, .NET en fait partie. Pouvez-vous me tirer un email pour que je puisse mieux comprendre ce que vous recherchez? Peter Dot Moskovits à Kaazing Dot Com
Pour des raisons inclus. ceux déjà énoncés ci-dessus, j'irais avec des webockets.
Si vous allez avec WebSockets, vous pouvez également envisager des standards AutoBahn, un serveur WS hautes performances prenant en charge Windows dans lequel elle s'exécute au-dessus des ports d'achèvement des IOCP (E / S).
Ce dernier est important si vous souhaitez accumuler des numéros de connexion importants (centaines de milliers).
Clause de non-responsabilité: je suis auteur de WebSockets Autobahn. La technologie de base est OSS. Nous préparons actuellement une offre commerciale, un hub de messagerie en temps réel fourni en tant qu'appareil virtuel (exécuté sur VMware / Sphere) .. Complètement intégré, appareil durci. Ce dernier vous permet également de faire pression sur la notification via le hub à l'aide d'un ancien http / post plain. Il dispose d'une API de repos qui vous permet de dépêcher des clients connectés via WS. Si vous êtes intéressé par des tests de bêta privé, contactez-moi ..
Il semble que vous choisissiez les implémentations de comètes les plus stables disponibles. Tous ont l'air stable, capables d'organiser dix à centaines de milliers d'utilisateurs par nœud et plus.
Alors, que pourrait être la prochaine? Par exemple, Pokein va héberger tous les aspects d'une application Web sur visualjs.net ; Video-1 , Video-2
Cela montre également les capacités intégrées de cette bibliothèque et des variétés que vous pouvez faire ..
En outre, la dernière version prend en charge la sérialisation de base64 pour les messages entre un client et un serveur, pas plus de messages JSON nus sur les packages réseau.
Pourquoi est-ce qu'il y a tant de vidéos "pédagogiques" ou "démo", sans narration? Ajouter une piste d'enseignement audio à ceux-ci serait utile!
WebSync v4 utilise des webockets en plus de la retombée à l'interrogation de l'interrogation de longue date / rappel au besoin. Les Webockets dans WebSync sont également des ports HTTP standard. Il n'y aura donc aucun problème avec des routeurs / fashrewalls / etc.
sur un système "normal", vous devez voir ~ 20k simultanément (par nœud) et ~ 100k messages / sec. Ce sont les très chiffres bruts cependant, car cela dépend considérablement de votre système et des types de messages que vous envoyez, etc. Nous avons considéré aussi élevé que 50k utilisateurs (par nœud) et (dans un test différent) 300k messages / seconde.
(Disclaimer: Je travaille pour la montagne gelée)
Signalr gagne.
Maintenant que le produit a mûri, il a été une brise à mettre en œuvre. Essentiellement, il offre ce que ces paquets de $ et dollar de dollars Everal vous coûtent, mais n'ont pas les dollars de marketing pour présenter certaines implémentations vraiment cool.
Dans une perspective technique, vous pouvez accomplir les mêmes choses avec Signalr. Si vos gars de technologie suggèrent autrement, ils ne savent probablement pas comment mettre en œuvre Signalr dans un environnement équilibré de la charge (ou même seul).
Et vous (et que SignalR) ne connaissez pas les sous-protocoles de WebSockets.
Je serais vraiment intéressé d'entendre les expériences de quiconque avec Signalr. Merci.
Elhaix, qu'est-ce que tu as fini avec et que suggéreriez-vous à quelqu'un qui pose cette question aujourd'hui?