✔ Effiziente Skriptsprache zum Aufrufen aus Anwendung?

multimolti

multimolti

Erfahrenes Mitglied
Hallo!

Ich sitze momentan an einem Projekt wie folgt:
  • Das Programm bekommt der TCP/IP ein Telegramm (Adresse + Wert)
  • Es entscheidet, ob mit diesem Telegramm etwas gemacht werden soll
  • Wenn ja, wird irgendwas berechnet, abhaengig von x Faktoren und ein Telegramm zurueckgesandt
  • Wenn nein, warte auf neues Telegramm


Der Punkt ist jetzt, dass die Nutzer selber das Verhalten bei bestimmten Telegrammen bestimmen koennen sollen, deswegen habe ich an eine Skriptsprache gedacht (Lua?); die Skripts kann der Nutzer (z.B. per Webinterface) in der Datenbank erstellen/aendern, diese werden bei Eingang des Telegramms ausgefuehrt und haben als Rueckgabeparameter entweder 0 (keine Antwort) oder das Rueckgabetelegramm.

Ich habe einen Lua Parser fuer C# gefunden (das ist die Sprache in der der Rest des Projekts realisiert ist), AluminumLua, der funktioniert soweit auch. Jetzt zu meiner eigentlichen Frage/Problem:

  • ist das grundsaetzlich ein guter Ansatz, das mit einer Skriptsprache wie Lua zu machen, die dann in meinem Programm bei Eingang geparst wird?
  • gibt es eine Moeglichkeit, von in-dem-Lua-Skript an Werte von ausserhalb zu kommen? Die Entscheidungen im Skript werden anhand anderer Werte in einer Tabelle/Array getroffen, und das Array kann theoretisch 32.000 Eintraege haben. Daher sehe ich es nicht als effizient an, dieses Array als Parameter beim Start des Skripts zu uebergeben.
Erganzung: Es koennen theoretisch mehrere Telegramme pro Sekunde reinkommen, und die Reaktionszeit des gesamten Programms (also bis das Antwort-Telegramm rausgeht) sollte auf jeden Fall unter 100ms liegen).

Hat da jemand Ideen? Ich waere begeistert :D

Danke!
 
Zuletzt bearbeitet:
Hallo mutlimolti

Grundsätzlich ist lua eine effiziente Sache, und gibt sich wohl kaum was mit anderen Scriptsprachen (Javascript, python usw). Aus deinem Posting wird mir nicht klar ob du die Scripts bei jedem neuen Telegramm aus der Datenbank lädst und interpretierst oder ob du das am Anfang ein mal machst. Falls ersteres: Dann hast du da ein Problem.

Ansonsten ist dein grösstes Problem mit lua nicht wirklich lua an sich sondern .NET. Du schreibst Parser für lua, also denke ich es wird intern die standardmässige (in C geschriebene) virtual machine von lua verwendet. Entsprechend hat diese virtual machine auch grundsätzlich keine Ahnung von verwalteten Objekten und kann auch nur mit unverwalteten arbeiten. Das heisst für dich, bzw den Parser, dass er alles was in das Script kommt und auch wieder von ihm zurück kommt (auch während der Ausführung aus deiner Applikation erfragte Objekte/Werte) durch den Marshaller lassen muss um dann unverwaltet damit arbeiten zu können. Das wird wohl alles in allem mehr Overhead erzeugen als die eigentliche Ausführung des Scripts.

Eine Alternative, die du dir überlegen kannst um die verwaltete Welt nicht verlassen zu müssen ist die dynamische Erstellung von verwalteten Assemblies (siehe: System.CodeDom.Compiler). Das ist nicht ganz trivial zu implementieren, aber dafür hast du wohl die schnellst mögliche Pluginmethode dann zu Hand. "Nachteil" ist, dass die Leute die Plugins in einer .NET-Sprache schreiben müssen.

Grüsse
Cromon
 
Hey!

Danke schon mal fuer die ausfuehrliche Antwort. Das Testszenario (der AluminumLua Parser), das ich jetzt implementiert habe, scheint KOMPLETT auf C#/.NET zu basieren, ich glaube dass der gar nichts sonst von Lua verwendet...

Ob ich die Skripts jedes mal neu lade oder nur einmal ist eigentlich egal, da der Nutzer das wahrscheinlich nicht sooo oft aendern wird. Und falls der das aendert und abspeichert, kann man dem C# Programm ja sagen, das einmal neu zu laden.

Was mir an dem AluminumLua auch gefallen hat: Ich kann einen Context erstellen, da mein Array mit den 32.000 Werten reinladen, und dann immer wieder verschiedene Skripte auf diesem Context ausfuehren, ohne den neu erstellen zu muessen.

Diese verwalteten Assemblies klingen sehr interessant, die werde ich mir mal genauer anschauen. Ob die Nutzer jetzt Lua oder .NET schreiben macht wohl kein Unterschied, da sie wahrscheinlich eh beiden neu lernen muessten....
 
Servus multimolti,

wenn du viel Wert auf schnelle Anfrageverarbeitung und hohen Durchsatz legst würde sich vielleicht für die Anfrageverarbeitung Node.js lohnen?
Vielleicht könntest du dann auch JavaScript als Scriptsprache für Anwender verwenden, weil du mit JS ja auch JS interpretieren und ausführen kannst. Inwiefern man sich natürlich vor Injektion von gefährlichem Code absichern kann müsste man natürlich schon schauen. Für deine Anwender wäre JS wohl einfacher zu lernen vermut ich mal..
Eine Alternative wäre natürlich über Node.js z.B. ein C# Programm aufzurufen dass die LUA Scripts interpretiert.

Viele Grüße,
Guillermo
 
Wenn wir schon von Node.js sprechen kannst du auch auch relativ umkompliziert Javascript mit deiner C#-Anwendung verwenden:
Stichwort eben: v8

Aber alles in allem bist du mit lua sicher nicht schlecht aufgehoben. Ich hab mir AlluminiumLua mal angesehen und muss sagen, dass die Sache nicht übel aussieht. Klar hast du mit .NET gewisse Performanceeinbussen gegenüber C, allerdings bist du bei diesen mit Sicherheit nicht im Bereich 100ms, wenn du dir etwas Mühe gibst.

Grüsse
Cromon
 
Hi!

Dieses AluminumLua war zwar auf den ersten Blick toll, aber ich bin recht schnell auf ein Problem gestossen, als ich versucht habe, in Lua eine Schleife (for) zu verwenden. Nach langer Suche habe ich den Entwickler kontaktiert und der hat mir bestätigt, dass bisher kein Support für Schleifen in AluminumLua ist... damit fällt diese Option zumindest (derzeit) für mich weg. Und eine andere (schnelle) Lua-Lösung gibt's nicht, oder?

Das NodeJS werde ich mir auch mal anschauen, aber ansonsten fahre ich mit dem C# CodeDom.

Danke für eure Hilfe!
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück