Gibt es eine gute Implementierung von Actors for C #? [geschlossen]


75

Gibt es eine gute Implementierung des Akteur-Parallelitätsmodells für .net / c #?

Ich muss die AC # -Routine optimieren und ich denke, dass das Schauspielermodell perfekt als Lösung für mein Problem passt. Leider habe ich nur Erfahrung mit der Scala-Implementierung.


Antworten:


22

Sie sollten sich MS Concurrency & Coordination Runtime (CCR) und die dezentralen Softwaredienste (DSS) von Robotic Studio ansehen .

Mit diesen Frameworks können Sie lose gekoppelte Services entwickeln, die die meisten Anforderungen an den Akteuransatz erfüllen.

Axum passt am besten, leider befindet es sich noch in einer Alpha / Beta-Phase (UPDATE wurde im Februar 2011 getötet). Ich benutze es für meine Forschung und muss sagen, dass die allgemeine Richtung großartig ist und ein enormes Potenzial hat.

Nicht C #, sondern C ++ ist die Asynchronous Agents Library von Microsoft, die Ihnen alle Funktionen bietet, die Sie benötigen.

Schauen Sie sich die parallelen Funktionen von .NET 4 genau an .

Ich hoffe es hilft!


6
und ich fand dies hier: code.google.com/p/retlang
alex25

Vielen Dank für Ihre umfassende Antwort.
Borba

TPL Dataflow enthält Bausteine ​​für Agenten / Akteure auf C #
Dzmitry Lahoda

Der ccrdss-Link ist jetzt tot - über TPL Dataflow (TDF) wird hier gesprochen: msdn.microsoft.com/en-us/concurrency/default.aspx und hier: msdn.microsoft.com/en-us/devlabs/gg585582 (obwohl Ich kann mir vorstellen, dass der zweite Link früher oder später veraltet sein wird. Zum Zeitpunkt der Veröffentlichung dieses Kommentars befand sich TDF noch in der Vorschau
Steve Wilkinson,

Aktualisierung des TPL-Datenfluss-Links: msdn.microsoft.com/en-us/library/vstudio/…
BozoJoe

55

.NET Actor Model-Frameworks:

Proto.Actor

  • Schauspieler
  • Virtuelle Schauspieler

https://github.com/AsynkronIT/protoactor-dotnet

Akka.NET

  • Schauspieler

https://github.com/akkadotnet/akka.net

Microsoft Orleans

  • Virtuelle Schauspieler

https://github.com/dotnet/orleans


Dieses Open-Source-Projekt ist ebenfalls vielversprechend. Github.com/louthy/language-ext // Protokollierungsprozess var logger = spawn <string> ("logger", Console.WriteLine); // Ping-Prozess ping = spawn <string> ("ping", msg => {tell (logger, msg); tell (pong, "ping", TimeSpan.FromMilliseconds (100));}); // Pong-Prozess pong = spawn <string> ("pong", msg => {tell (logger, msg); tell (ping, "pong", TimeSpan.FromMilliseconds (100));}); // Auslöser tell (pong, "start");
Dasith Wijes

25

Man könnte sich auch den Ansatz von Project Orleans Microsofts zu Schauspielern ansehen (der letzte Woche veröffentlicht wurde).

Dies ist die Website des Projekts : http://research.microsoft.com/en-us/projects/orleans/

Hier ist auch ein guter Vortrag von Build 2014 als Einführung

Verwenden von Orleans zum Erstellen der verteilten Cloud-Dienste von Halo 4 in Azure http://channel9.msdn.com/Events/Build/2014/3-641

Bitte beachten Sie, dass die heute veröffentlichten Bits zum Herunterladen CTP sind.

Einführung in Orleans: http://felixnotes.com/orleans-microsofts-take-on-the-actor-pattern-in-net/

Und ja, es war auch Open Source: https://github.com/dotnet/orleans


1
Leider bindet es Sie an die Azure ...
Den

2
Ich denke, es wird bevorzugt mit Azure ausgeführt (da es von Microsoft stammt), aber nicht unbedingt erforderlich, aber nicht 100% sicher.
Silberkämpfer

Es scheint, dass sogar die Entwickler sich nicht sicher sind :) orleans.codeplex.com/discussions/543928
Den


Welcher der drei passt am besten?
Gerard

18

Stact

Eine Actor-Lib auf .Net. Sehr kompetent und gut getestet. Die Gründung von TopShelf, MassTransit und NServiceBus.Host.

https://github.com/phatboyg/stact

Enthält die Abstraktionen:

  • Workflow, mit dem komplexe zustandsgesteuerte Protokolle definiert und ausgeführt werden können
  • Kanäle zur Unterstützung der Nachrichtenübertragung zwischen Objekten
  • Schauspieler, sowohl getippt als auch anonym
  • Fasern, ein kooperatives Einfädelmodell
  • Routing
  • Anfrage / Antwort
  • Scheduler

Bevorstehende:

  • Richtige Supervisor-Hierarchien

Zum Zeitpunkt des Schreibens von Chris aktiv entwickelt.

Überblick:

Die Entwicklung gleichzeitiger Anwendungen erfordert einen Ansatz, der von den aktuellen Softwareentwicklungsmethoden abweicht. Dieser Ansatz betont die Parallelität und Kommunikation zwischen autonomen Systemkomponenten. Das Akteurmodell definiert ein System von Softwarekomponenten, die als Akteure bezeichnet werden und miteinander interagieren, indem sie Nachrichten austauschen (anstatt Methoden an Schnittstellen in einem objektorientierten Design aufzurufen) und ein System erzeugen, in dem Daten (anstelle von Steuerung) durch Komponenten fließen, um sich zu treffen die funktionalen Anforderungen des Systems.

Stact ist eine Bibliothek zum Erstellen von Anwendungen mithilfe des Akteurmodells in .NET. Die Hauptassembly, Stact.dll, ist die Akteursbibliothek und enthält alles, was zur Verwendung des Akteurmodells in jeder Art von Anwendung erforderlich ist. Es gibt auch zusätzliche unterstützende Frameworks wie Stact.ServerFramework, mit denen Akteure über Sockets oder HTTP verfügbar gemacht werden können, sodass Dienste mithilfe von Akteuren erstellt werden können.


Ich habe gerade einen Vortrag über Stact von @phatboyg bei Øredev gesehen. Sehr vielversprechend
svrist

Stact scheint nicht mehr aktiv entwickelt zu sein.
Ronnie Overby

13

NAct ist ein Akteurs-Framework für .NET, das einen wirklich benutzerfreundlichen Ansatz verfolgt. (Haftungsausschluss: Ich habe es geschrieben)

Die zwischen zwei Akteuren übertragene Nachricht ist nur ein Methodenaufruf zwischen zwei Objekten. Sie müssen sicherstellen, dass alle Methodenargumente unveränderlich sind und dass sie threadsicher sind.

Es funktioniert, indem Sie Ihre Objekte in einen Proxy einbinden, der sich mit dem Threadwechsel befasst. Alle normalen .NET-Funktionen, insbesondere Ereignisse, werden korrekt behandelt, sodass Sie normalen Code schreiben können und das Thread-Marshalling von selbst erfolgt.

Es gibt sogar einen Zweig mit Unterstützung für C # 5 async / await.


Würden Sie in Betracht ziehen, einen Teil Ihrer Zeit für die Erweiterung von Stact aufzuwenden, anstatt ein neues Framework zu erstellen? Ich wäre sehr daran interessiert zu sehen, wie Ihr asynchrones Denken mehr von Stact durchdringt (ich bin nicht der Autor, aber ich mag es wirklich).
Henrik

Hmm, ich bin wirklich froh, dass jede Implementierung von Actors an Bedeutung gewinnt, aber ich bin immer noch ein Fan davon, dies mit Methodenaufrufen zu tun. Vergleichen Sie diese mit (zufällig identischen) Codebeispielen mit Stact und NAct: github.com/phatboyg/Stact/wiki/Samples-Ping-Pong und code.google.com/p/n-act/wiki/PingPong
Alex Davies

1
Ich bevorzuge die Semantik der Nachrichtenübermittlung, da sie genau dem entspricht, was sie tut, und es keine Möglichkeit gibt, z. B. einen zeitweiligen Netzwerkfehler oder eine einfache Vernunft mit der Parallelität und den Uhren der gesendeten Nachrichten anzuzeigen, wenn dies nicht explizit ist. Würde ich heutzutage an einem Framework teilnehmen, würde ich den F # MailboxProcessor erweitern, der bereits sehr gut funktioniert - mit Supervisoren und einer einfacheren Nachrichtenübertragung über das Netzwerk.
Henrik

Ich habe gerade EasyActor erstellt, dessen Philosophie NAct ähnelt. Der Hauptunterschied zu Nact besteht darin, dass es Ergebnisse unterstützt, die von Akteuren mit Task <T> erhalten wurden, und auf Castle Core DynamicProxy basiert, um Methodenaufrufe abzufangen. Der Rohleistungstest zeigt auch eine verbesserte Leistung von etwa 40% im Ping-Pong-Test.
David Desmaisons


4

Ich kenne keine Implementierungen für C #, aber es gibt eine ganz neue Programmiersprache, die auf dem Actor-Modell von Microsoft basiert. Es heißt Axum :

Axum(zuvor mit dem Codenamen versehen Maestro) ist eine domänenspezifische gleichzeitige Programmiersprache, die auf dem von Microsoft entwickelten Actor-Modell basiert. Es handelt sich um eine objektorientierte Sprache, die auf der .NET Common Language Runtime basiert und eine C-ähnliche Syntax verwendet. Diese domänenspezifische Sprache ist für die Entwicklung von Teilen einer Softwareanwendung vorgesehen, die für die Parallelität gut geeignet ist. Es enthält jedoch genügend Allzweckkonstrukte, so dass für die sequentiellen Teile der gleichzeitigen Komponenten nicht auf eine Allzweckprogrammiersprache (wie C #) umgeschaltet werden muss.


Danke für deine Antwort. Axum scheint interessant zu sein, aber auf den ersten Blick denke ich, dass die Option ac # besser zu meinem Problem passt.
Borba

3
Leider wurde das Projekt von MS
CharlesB am

@CharlesB Die TPL DataFlow-Bibliothek hat dies ersetzt, nicht wahr?
EJoshuaS - Wiedereinsetzung Monica

@ EJoshuaS Ich habe keine Ahnung
CharlesB

2

Haben Sie MailboxProcessor of T in Betracht gezogen, das mit F # versehen ist?



1

Remact.Net ist mein aktuelles Projekt. Es verwendet WebSockets und Json für das Remote-Actor-Messaging. Es bietet Typensicherheit für C # -Darsteller, unterstützt jedoch auch dynamische Typen für browserbasierte Akteure, die in Java-Skript geschrieben sind.

Mein vorheriges Projekt war AsyncWcfLib . Dies ist eine C # -Bibliothek für Akteure, die in einem Prozess oder zwischen verschiedenen Anwendungen kommunizieren. Die Remote-Nachrichtenübergabe verwendet WCF.
Ein Akteurkatalogdienst ermöglicht die Akteurserkennung auf mehreren Hosts. Auf den Hosts kann Windows oder Linux ausgeführt werden.


0

FSharp.Actor

Ein Schauspieler-Framework für F #.

Aus einem Beispiel:

let rec schizoPing =
    (fun (actor:IActor<_>) ->
        let log = (actor :?> Actor.T<_>).Log
        let rec ping() =
            async {
                let! (msg,_) = actor.Receive()
                log.Info(sprintf "(%A): %A ping" actor msg, None)
                return! pong()
            }
        and pong() =
            async {
                let! (msg,_) = actor.Receive()
                log.Info(sprintf "(%A): %A pong" actor msg, None)
                return! ping()
            }
        ping()
    )

Das Senden von zwei Nachrichten an den "Schizo" -Darsteller führt zu

let schizo = Actor.spawn (Actor.Options.Create("schizo")) schizoPing

!!"schizo" <-- "Hello"
!!"schizo" <-- "Hello"

Ausgabe:

(schizo): "Hello" ping
(schizo): "Hello" pong

Finden Sie es bei github und bei docs


0

Ich habe gerade diese Frage bemerkt und dachte daran, einen neueren Datenpunkt hinzuzufügen. Microsoft hat derzeit ein halboffizielles Projekt dafür, ActorFX . Es ist Open Source und entwickelt sich weiter, aber es lohnt sich, ein Auge auf ...


0

Wie bereits erwähnt, bietet die MailboxProcessor-Klasse von F # eine einfache und unkomplizierte Implementierung des Akteurmodells. Eine fantastische Einführung in die Verwendung finden Sie hier . F # arbeitet sehr gut mit C # zusammen und Sie können den Agenten in eine Klasse mit Methoden einschließen, die verschiedene Nachrichten veröffentlichen. Informationen zu den Fällen, in denen der Agent mit einer asynchronen Antwort antwortet, finden Sie in der PostAndAsyncReply- Methode. Dies gibt einen Async-Workflow zurück, den Sie mit der Async.StartAsTask- Methode in eine Aufgabe verwandeln können, die in C # erwartet werden kann.

Wenn Sie Ihre Schauspieler remote verteilen müssen, empfehlen wir Ihnen Akka.NET, das sowohl C # - als auch F # -APIs bietet.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.