Client TCP IP

Jul 6, 2016 at 5:18 PM
TEXT

Hallo Konrad,
sicher ein gutes Beispiel.
Aber enorm groß und etwas unübersichtlich.
Hast Du evtl. ein gutes Client Asynchron Projekt parat? Gerne mit Events etc.

Danke vorab und Grüße Sandra
Coordinator
Jul 6, 2016 at 5:27 PM
Hallo Sandra,

die Klassen sind halt so gedacht, dass die ganzen Klassen 1:1 übernommen werden und so relativ wenig eigener Code geschrieben werden muss.

Das unübersichtlich ist aber ein wichtiger Punkt - hast Du eine Idee, was dies evtl. noch übersichtlicher machen könnte?

Ich versuche derzeit auch, zu diesem Theme ein Technet-Artikel zu schreiben sowie ein entsprechendes Beispiel-Projekt. Aber das zieht sich leider derzeit etwas hin (Ist halt insgesamt doch etwas umfangreicher).

Ideen und Vorschläge nehme ich gerne mit auf.

Viele Grüße,

Konrad
Jul 7, 2016 at 5:21 PM
Hallo Konrad,

den Code habe ich nicht getestet, suche noch ein gutes Gegenstück.

zu a)
Du hast recht Verbindung aufbauen, vergessen, da habe ich auch Bedenken.
Vom zeitlichen her, wäre es günstiger die Verbindung einmalig aufzubauen und dann nur
noch auf die Events, sprich den Anfragen seitens Client zu hören.
Man könnte es ja wie folgt machen.
Im vereinbarten Datenaustausch Server - Client wird die Länge mitgegeben,
die mind. gelesen werden muss.

Sei mir bitte nicht böse. Ich suche ein gutes asynchrones Handling,
das man noch verstehen kann und nicht zuviel Overhead, Möglichkeiten drin sind.

Man müßte die Verbindung einmal aufbauen, nicht für jedes Telegramm.
Eigener Thread, um keinen Zeitverlust zu haben.

Wenn Du hierzu noch was hast, wäre es echt super.

Viele Grüße Sandra
Jul 7, 2016 at 5:23 PM
Hallo Konrad,

ja das hört sich gut an.
TEXT
Leider kann ich nicht helfen, da ich zu diesem Thema auch nach praktischen Lösungen suche.

Auch zum Thema Performance Logger finde ich wenig.
TEXT
Log4nNet macht es evtl. gar nicht im eigenen Thread.
Über GitHub gibt es noch den EasyLogger, leider ist nur der Name easy, wie die Konfiguration genau zu handhaben ist, geht nicht deutlich hervor.

Vielleicht weißt Du hier auch etwas.
Grüße Sandra
Coordinator
Jul 8, 2016 at 8:08 AM
Hallo Sandra,

bezüglich Logging nutze ich eigentlich immer die TraceSources. Die Listener werden dann per Config-File konfiguriert.

Was für Performance-Probleme siehst Du denn da? Ein Logeintrag ist normalerweise sehr schnell geschrieben. Es gab da mal einen größeren Thread in den MSDN Foren, und da habe ich dann auch ein paar Tests gemacht und fand die Lösung mit den TraceListenern nicht wirklich schlecht. Wenn Du ganz viele Nachrichten auf niedrigem Niveau schreibst, dann wäre evtl. ein direkter Test denkbar. Sprich: Globale Variable (Also entweder über Singleton oder eine statische Variable), die einmal gesetzt wird beim start der Applikation über die Konfigurationsdatei und die dann direkt aufgerufen wird. Das mag eine kleine Optimierung sein, weil man dann die TraceListener Aufrufe nicht mehr machen muss (dem meist auch ein String.Format Aufruf voran gehen würde!) und statt dessen einen schnellen check einer Variable hat.

Die Lösung mit einem zweiten Thread halte ich nicht für optimal. Wenn die Applikation crasht, dann fehlen evtl. Logeinträge. Denn um die Performance-Steigerung zu haben musst Du ja parallel weiter arbeiten. Das halte ich daher nicht wirklich für zielführend. Ich weiß nicht, was die großen Log-Frameworks diesbezüglich so bieten, aber ich habe Abstand von diesen Frameworks genommen. Es ist einfach eine weitere Abhängigkeit, die einfach nicht sein muss. Die meisten Features, die benötigt werden wie die Konfiguration zur Laufzeit ist durch die .Net Methoden ja durchaus möglich. Aber klar - spezielle Anforderungen mögen die Nutzung empfehlenswert machen.

Bezüglich der Netzwerk-Codes: Eine Vereinfachung sehe ich im Augenblick nicht wirklich. Der Server muss gewisse Aufgaben erfüllen:
  • Es muss ein Socket (oder eine Instanz, die den Socket verwaltet) geöffnet werden.
  • Neue Verbindungen müssen angenommen werden.
  • Die Verbindungen müssen verwaltet werden.
  • Daten müssen an eine Verbindung gesendet werden können
  • Daten die ankommen, müssen gelesen werden
  • Statusveränderungen müssen erfasst werden.
Und die wichtigen Veränderungen werden per Events heraus gegeben.

Die Kernidee ist ja bei den Klassen, dass diese einfach verwendet werden. Es geht also eigentlich nicht darum den Code als Anleitung für einen eigenen Code zu nutzen. Die Lesbarkeit werde ich aber noch etwas erhöhen, indem ich Methoden noch etwas unterteilen werde. Das sind aber einfache Refactorings und am Code selbst wird sich nichts ändern.

Und ein einfaches Beispiel mit einem Chat Client / Server findet sich ja auch im Forms Beispiel. Da könntest Du die Nutzung der TcpIpClientConnection und TcpIpServerConnection anschauen.

Ansonsten kommen noch komplexere Beispiele / Beschreibungen - aber das zieht sich leider noch etwas hin ...

Viele Grüße,

Konrad
Jul 8, 2016 at 2:51 PM
Hallo Konrad,

vielen Dank.
Logging nutze ich eigentlich immer die TraceSources. Die Listener werden dann per Config-File konfiguriert
Ich muss von meinem Chef den Log4net nehmen. Dieser zeigt beim Level DEBUG auch zeitliche Verzögerungen.
Ich muss auf 1ms kommen, beim Level DEBUG bin ich bei 6ms. Da ist das Problem, da meine Anwendung zeitkritisch ist.

Ich freue mich auf Deine Beispiele.

Grüße Sandra