myCSharp.de - DIE C# und .NET Community
Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 
 | Suche | FAQ

» Hauptmenü
myCSharp.de
» Startseite
» Forum
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Suche
» Regeln
» Wie poste ich richtig?
» Forum-FAQ

Mitglieder
» Liste / Suche
» Wer ist wo online?

Ressourcen
» openbook: Visual C#
» openbook: OO
» Microsoft Docs

Team
» Kontakt
» Übersicht
» Wir über uns

» myCSharp.de Diskussionsforum
Du befindest Dich hier: Community-Index » Diskussionsforum » Gemeinschaft » Projekte » MessageCommunicator - Tool zum Testen von TCP-/IP Kommunikation
Letzter Beitrag | Erster ungelesener Beitrag Druckvorschau | Thema zu Favoriten hinzufügen

Antwort erstellen
Zum Ende der Seite springen  

MessageCommunicator - Tool zum Testen von TCP-/IP Kommunikation

 
Autor
Beitrag « Vorheriges Thema | Nächstes Thema »
Roland_K Roland_K ist männlich
myCSharp.de-Mitglied

avatar-4146.jpg


Dabei seit: 15.11.2014
Beiträge: 37
Entwicklungsumgebung: Aktuellstes Visual Studio
Herkunft: Weiden i. d. Opf.


Roland_K ist offline

MessageCommunicator - Tool zum Testen von TCP-/IP Kommunikation

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

GitHub
 github.com/RolandKoenig/MessageCommunicator

Das Projekt
Dieses Projekt ist aus der Idee entstanden, ein Set an Klassen für einen einfachen TCP/IP basierten Nachrichtenaustausch mit den neusten Mitteln aus .Net Core zu machen. An sich nichts Weltbewegendes, es war von Anfang an mehr als Übung gedacht. Mit der Zeit ist das Projekt aber schon etwas gewachsen und eine Cross-Plattform fähige GUI drum herum entstanden. Für den einen oder anderen ist es dadurch sicher ein gutes Testwerkzeug.
Die Konkrete Funktion: In meinem Umfeld habe ich oft damit zu tun, dass mittels einfacher Nachrichten über TCP/IP kommuniziert wird. Die Erkennung von Nachrichten im TCP/IP Datenstrom erfolgt dabei mit Regeln wie „Endekennzeichen“, „Feste Länge“ oder „Längenangabe in der Nachricht“. Der Message Communicator macht genau das, man kann eine oder mehrere Verbindungen definieren und je Verbindung das Nachrichtenformat festlegen. Anschließend kann man bei erfolgreichem Verbindungsaufbau mit der Gegenstelle „chatten“. In Summe ist es als Testprogramm gedacht. Bei den Verbindungen wird folgende Funktionalität unterstützt:
  1. Unterstützung Passiv/Aktiv: Warten auf Verbindungsanfrage von außen auf bestimmten Port / Aufbau einer Verbindung zu einer fremden IP-Adresse und Port
  2. Unterstützung TCP oder UDP: Modus kann einfach in der Konfiguration umgestellt werden.
  3. Einzelne Verbindung: Trifft eine neue Verbindungsanfrage an einem Port ein, so wird die vorherige als ungültig erklärt (gilt für passiven Modus)
  4. Timeouts: Trifft über eine gewisse Zeitspanne keine Nachricht von der Gegenseite ein, so wird die Verbindung automatisch abgebaut und ein neuer Verbindungsaufbau versucht
  5. Flexible Nachrichtenerkennung: Die Logik zur Erkennung einer Nachricht kann flexibel konfiguriert werden. Z. B. Erkennung einer Nachricht auf Basis eines Ende-Kennzeichens oder einer festen Länge.
  6. Automatischer Reconnect: Sobald ein Verbindungsprofil gestartet wurde, kümmert es sich automatisch um den Verbindungsaufbau und um ggf. notwendige reconnects.
Neben der GUI steht die Funktionalität dahinter aber auch in einer Library per Nuget zur Verfügung. In der Readme auf Github sind entsprechend zwei kurze Beispiele.

Technologie
Unabhängig von der reinen Funktion ist das Projekt sicher auch von der Technologie her interessant. Die GUI basiert auf Avalonia und läuft damit auf Windows, Linux und macOS.Wer es nicht kennt: Avalonia ist ein OpenSource-Framework und ähnelt sehr stark WPF. Während der Arbeit an diesem Projekt war ich von der Stabilität und dem Reifegrad des Frameworks sehr überrascht – abgesehen von einigen kleinen Ecken und Kanten natürlich. Als Runtime verwende ich aktuell .Net Core 5.

Download
Das Programm kann man sich direkt von GitHub bei Releases runterladen oder auch über den Windows Store installieren (?? App „Message Communicator“).

Nächste Schritte
Ich selbst habe momentan das meiste eingebaut, was ich brauche. Gerne könnt ihr euch das Projekt bei Interesse anschauen und Rückmeldung geben.

Roland_K hat dieses Bild (verkleinerte Version) angehängt:
2021-01-04_19-33-40.png
Volle Bildgröße

04.01.2021 19:38 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 14.473
Herkunft: BW


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Code sieht schon ganz gut aus; aber einfach aus Feedback-Gründen: Dein Namespace Handling ist mir unklar.
Verstehe die ganzen Verzeichnisse mit Underlindes nicht; steht alles etwas im Gegensatz, wie man Namespaces designed / desginen sollte - zumindest wenn man die C# Guidelines und die "normalen" Open Source Umsetzungen so sieht. Etwas schwer sich da zurecht zu finden als Außenstehender.

Zudem, weil Du es ja als Übung gesehen hast: Serialisierung ist derzeit ein Thema, bei dem immer öfter Source Code Generators sinnvoll eingesetzt werden können.
Beispiel:  https://github.com/RudolfKurka/StructPacker
04.01.2021 20:14 Beiträge des Benutzers | zu Buddylist hinzufügen
Roland_K Roland_K ist männlich
myCSharp.de-Mitglied

avatar-4146.jpg


Dabei seit: 15.11.2014
Beiträge: 37
Entwicklungsumgebung: Aktuellstes Visual Studio
Herkunft: Weiden i. d. Opf.

Themenstarter Thema begonnen von Roland_K

Roland_K ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Danke für dein Feedback

Das mit den Namespaces ist tatsächlich noch eine sehr alte und eigenwillige Angewohnheit, bei der es auch mal an der Zeit wird, sie an den Nagel zu hängen. Die Grundregel ist eigentlich ganz einfach, Ordner mit _ vorne dran zählen nicht als eigener Namespace.
Mal gucken, vielleicht ändere ich das direkt mal in der nächsten Zeit. Ist ja grundsätzlich nicht so wild.

Beim Thema SourceGenerators bin ich ganz bei dir.
Ich verfolge das Thema auch seit  diesem Post im .Net Blog und finde es sehr spannend. Ich sehe dafür auch einige Anwendungsfälle, ganz unabhängig von der Serialisierung.

Bei der Library MessageCommunicator ging es mir zunächst darum, den Code so zu schreiben, damit möglichst wenig allokiert und möglichst selten mit locks gearbeitet wird. Das Thema Cross-Plattform Testtool (mit GUI) kam dann eher so nebenbei rein. Insbesondere deswegen, weil ich von Avalonia sehr positiv überrascht war und weil ich tatsächlich so ein Tool immer wieder mal brauche. Es steckt aber viel Spielerei drin, was gar nicht so dringend notwendig ist. Zum Beispiel verschiedene Themes, automatischer Wechsel zwischen Hell und Dunkel auf Windows, überall Eingabevalidierung, integrierte Markdown-Dokumentation, etc.
Für mich war das in Summe schon sehr spannend, da ich in den letzten 13 Jahren primär auf Windows unterwegs war.
04.01.2021 21:15 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
teebeast teebeast ist männlich
myCSharp.de-Mitglied

Dabei seit: 29.12.2010
Beiträge: 39
Entwicklungsumgebung: Visual Studio 2019
Herkunft: Bayern


teebeast ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Ich habe gesehen, dass Du als Abhängigkeit das NuGet  StringFormatter verwendest. Überlege mal diese Implementierung durch den Standard zu ersetzen. In .NET Core 5 - und auch schon davor - wurde sehr viel an der Performance und dem Speicherbedarf im Framework optimiert. Ich wäre der Meinung, dass es einen Blog-Eintrag vom Microsoft hierzu gäbe, hab ich nur nicht gefunden. Nur den hier:  Performance Improvements in .NET Core 5
05.01.2021 08:14 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Baumstruktur | Brettstruktur       | Top 
myCSharp.de | Forum
Antwort erstellen


© Copyright 2003-2021 myCSharp.de-Team | Impressum | Datenschutz | Alle Rechte vorbehalten. | Dieses Portal verwendet zum korrekten Betrieb Cookies. 23.01.2021 16:04