Utilisez HttpListener pour un serveur Web de calibre de production?

Est-il réaliste d'utiliser le HttpListener de classe C# .Net comme base pour un serveur web de calibre de production?Utilisez HttpListener pour un serveur Web de calibre de production?

Le service Web http que je dois héberger ne contient aucun fichier .aspx ou statique. Toutes les réponses http sont dynamiques et générées dans le code C# qui est invoqué via quelques instructions switch qui inspectent un format d'URL reposant. Je pense que IIS est vraiment un wrapper en mode utilisateur autour du module noyau HTTP-SYS de Windows o/s qui gère tout le réseau lourd, tout comme HttpListener.

J'ai déjà un serveur web multithread basique qui est excellent pour le développement car il démarre en mode debug dans une instance, maintenant je pense que j'ai besoin de l'overi de IIS pour la production. Une empreinte de mémoire faible est une autre attraction.

Source

2009-08-13 Anonymous

BTW, il est la classe .NET 'HttpListener', et non la "classe C# .NET 'HttpListener'". Tout dans .NET peut être utilisé par toutes les langues, pas seulement C#. –

@John Saunders - J'essayais de préciser que ma question ne portait pas sur une classe Java du même nom, évidemment j'ai essayé trop dur. –

Je ne voudrais pas utiliser HttpListener, ce n'est pas le meilleur wrapper pour httpapi.dll, vous pouvez écrire votre propre enveloppe, ou si vous êtes vraiment fou, vous pouvez en construire un à partir de TcpListener .. quelqu'un qui travaille déjà sur cela: http: // webserver.codeplex.com – meandmycode

Vous avez deux choix sérieux ici. Et non, coder votre propre serveur Web avec HttpListener n'est pas productif.

1) Utiliser IIS. Il a une tonne de fonctionnalités pour la sécurité, la performance, et peut-être plus important encore, que vous auriez à vous réinventer. Comme l'administration à distance, la journalisation, la sécurité Windows intégrée, etc.

2) Utilisez WCF et créez un ServiceHost pour héberger vos fichiers. Ensuite, vous devrez mettre en place vos propres services et trouver un moyen de gérer leur durée de vie. Vous pouvez le faire, mais encore une fois, si vous parlez des appels Web RESTFul, IIS est vraiment la voie à suivre.

Rouler manuellement le vôtre doit être évité. IIS a beaucoup changé au cours des 10 dernières années. Ce n'est en aucun cas un grand serveur monolithique. Ils ont modularisé à peu près tout, en particulier dans Windows 2008, de sorte que vous obtenez un système allégé et rapide.

Source

2009-08-13 10:05:29

@Dave Markle - Merci, j'ai besoin de lire sur les améliorations IIS, mes connaissances bloquées à Windows 2003. Lean et rapide est ce dont j'ai besoin. –

@Dave Markle - Pas d'administrateur distant = un bon trou de sécurité de configuration. Pas de journalisation = pas de problème, avec les services Web dynamiques, une grande partie de la nature de la requête est enterrée dans les données de publication, de sorte que les journaux n'exposent pas beaucoup pour les diagnostics. Pas de sécurité intégrée = bien, n'en avez pas besoin donc une chose de moins à mal configurer. –

Vous jugez selon les normes de Windows Server 2003. 2008-2003 = 5 ans de différence. La journalisation est bien meilleure, ne se limite pas aux lignes uniques dans le journal IIS et inclut la journalisation détaillée des demandes échouées. –

Si vous l'écrivez, alors vous devrez le maintenir. Microsoft a déjà écrit un serveur Web - vous devriez l'utiliser.

Source

2009-08-13 09:58:37

La consommation de mémoire est une bonne raison de ne pas utiliser IIS. La dernière fois que je l'ai utilisé en colère, nous devions activer le commutateur 3GB pour donner à IIS plus de marge de mémoire sur 1.7Gb. Faites les calculs pour l'hébergement sur une plate-forme cloud et vous verrez le problème $$$. –

Je vous suggère fortement d'essayer IIS 7 et de voir si cela pose toujours un problème. Cela peut aussi être dû à l'application spécifique, et non à IIS. –

@JS "Je vous suggère fortement d'essayer IIS 7 et de voir si c'est toujours un problème." Ok va faire, je suis sur BizSpark maintenant afin que je puisse lancer quelques outils de test MS pour un test de mémoire. Un truc, la plate-forme cloud Amazon est bloquée sur Windows 2003 pour le moment ... ho hmm. –

Eh bien, comme il a été dit - essayez d'utiliser IIS au début. HttpListener n'est pas mauvais du tout - c'est le serveur d'écoute géré le plus rapide que vous pouvez avoir maintenant (plus rapide que TcpListener et plus rapide que la classe Socket). Et c'est en fait le même noyau qu'avec IIS. Mais IIS a beaucoup plus de choses. Je ne peux pas dire que IIS est monolithe - l'utilisation de l'hébergement a montré que la stabilité et la gestion de Win2008 ont empiré. Mais votre solution faite à la main peut être bien pire. Et n'oubliez pas non plus - http.sys beaucoup plus personnalisable que HttpListener. C'est à dire. vous ne pouvez pas faire de streaming avec HttpListener, mais vous pouvez le faire avec http.sys - Question about HttpListener streaming

Mais si vous aurez assez de puissance en tant que développeur - vous pouvez essayer d'écrire propre wrapper http.sys et c'est mieux approche de l'écriture propre serveur web dans Windows.

Source

2009-09-03 16:18:24 Mash

Avez-vous une URL qui détaille la perte de stabilité et de gestion de Win2008? –

Déchets, roulez le vôtre. L'architecture le permet. Sachez cependant qu'il y a des comportements étranges dans la classe. Le fermer quelques fois dans un service de NT le fait flakey comme sac de pâtisseries.

Si vous l'exécutez sur la console, aucun problème, exécutez-le asynchrone et tout devrait bien, cependant, commencer et arrêter la chose sacrément. C'est une question différente que je suis actuellement aux prises avec aucune erreur étant produite par les classes hermétiquement scellées de Microsoft.

Je me sens python venir avec un petit filet de cherrypy

Source

2009-12-02 11:14:19 iestyn

-1: pas autant une réponse qu'une diatribe. –

Utilisez HttpListener pour un serveur Web de calibre de production?

Répondre

Questions connexes