2017-10-17 10 views
-6

J'écris une application de lecture de port TCP/IP dans .Net pour lire les données des périphériques IOT, actuellement il fonctionne comme une application Windows. Je veux en faire un service Windows, y a-t-il une meilleure option? Je veux lire les ports 24/7. Y a-t-il de meilleures options qu'un service Windows?Application de lecture de port dans .Net qui est meilleur service Windows ou application Windows

+2

Si vous voulez en faire un service Windows, alors c'est évidemment la meilleure option pour vous. Il n'y a pas de mesure objective à appliquer ici, certainement pas au niveau de détail que vous avez actuellement fourni. –

+2

Service Windows s'exécutant sous LocalSystem ou NetworkService si des ressources réseau sont nécessaires. Si le volume est élevé ou que le nombre d'appareils est supérieur, en ayant un canal d'intégration de données/message entre les deux, quelque chose comme Kafka pour s'assurer que vous ne perdez pas les données. –

+0

Pour le développement et le débogage de Windows l'application est meilleure, mais pour la version j'irais pour le service de Windows - évidemment si vous êtes bien avec la fenêtre de console dans l'environnement de production l'application de gain est bonne. – jabko87

Répondre

2

Oui, un service Windows serait bien. Je voudrais utiliser une petite bibliothèque appelée TopShelve pour créer une application de service/console. Ensuite, je voudrais ajouter NancyFx pour exposer le service et ses données (ou le lire à partir d'une base de données partagée).

Vous avez également demandé s'il y avait un «meilleur» moyen. Vous pourriez argumenter que l'interrogation de tous les périphériques IoT n'est pas une bonne idée (vous pourriez utiliser trop de ressources). Laissez-les diffuser leur lecture (quand ils le souhaitent) dans une file d'attente de messages (la plupart de ces petits appareils aiment utiliser MQTT). Ensuite, votre application ne doit s'abonner qu'aux files d'attente souhaitées et traiter les données si nécessaire.

7

Si vous voulez être en mesure d'exécuter le programme sans utilisateur connecté, un service Windows est la voie à suivre. Si vous voulez une interface utilisateur graphique, une application normale est plus utile.

En tant que nœud secondaire, vous pouvez modifier une application avec des indicateurs de débogage entre le démarrage en tant que service et le démarrage en tant qu'application. Ajoutez une classe de service à votre application et une autre classe pour votre code personnalisé. Le service appellera également la classe Sample. Ensuite, vous pouvez basculer entre chaque cours de débogage si vous ajoutez un precompiler #if DEBUG dans le Program.cs

public static void Main() 
    { 
#if DEBUG 
     SampleClass sc = new SampleClass(); 
     sc.Start(); 
#else 
     ServiceBase[] servicesToRun = new ServiceBase[] 
     { 
      new SampleService() 
     }; 
     ServiceBase.Run(servicesToRun); 
#endif 
    } 

vous pouvez également ajouter du code pour la sortie qui fonctionne différemment pour chaque génération de type

public static void WriteLog(string message, LogLevel logLevel) 
    { 
#if DEBUG 
      Console.WriteLine(message); 
#else 
      Trace.Write ($"{DateTime.Now:dd.MM.yyyy HH:mm:ss.fff} {message}"); 
#endif 
    } 

Ensuite, si vous démarrez l'application, choisissez entre construire et déboguer. Mais vous pouvez seulement installer le release-build en tant que service de cette façon.

+1

J'aime ce design.Une suggestion est lors de l'exécution en tant que service pour se connecter au [Journal des événements Windows] (https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.eventlog?view=netframework-4.7.1) . Ceci est une pratique assez courante pour les services Windows et peut faciliter le dépannage des services de production. Par exemple, si une exception est détectée, vous pouvez l'écrire en tant qu'erreur dans le fichier 'EventLog' avec la trace de la pile complète [si vous le souhaitez]. – Zer0

0

Je n'ai aucune expérience de l'écriture d'un service dans .NET, et j'ai toujours l'impression qu'il est difficile de déboguer.

Vous avez demandé une "meilleure option", c'est une option alternative mais si elle est meilleure dépendra beaucoup de vos besoins: Donc, en guise d'alternative, avez-vous considéré le planificateur de tâches?

J'ai un certain nombre d'applications de ligne de commande dans .NET que je peux exécuter et déboguer dans Visual Studio et qui sont ensuite appelées par le planificateur de tâches quand elles doivent être exécutées périodiquement. Si vous voulez utiliser le planificateur de tâches, assurez-vous simplement qu'il ne nécessite aucune interaction de l'utilisateur (et pas de gui), mais que les mêmes restrictions s'appliquent au service. Si c'est pour une application en cours d'exécution (la vôtre semble être) alors vous pouvez utiliser le planificateur de tâches pour le mettre en marche, et si vous le souhaitez vous pouvez utiliser le gestionnaire de tâches pour le redémarrer périodiquement s'il n'est pas encore en cours d'exécution.

Les services sont plus appropriés pour certaines choses. Certes, ils sont plus faciles à arrêter que quelque chose qui se déroule hors du planificateur de tâches (car pour le planificateur de tâches, vous devez trouver le processus dans le gestionnaire de tâches pour le tuer).

Il pourrait être utile de considérer pourquoi vous voulez le faire fonctionner comme un service Windows. Si c'est seulement comme un moyen de le mettre en marche lorsque votre machine démarre, une tâche planifiée serait tout aussi bonne. Si c'est parce que vous voulez de l'expérience dans l'écriture d'un service Windows, faites-le comme un service Windows. etc.

1

Il peut y avoir plusieurs raisons de choisir l'une ou l'autre mais voici quelques suggestions qui pourraient vous aider à décider.

vous avez mentionné 24/7 donc le service Windows devrait être votre choix sans question. MAIS vous devrez prendre en compte les éléments suivants

Assurez-vous de mettre toutes vos valeurs configurables dans le fichier de configuration. par exemple port d'écoute, les intervalles ou tout autre chose que vous pourriez vouloir changer sans recompiler/re-déployer, car vous n'aurez pas l'interface utilisateur pour le contrôler.

Vous pouvez également stocker tous ces paramètres dans un fichier json ou xml pour lequel vous pouvez créer une interface utilisateur distincte uniquement pour gérer ce fichier de paramètres, tandis que le service Windows fonctionne uniquement à partir de ces paramètres. Pour aller plus loin, vous pouvez également ajouter du code à votre service Windows en démarrant l'API api web qui répond aux demandes de repos pour manipuler la configuration du service et/ou les actions/commandes que vous souhaitez livrer à votre service Windows. cela permettrait au service Windows de fonctionner en arrière-plan avec ou sans session utilisateur et peut également être contrôlé à partir d'une machine séparée via des appels de repos.

MAIS ce ne sont que quelques idées et combien vous dépend de ce que vous devez faire.

1

Une application est un programme avec lequel vous interagissez sur le bureau.

Le service Microsoft Windows est spécialement conçu pour résoudre le problème du temps de disponibilité 24h/24 et 7j/7 et éviter les applications de formulaires orientées GUI. C# fournit des exemples très pratiques de développement de services Windows. Avec le système d'enregistrement des erreurs, il peut faire partie intégrante de votre solution. Pour que votre service Windows soit compatible avec les débogueurs, vous pouvez le mettre sur

Topshelf technologie.J'ai utilisé dans mon expérience et cela a considérablement réduit le temps de développement/débogage.

-1

Pourquoi reconstruire la roue? Vous pouvez utiliser WinDivert:

permet aux applications en mode utilisateur pour capturer/modifier/paquets réseau de goutte envoyés à/de la pile réseau Windows

et

peut être utilisé pour implémenter des filtres de paquets en mode utilisateur, des renifleurs de paquets, des pare-feu, des NAT, des VPN, des applications de tunnellisation, etc.

Vous pouvez probablement l'utiliser avec C# ou .NET

+0

Il doit «écrire une application de lecture de port TCP/IP dans .Net pour lire les données des périphériques IOT», en cours d'exécution WinDivert permet d'interagir dans le flux réseau TCP/IP en temps réel, il peut également utiliser un filtre personnalisé pour détecter IOT paquet réseau et lire/reconstruire les données relatives lorsqu'il est déclenché ... –