Prozesskommunikation über ein Netzwerk realisieren

Hallo zusammen,

mich interessiert gerade wie man eine Prozesskommunikation über ein Netzwerk realisieren kann. Im Internet findet man zwar sehr viel zu dem Thema, aber auch viel altes. Daher würde ich gerne von euch wissen was 2018 "state of the art" ist. WCF, SimpleTCP oder....??

Ich würde gerne Klassen oder xml über ein Netzwerk von A nach B senden, EDIT[für Desktop Applikationen]. Eine konkrete Aufgabenstellung gibt es nicht, ich möchte nur testen und lernen.

Über eure Meinung würde ich mich sehr freuen!

LG
Christoph

Ist meistens Abhängig von der Anwendung.
Bei Webanwendungen nimmt man z.B. WebAPI als Schnittstelle zur Kommunikation.
Bei Desktop Anwendungen kann man dies per Serialisierung(JSON, XML, Binär) und einer TCP/UDP Verbindung erledigen.
Hier müssen dann aber in beiden Fällen beide Anwendungen auch die Klasse kennen und natürlich auch in Teilen oder Komplett wieder Deserialisieren können.

Wenn du einen spezifschen Fall hast, kann man auch eine spezifische Lösung liefern.
Eine generische Lösung fü alle Varianten, kann man leider nicht anbieten.

T-Virus

JSON über REST-Schnittstellen; das erkennst Du alleine an der Art, wie aktuelle Technologien derzeit kommunizieren bzw. implementiert sind.

Bei Desktop Anwendungen kann man dies per Serialisierung(JSON, XML, Binär) und einer TCP/UDP Verbindung erledigen.

Das kann man in Webanwendungen auch; macht man aber nicht.
Wozu denn TCP (oder gar das verlustbehaftete UDP????) nehmen, wenn das gar nicht notwendig ist? Ich müsste doch viel zu viele Räder für so einen Zweck neu erfinden, das ich auch geschenkt bekommen kann - und zwar getestet, standardisiert und konform!

Allein das Thema Authentifizierung, was man überall haben sollte, ist ein riesen Akt selbst in TCP zu implementieren.
Wer das missachtet, handelt bewusst fahrlässig; und wer darüber - auch auf dem Desktop - Daten im Sinne des GDPR überträgt, sogar gesetzwidrig.

Ich kann genauso in Desktop-Anwendungen mit REST-Schnittstellen arbeiten.
So arbeitet zum Beispiel die gesamte Office 365 Desktop Suite beim Abgleich und Übertragung von Informationen.

Eine generische Lösung fü alle Varianten, kann man leider nicht anbieten.

Doch; das kann man.
Die Aufgabenstellung hier ist die Übertragung von Klassen.
Und dafür eignet sich REST mit Json (oder alternativ XML) hervorragend für alle Technologien.

Wenn es um eine "Übertragung jeglicher Art" ginge, was hier nicht der Fall ist, dann kann man tatsächlich nichts anbieten.

Ist meistens Abhängig von der Anwendung.
Bei Desktop Anwendungen kann man dies per Serialisierung(JSON, XML, Binär) und einer TCP/UDP Verbindung erledigen.
Hier müssen dann aber in beiden Fällen beide Anwendungen auch die Klasse kennen und natürlich auch in Teilen oder Komplett wieder Deserialisieren können.

Sorry, sollte für den Desktopbereich sein, ich habe es angepasst.

@Abt
Wie genau würde man dann die REST Schnittstelle auf Desktop Ebene umsetzen?
Würde mich schon interessieren, da ich dies sonst nur bei Webanwendungen bisher mit WebAPI kenne, aber ohne WebAPI bei reinen Desktop Anwendungen wüsste ich nicht, wie dies realisiert werden sollte.

Hast du dazu ein paar Links/Infos?
Würde mich in das Thema mal reinarbeiten wollen.

T-Virus

.NET selbst kann sowas schon seit Version 3.
Auch schon mit NancyFX war das problemlos in jede Desktop-Anwendung zu integrieren und quasi seit Jahren Alltag.
WCF kann das ja prinzipiell genauso und wird auch hier im Forum immer wieder genau für dieses Thema empfohlen. Ich persönlich rate aber mittlerweile von WCF ab; es ist einfach obsolete (für 99,999% der Dinge).

Eine ASP.NET Core Anwendung ist nichts anderes als eine Konsolenanwendung - NICHTS anderes.
Hier ist absolut keine Besonderheit. Und es würde null Unterschied machen, wenn ich das nicht in einer Konsolenanwendung sondern in einer Anwendung mit UI starten würde.

REST ist keine reine Internet-Technologie. REST ist einfach nur der "Nachfolger" von SOAP und WSDL. Und SOAP ist ja für Inter-Process Communication in vielen Bereichen (leider) noch Standard.
REST basiert einfach auf HTTP und ein HTTP-Endpunkt kann in jeder Anwendung erzeugt werden. In jeder.
Ob HTTP im Internet, im Intranet oder zwischen Prozessen verwendet wird: wer sagt denn, dass es nur dort oder dort verwendet werden darf?

Sehr viele Anwendungen, weit mehr als man denkt, arbeiten genau so.
Weiß jetzt nicht was Du da für eine Lektüre haben willst; das ist ja nichts Außergewöhnliches.
Ist ja nur der intelligente Mix von bereits vorhandenen Technologien.

Natürlich kann man auch so Dinge von NamedPipes nehmen; aber auch hier muss man sehr sehr viel neu erfinden.

Vielen Dank schon mal für die ganzen Infos!

Kann ein ASP.Net Dienst auch Daten an einen Client weiterleiten?

Weiß jetzt nicht was Du da für eine Lektüre haben willst; das ist ja nichts Außergewöhnliches.

Lektüre hätte ich auch gerne. Eine Anleitung die mein Vorhaben beschreibt konnte ich bisher nicht finden. Vielleicht liegt es auch daran, das ich null von ASP.Net kenne!?

Die Basics kann ich euch aber nicht abnehmen.
Sowas, wie ein Protokoll funktioniert, das müsst ihr euch halt selbst beibringen.
Und Push bei HTTP gibt es nicht. Push braucht logischerweise eine aktive Verbindung; das gibt es aber bei HTTP nicht.
Ergo kann man natürlich nicht mit ASP.NET pushen.

Für Push-Wege gibt es dann eben andere Technologien, wie Web-Sockets zB. auf Basis von SignalR.

Kann ein ASP.Net Dienst auch Daten an einen Client weiterleiten?

Jetzt sprichst Du plötzlich von einem Client.
Das hört sich nicht mehr an wie eine gleichwertige Peer-to-Peer Kommunikation oder Inter-Process Communication wie Du es im Startthread zunächst beschreibst.

Lektüre hätte ich auch gerne. Eine Anleitung die mein Vorhaben beschreibt konnte ich bisher nicht finden

Wie gesagt; es ist keine neue Technologie die neue Lektüre mitbringt.
Es ist doch einfach nur ein Mix der Verwendung von vorhandenen Technologien. Und ihr habt sicherlich nun Verständnis, dass ich euch keine Google-Treffer über ASP.NET raussuche.
Den Einstieg könnt ihr dazu selbst machen 😉

Dachte bisher WCF wäre auch nur für Web, hab halt noch nicht viel damit gemacht.
Da ich auch bisher sogut wie nichts mit ASP .NET Core gemacht habe, fehlt mir hier auch der aktuelle Stand.
Entsprechend kann ich diesen Ansatz bisher nicht.

Die Frage für mich wäre jetzt nur, wie die Performance davon aussieht.
Eigentlich würde ich eine Datenübertragung zwischen Prozessen im Netzwerk möglichst ohne HTTP Server umsetzen wollen.

Ein Beispiel wäre z.B. wenn ich einige TCP/UDP Server habe, die unterschiedliche GPS Daten entgegen nehmen und in ein eigenes festes GPS Format umwandeln soll.
Dieser umgewandelten Daten müssten dann von dem TCP/UDP Server wieder zu einem weiteren zentralen Prozess gesendet werden.
Dieser könnte dann auf dem gleichen oder einem anderen Server liegen.
Dieser Prozess wäre dann eine zentrale Empfangsstelle, die diese Daten im festen Format entgegen nimmt und speichert.
Wenn hier nun z.B. einige Hundert bis Tausend Anfragen reinlaufen in wenigen Sekunden, wie wäre dort dann die Performance mit ASP .NET Core und REST als Protokoll?

Hier fehlt mir etwas der Überblick wie die Performance von ASP .NET Core im Moment bei solchen Lastszenarien aussieht.
Wäre mal ein Testprojekt in den nächsten Tagen wert.

T-Virus

Jetzt sprichst Du plötzlich von einem Client.

Sorry, das du mich falsch verstanden hast. Ich dachte das ist ist klar, wenn ich von Prozess spreche und von A > B senden.

Also doch WCF oder SimpleTCP ?

@Christoph1972
Nein ist so nicht verständlich.
Deine Anfrage war Netzwerk Kommunikation zwischen zwei Prozessen.
Das kann alles möglich sein, was über das Netzwerk läuft.
Das können Client-Server Anwendungen sein oder zwei Desktop Anwendungen oder oder oder.
Musst du spezifizieren, was du genau meinst.
Sonst kann man nicht wissen, welches Prozesse du meinst.

Nachtrag:
Auf WCF solltest du verzichten, da die Zukunft hier nicht ganz klar ist.
Wie Abt schon vorschlägt, dann lieber mit ASP .NET Core und einer einfachen REST WebAPI.
Kann man mit .NET Core simpel starten, Anleitungen dazu gibt es im Netz zuhauf.
WebAPI oben drauf packen, kannst du dann mit Einbindung der NuGet Pakete + Anleitung im Netz wie man diese nich konfigurieren muss.

T-Virus

Naja, überleg halt mal was ein HTTP Server überhaupt ist und was ihn von einer Socket-Verbindung mit TCP, wie Du es sagst, unterscheidet: nicht viel.

Beides sind ganz einfache Sockets mit der Ausnahme, dass Du bei HTTP eben viel geschenkt bekommst und Du einen wiederverwendbaren Standard hast.
Das haste mit nem eigenen Socket-Gebastle nicht. Niemals.

Du stellst hier also es so dar, als ob es völlig verschiedene Dinge sind.
Ist es aber nicht. Es gibt Dir einfach ein Format vor, wie eben Protobuf zum Beispiel auch.

Und Dir ist schon bewusst, dass ASP.NET zu den performantesten Frameworks gehört, die es derzeit gibt? https://www.techempower.com/benchmarks/
Wenn Du sowas wie Security und Protokolle selbst implementierst, stell Dir dann mal die Frage, was schneller ist..
Ein Tipp: Dein Socket-Zeug sehr wahrscheinlich nicht. 😉

Also doch WCF oder SimpleTCP ?

Hab ich schon beantwortet:

Ich persönlich rate aber mittlerweile von WCF ab; es ist einfach obsolete (für 99,999% der Dinge).

Wozu denn TCP (oder gar das verlustbehaftete UDP????) nehmen, wenn das gar nicht notwendig ist? Ich müsste doch viel zu viele Räder für so einen Zweck neu erfinden, das ich auch geschenkt bekommen kann - und zwar getestet, standardisiert und konform!

Ich setze auf zwei Dinge:

• REST
• Google's Protobuf
  Kommt halt dann doch auf die Anwendung an...

@Abt
Ich werde mich mal die Tage ranmachen und mal ein wenig mehr mit ASP .NET Core arbeiten und eine entsprechende Testanwendung umsetzen.
Dann kann ich hier auf meinen Kisten schauen, wie der Durchsatz ist und was mich da grob erwartet.

Mein Ziel ist es dabei, eben möglichst wenig Overhead bei der Datenübertragung zu haben und auch möglichst wenig zusätzliche Last zu erzeugen und somit performant wie möglich.
Hier muss ich aber wirklich mal testen, wie dies mit ASP .NET Core aktuell aussieht.
Da fehlt mir halt noch zu viel Wissen, weshalb ich es aktuell nicht wirklich abschätzen kann.

Ich arbeite aktuell überhaupt nicht mit ASP .NET Core und werde es beruflich wohl in den nächsten 1-2 Jahren auch nicht.
Und Privat mache ich gar keine Projekte mehr, es sei den Lernprojekte wenn mal ein brauchbares Thema reinflattert wie jetzt.

T-Virus

Mein Ziel ist es dabei, eben möglichst wenig Overhead bei der Datenübertragung zu haben und auch möglichst wenig zusätzliche Last zu erzeugen und somit performant wie möglich.

Wenn ich provokativ sein darf: und offensichtlich auch möglichst wenig Wiederverwendbarkeit, kaum Testbarkeit, keine Beachtung für Security....

Performance alleine - auch wenn_ performance is a feature_ mein Leitspruch ist - ist niemals alleine eine akzeptable Kennzahl.
Für sowas gibt's dann Mechanismen der Skalierung.

Ich würde das so nie empfehlen - meine persönliche Meinung.

In dem Kontext hast du recht, da würde einiges auf der Strecke bleiben.
Wie gesagt, werde ich mal eine Testanwendung umsetzen und schauen wie sich dies verhält unter Dauerlast.

T-Virus

Also ich kann dir versichern das bevor deine Restschnittstelle in die Knie geht sich ganz andere Flaschenhalse auftun z.B. die Datenbank. Ich hab jetzt in 6 Jahren einblicke in ein paar Projekte gesehen und da waren HTTP basierte Schnittstellen nicht das Problem 😉 Im übrigen basiert quasi die Gesamte Web-, und Schnittstellen für Mobile Anwendungen auf Rest. Und im Business-Software bereich wird das Thema Rest auch immer größer durch das Thema Microservices. Es gibt echt nicht so viele Anwendungsfälle wo man die "langsamkeit" von Rest beachten muss.

@Lacka
Stimmt schon.
Für ein aktuelles Projekt, was wir dieses Jahre Relaunchen wollen, will ich deshalb die Möglichkeiten ausloten.

Aktuell nutzen wir noch ein Konzept, was die Daten als Query String an einen HTTP Handler schickt.
Dies ist dem Umstand geschuldet, dass das Projekt nun rund 8 Jahre alt ist und mit .NET 2.0 gestartet wurde.
Damals hatte ich gerade etwas mehr als die Grundlagen von C# gelernt und war mitten in der Ausbildung.
Entsprechend fehlte mir hier der gesamte Hintergrund, wie man diese Daten hätte übertragen können.

Dabei nehmen wir wie oben beschrieben, die TCP/UDP Server von unterschiedlichen GPS Boxen die GPS Daten in deren Format entgegen.
Die Daten werden dann in das generelle GPS Format umgewandelt und als String an den Handler geschickt.
Dieser verarbeitet und speichert dann die GPS Daten.
Diesen haben wir im laufe der Jahre soweit optimiert, dass er schon einiges an Grundlast einstecken kann, aber wirklich optimal ist das Konzept heute nicht mehr.

Deshalb würde ich schon eher den WebAPI Weg mit Post gehen um die Daten zu übertragen.
Dies dürfte für die Übertragung der Daten dann mehr als ausreichen.
Dazu werde ich heute Abend mal meine Test WebAPI ausbauen und mit einigen Test Clients entsprechend Daten darauf hämmern lassen.

T-Virus

Dann solltest du aber darauf achten, was du wirklich testen möchtest.

Wenn deine Test-WebAPI die Daten annimmt, konvertiert und in die Datenbank einträgt, dann misst du nicht nur die Übertragung.

Wenn es auf den Durchsatz ankommt, dann kann die WebAPI die Daten auch entgegennehmen und in eine Queue eintragen (MSMQ, RabbitMQ, etc.). Von dort aus können dann n Systeme diese Daten verarbeiten.

@Sir Rufo
Ich will erst einmal testen wie der Durchsatz der WebAPI ist.
Sollte aber dank Post mehr als schnell sein.
Datenbank Anbindung ist in diesem Fall noch nicht eingeplant, da es erst einmal nur reine WebAPI Tests sind.
Diesen Testfall muss ich dann im nächsten Schritt einplanen.
Dazu würde ich dann, um auch damit Erfahrungen zu sammeln, mal Dapper ausprobieren.

T-Virus

Wie gesagt, ich würde bei so einem Datensammler, das Entgegennehmen und Eintragen in die Datenbank mit einer Queue entzerren.

@Sir Rufo
Ich will erst einmal testen wie der Durchsatz der WebAPI ist.
Sollte aber dank Post mehr als schnell sein.

Was hat denn Post mit irgendeinem Datendurchsatz zutun? Weißt Du überhaupt, was HTTP Post ist...? Sieht nach dem Satz nicht so aus 😉
Mir scheint so, dass Du hier irgendwas ohne Hand und Fuß einfach mal raus bläst.

Zielführend? Absolut nicht.

Und was Du da beschreibst T-Virus sagt Sir Rufo völlig richtig: sowas ist ein Fall für eine Queue und Architekturen wie CQ(R)S.

Ich würde mich hier gerne mal einklinken und zum Thema "Prozesskommunikation über ein Netzwerk realisieren" zurückkehren.

Wenn es also darum geht zwei Prozesse miteinander kommunizieren zu lassen, starte ich in min. einem Prozess einen HTTP-Server, der dann entweder REST oder ähnliches versteht.

Das Problem, welches ich schon mehrmals hatte ist, dass mir die Windows-Firewall per default nicht erlaubt einen HTTP-Server zu hosten. Dazu benötigt der Prozess entweder eine höhere Berechtigung oder ich muss dies explizit in der Windows Firewall freigeben.

Ist das bei euch nicht so? Gibt es da workarounds?

Eine Firewall kann nicht verbieten, dass ein Prozess einen "HTTP Server" hostet.

Eine Firewall kann lediglich den Verbindungsaufbau unterdrücken; und dies erfolgt i.d.R. egal ob es eine einfache Socket-Verbindung oder eine HTTP-Verbindung ist.
Ich hab das regelmäßig auch mit NamedPipe-Verbindungen via ProtoBuf. Wenn eine Firewall sich nicht meldet, dann ist sie eigentlich nicht restriktiv genug eingestellt.

Der einzige schmutzige Workaround bei einer korrekt eingestellten Firewall ist Hole Punching.
Aber UDP ist in 99,9% der Fälle kein legitimer Weg.

Und wie gesagt: jede ASP.NET Core Anwendung ist eine Konsolenanwendung mit integriertem HTTP Server (Kestrel).
Probier doch einfach mit dem Standard Template aus, ob Deine Anwendung geblockt wird.

Was man natürlich nicht tun darf bei sowas, ist Port 80 oder 443 zu verwenden.
Die sind ja wirklich für PC-weite Webserver gedacht.

@Abt
Stimmt Post ist hier der faslche Weg, würde die Daten im Endeffekt als Formulat Variablen an den Server schicken.
Put wäre hier der richtige Ansatz.

Ich muss die WebAPI nochmal überdenken, da ich einen Teil der Anforderung bisher nicht bedacht hatte.
Die WebAPI muss nach dem empfangen der Daten auch eine Rückmeldung machen, ob die Daten verarbeitet werden konnten.
Defekte Daten müssen hier einen entsprechenden Status liefern.
Ebenfalls müssen komplett ungültige Daten auch einen Fehlerstatus melden.

Dann kann es aber auch sein, dass neben dem Status noch einer oder mehrere Base64 Codierte Strings zurückgemeldet werden können.
Dabei handelt es sich aktuell um GPS Navi Befehle/Antworten.
Die Anfragen dazu kann ich über eine eigene WebAPI abbilden, aber es kann eben auch passieren, dass wir beim erhalten einen GPS Datensatzes eine Rückmeldung machen müssten.
Hier müsste ich entweder die spezifische WebAPI jedes mal zusätzlich abfragen oder im Response der GPS Put Methode einen entsprechenden Response oder einfach eine Info, dass Daten zum abholen der Navi Api vorliegen.
Würde ich trennen wollen, da dies sauberer sein dürfte als die APIs so über Kreu zuverknüpfen.

@MorphieX
Ist so wie Abt es schreibt.
Das Template in VS2017 legt hier nur eine Konsolenanwendung an.
In der Main Methode wird dann eine Methode augerufen, die den Webserver mit der StartUp Klasse konfiguriert und dann auch startet.
Die entsprechenden Einstellungsdateien sind dann im Projekt enthalten.
Bei mir war dann auch zusätzlich eine Beispiel WebAPI dabei, die auch direkt Daten liefert die fest hinterlegt sind.
Hatte hier explizit eine ASP .NET Core 2.0 WebAPI angelegt um eben den WebAPI Test umzusetzen.

T-Virus

@Abt
Stimmt Post ist hier der faslche Weg, würde die Daten im Endeffekt als Formulat Variablen an den Server schicken.
Put wäre hier der richtige Ansatz.

Ähm, was? 🤔

Bitte schau Dir mal nochmal an, was PUT und POST ist.
Du würfelst hier einfach nur - sorry, das so sagen zu müssen.

Trotzem, egal ob PUT oder POST: ein HTTP Verb hat genau 0 mit Performance zutun.

Ich muss die WebAPI nochmal überdenken, da ich einen Teil der Anforderung bisher nicht bedacht hatte.
Die WebAPI muss nach dem empfangen der Daten auch eine Rückmeldung machen, ob die Daten verarbeitet werden konnten.

Und nochmal sorry: bitte schau Dir ein Thema an, bevor Du irgendeinen/so einen Käse postest. Das bringt doch nichts ?!
Auch eine API kann eine Rückmeldung - jeglicher Art - geben. Kommt ganz drauf an, was Du für ein Gesamtsystem hast, ob dies synchron oder asynchron ist.
Aber aktuell postest Du hier einfach nur Käse. Und es wird mit jedem Post irgendwie schlimmer...

@Abt
Aktuell sind deine Kommentare nicht hilfreich.
Wenn ich die Daten weder mit Put noch mit Post übertragen soll, wie soll es sonst gemacht werden?
Ich kenne nur Put und Post um Daten an den HTTP Server zu senden.
Alle anderen Varianten(GET, DELETE etc.) machen keinen Sinn.
Es bringt nichts, hier alle Möglichkeiten abzulehnen ohne Erklärung warum dies falsch ist.
So komme ich nicht weiter, außer dass dann mehr Verwirrung als Klarheit herrscht.

T-Virus

Schau Dir doch erst mal an, was PUT oder POST überhaupt im Sinne von REST ist, dann ergibt sich das von ganz alleine.
Using HTTP Methods for RESTful Services

Aber eine Aussage wie

Ich will erst einmal testen wie der Durchsatz der WebAPI ist.
Sollte aber dank Post mehr als schnell sein.

verfehlen so weit das Thema, dass der Mars dagegen um die Ecke ist.
Ein HTTP Verb hat NULL KOMMA NULL mit Performance zutun.

Du verlangst doch auch immer wieder - zurecht - von anderen, dass sie die Basics erlernen.
Das fehlt Dir hier aber genauso.

Deswegen erst mal das Thema anschauen, und dann posten. Ne?
Aktuell haust Du eines nach dem anderen raus - und das vollkommen falsch - ohne vermutlich auch nur ein mal ordentlich was damit selbst ausprobiert zu haben.
Das jedenfalls haste selbst gesagt. Weiß nicht, wie man darauf basierend dann irgendwelche Ratschläge geben kann... mir ein Rätsel.

@Abt
Aber dann ist Post doch richtig.
Ich will von den "Clients" die GPS Daten an die API senden und dort speichern.
In dem Kontext ist POST doch genau das was ich brauche.
Ich glaube wir sprechen nur aktuell an einander vorbei.

T-Virus

@T-Virus

Es geht nicht darum ob POST richtig oder falsch ist, sondern um deine Aussage

Sollte aber dank Post mehr als schnell sein.

Da kannst du auch schreiben:

Ich muss in einer Stunde mit einem Auto in Köln sein.
Meins ist schwarz, das wird wohl schnell genug sein.

um eine ähliche Aussagekraft zu haben

@Sir Rufo
Jetzt ist klar, was ihr meint.
Ich stand hier etwas auf dem Schlauch.
Klar die Aussage ist Unsinn, kann verworfen werden.

T-Virus

Die WebAPI muss nach dem empfangen der Daten auch eine Rückmeldung machen, ob die Daten verarbeitet werden konnten.
Defekte Daten müssen hier einen entsprechenden Status liefern.
Ebenfalls müssen komplett ungültige Daten auch einen Fehlerstatus melden.

HTTP liefert dir immer einen HTTP-Statuscode zurück.

Für den von dir genannten Fall wird BadRequest dich wohl am weitesten bringen.
Edit: Oder du gehst über 9xx, wobei das Gefrickel und für eine simple Validierung von Daten etwas Kanonen auf Spatzen ist.

Beste Grüße
emuuu

HTTP liefert dir immer einen
> zurück.

Der Status Code eignet sich dafür aber nur insgesamt bedingt.
Ein Code sagt nichts anderes an als ein numerisches Ergebnis; das reicht aber i.d.R. nicht.
9xx gilt als bad practise.

Deswegen gibt es strukturierten Resultate (zB. Json als Return im Sinne von Hypermedia) als Stufe über REST.

Aber wie bereits gesagt sollte T-Virus sich im Sinne von solchen Services einfach mal in die Thematik einlesen.
Raten und Puzzlen hat an solchen Stellen in der Vergangenheit i.d.R. schlimme Resultate erzeugt 😉

Keiner braucht meinen, dass er in der Welt der Services der erste mit solchen Anforderungen ist.
Da haben sich schon sehr schlaue Menschen entsprechend standardisierte Lösungen überlegt.

Danke für die Infos!

Ich werde meine Gehversuche der Prozesskommunikation nun mit der ASP.Net API und Named Pipe umsetzen. Mit der Kombination beider Technologien sollte das gut machbar sein und ich lerne nebenbei wie das Web API funktioniert.

Diese Tutorial Serie scheint mir sehr geeignet: https://www.youtube.com/watch?v=0pcM6teVdKk

Es gibt einige Folgen zu dem Thema.

Das ist aber das "alte" Produkt ASP.NET und nicht das neue ASP.NET Core.

Wenn Du eine Umgebung hast, mit der ASP.NET Core lauffähig ist, dann nimm auch das neuere.
Wenn nicht, dann lieber NancyFX statt dem ASP.NET WebAPI 2.2 Monolithen.

Versteh bitte die Technologien zuerst, evaluier dann anschließend erst mal richtig zB. auf Basis von www.asp.net statt jetzt mit "irgendwas" anzufangen.
Ansonsten biste hier in 6 Monaten und schiebst die Schuld auf irgendwen 😉

Das ist aber das "alte" Produkt ASP.NET und nicht das neue ASP.NET Core.

Zum Grundlagen legen und verstehen sollte das vorerst reichen, oder?

Versteh bitte die Technologien zuerst, evaluier dann anschließend erst mal richtig zB. auf Basis von
> statt jetzt mit "irgendwas" anzufangen.
Ansonsten biste hier in 6 Monaten und schiebst die Schuld auf irgendwen 😉

Ich mache das nur um die Technologie zu erlernen, es gibt noch keine Anforderung, aber das kommt dann ja vielleicht im laufe der Zeit.

Vielen Dank für die Hinweise! 👍

Das Problem ist, dass ASP .NET Core schon ein ziemlicher Technologie Umbruch ist.
Das alte ASP .NET hat noch alte Techniken, wie WebForms die im neuen Core keine Rolle mehr spielen.
Gerade im Webbereich hat sich in den letzten Jahren zu viel getan um den alten Stoff noch viel Wert zu schenken.
Dort hat man noch Update Panels die dicke Ajax Anfragen generieren und vom Server dann die Antworten liefern.
Ist schon seid Jahren nicht mehr zeitgemäß.

Webanwendungen werden werden heute primär als Single Page Applications entwickelt.
Also liegt beim Client fast nur HTML mit JS in Kombination vor und sprechen mit dem Server per REST Schnittstelle.

Ist ein ziemlich großes Thema, dass man nicht einfach mal so lernt.
Und mit alten ASP .NET Techniken wirst du heute schon keine neuen Projekte mehr machen wollen.
Lohnt sich einfach nicht mehr, dass alte Kram zu lernen.

Ich pflege hier noch WebForms Projekte, die schon um die 8-6 Jahre alte sind.
Unsere neuen Projekte werden nur noch auf Serverseite mit WebAPI und im Client per AngularJS und HTML Templates umgesetzt.
Und dies ist der aktuelle Stand seit rund 2-3 Jahren, vielleicht auch etwas mehr hab es nur noch nicht solange auf dem Schirm.
Also tue dir selbst den Gefallen und schau dir nur das aktuelle Zeug an.

T-Virus