Motivation bei Privatprojekten (Split aus Diamond of Death)
-
Wenn die Plugins eigene Prozesse sind, stehen dir prinzipiell alle Möglichkeiten der IPC offen. Wenn du dich auf C++ beschränken willst, wäre Boost.Interprocess sicher anschauenswert. Dort kannst du über shared memory auch (fast) beliebige Objekte austauschen.
Prinzipiell ist es aber sowieso sinnvoller, ein Plugin-Grundgerüst zur Verfügung zu stellen, das die Kommunikation mit dem Bot kapselt. Dann kann man auch einfach z.B. auf Sockets umsteigen, indem man einfach das Grundgerüst ändert.
-
314159265358979 schrieb:
Außerdem wird die Thread-Variante eine geringere Latenz haben.
Die Latenz zwischen Bot und Plugin wird in jedem Fall gering genug sein gegenüber der Latenz zwischen Bot und IRC-Server.
Wenn zwei Prozesse auf demselben PC lokal über ein Socket kommunizieren, ist die Latenz quasi Null.
-
ipsec schrieb:
Wenn die Plugins eigene Prozesse sind, stehen dir prinzipiell alle Möglichkeiten der IPC offen. Wenn du dich auf C++ beschränken willst, wäre Boost.Interprocess sicher anschauenswert. Dort kannst du über shared memory auch (fast) beliebige Objekte austauschen.
Shared memory ist doch unter vielen Betriessystemen über das Dateisystem gelöst, wäre das nicht ziemlich langsam gegenüber Sockets?
ipsec schrieb:
Prinzipiell ist es aber sowieso sinnvoller, ein Plugin-Grundgerüst zur Verfügung zu stellen, das die Kommunikation mit dem Bot kapselt. Dann kann man auch einfach z.B. auf Sockets umsteigen, indem man einfach das Grundgerüst ändert.
Gute Idee. Das muss ich mir mal durch den Kopf gehen lassen.
-
314159265358979 schrieb:
ipsec schrieb:
Wenn die Plugins eigene Prozesse sind, stehen dir prinzipiell alle Möglichkeiten der IPC offen. Wenn du dich auf C++ beschränken willst, wäre Boost.Interprocess sicher anschauenswert. Dort kannst du über shared memory auch (fast) beliebige Objekte austauschen.
Shared memory ist doch unter vielen Betriessystemen über das Dateisystem gelöst, wäre das nicht ziemlich langsam gegenüber Sockets?
Ich glaube du verwechselst das mit memory-mapped files. Und selbst die sollten schnell genug sein, da sie ja (wie der Name sagt) in den Arbeitsspeicher gemappt sind.
-
314159265358979 schrieb:
ipsec schrieb:
Wenn die Plugins eigene Prozesse sind, stehen dir prinzipiell alle Möglichkeiten der IPC offen. Wenn du dich auf C++ beschränken willst, wäre Boost.Interprocess sicher anschauenswert. Dort kannst du über shared memory auch (fast) beliebige Objekte austauschen.
Shared memory ist doch unter vielen Betriessystemen über das Dateisystem gelöst, wäre das nicht ziemlich langsam gegenüber Sockets?
Lokale Sockets bei Unix-ähnlichen Systemen kann man auch über das Dateisystem laufen lassen. Das ist überhaupt nicht langsam, weil "Dateisystem" hier nicht heißt, dass die Festplatte irgendwie daran beteiligt wäre. Das läuft alles im RAM ab.
"Im Dateisystem" kann man so sehen: Anstelle, dass man lokale listening Sockets nur anhand ihrer Port-Nummer finden kann, kann man Sockets auch sprechende Namen geben, zum Beispiel "/var/run/foo". Auf das Socket namens /var/run/foo zu verbinden ist einfach nur etwas sprechender als auf "localhost:1234" zu verbinden, das ist alles. Von der Geschwindigkeit her gibt sich das alles nichts, zumindest im Rahmen eines IRC-Bots.
-
Na dann ist das ja gut.
Bleibt die Frage, ob Sockets oder Shared Memory.Sockets haben den Vorteil, dass ich auch in anderen Sprachen Plugins schreiben könnte. Ist shared memory performanter oder hat er andere Vorteile?
-
Privat-Projekte scheitern auch daran, das sie perfektioniert wollen. D.h. man arbeitet ewig lange dran, ohne Ende, weil einem immer was auffällt/einfällt, was verbessert werden kann. Das Problem ist nur, es gibt von Menschen nichts perfektes!
Da ist es also gut, wenn man z.B. jemand dabei hat oder benennt, der einem auch mal sagt "Jetzt ist aber Schluss! Lass das Programm jetzt endlich mal auf die Menschheit los!". Bei beruflichen Projekten ist da immer der Auftraggeber oder das knappe Budget, das einem einen Schlussstrich vorgibt.
-
314159265358979 schrieb:
Na dann ist das ja gut.
Bleibt die Frage, ob Sockets oder Shared Memory.Sockets haben den Vorteil, dass ich auch in anderen Sprachen Plugins schreiben könnte. Ist shared memory performanter oder hat er andere Vorteile?
Wenn performanter, dann nicht in einem Ausmaß, das du irgendwie bemerken wirst. Der Hauptvorteil von shared memory ist Bequemlichkeit, da du dort gleich die Objekte austauschen kannst.
-
Was tut man denn, wenn sich ein Plugin aufhängt, und der Bot sich dann beendet? Eigentlich sollte doch der Bot dafür verwantwortlich sein, dass alle Plugins beendet/gekillt werden.
Edit: Evtl. SIGTERM zu allen Plugins schicken und in den Plugins einen Handler dafür installieren?
-
314159265358979 schrieb:
Edit: Evtl. SIGTERM zu allen Plugins schicken und in den Plugins einen Handler dafür installieren?
SIGTERM beendet auch ohne speziellen Handler das Programm. Wenn du sichergehen willst musst du wahrscheinlich erst SIGTERM senden und dann nach einem timeout SIGKILL, denn SIGTERM kann ignoriert werden.
-
Aufgeräumt werden muss ja trotzdem, darum würde ich dafür einen Handler installieren, der diese Arbeiten durchführt. Natürlich so, dass der Nutzer davon nichts mitbekommt. SIGKILL werde ich sowieso senden müssen. Dazu muss ich aber irgendwie an die pids rankommen. Vielleicht eine Art "Registrierung" beim Bot.
-
314159265358979 schrieb:
SIGKILL werde ich sowieso senden müssen.
Nein, SIGKILL musst du nur senden, wenn ein Plugin SIGTERM ignoriert hat. SIGKILL sollte auf keinen Fall normales Verhalten sein.
314159265358979 schrieb:
Dazu muss ich aber irgendwie an die pids rankommen. Vielleicht eine Art "Registrierung" beim Bot.
Genau das ist die Frage. Eine simple Methode wäre, dass der Bot die Prozesse selber startet, dann hat er die process id nämlich automatisch.
-
Lolz
Ihr diskutiert hier über ein (IMO unnötiges) Sicherheits-Feature das ein theoretisches Projekt deutlich komplizierter machen würde, wobei ursprünglich gefragt war, ob es (das theoretische Projekt) einfach genug wäre um als Hobbyprojekt umgesetzt zu werden.@314159265358979:
Vermutlich etwas grenzwertig was "einfach genug" angeht, aber noch im grünen Bereich.
Aber wie sieht's mit der Motivation aus? Was willst du damit dann machen? Wieso C++? ...?Wenn du einfach nur ein paar eigene Bots haben willst, um diese zu verwenden, dann nimm PHP/C#/Java/..., und frickel dir damit deine Bots zusammen.
Ansonsten... woher soll die langfristige Motivation kommen, falls es dir nicht darum geht nen IRC Bot zu verwenden?
-
hustbaer schrieb:
Aber wie sieht's mit der Motivation aus? Was willst du damit dann machen?
Im IRC gibt es diverse Bot-Hoster, die verwenden alle IRC-Bots, die in Sprachen wie TCL geschrieben sind und dadurch saulahm. Ich wills besser machen.
hustbaer schrieb:
Wieso C++? ...?
Weil C++ eine orentliche, flotte Sprache ist. Java werde ich auf meinem VServer sicherlich nicht installieren und Interpreter-Sprachen sind mir zu langsam oder unterstützen keine Threads.
hustbaer schrieb:
PHP
Ich hatte (habe) ürsprünglich einen PHP Bot, der zur Laufzeit Befehle hinzufügen konnte. (PHP Code ins IRC, in ne Datei schreiben und danach laden.)
Datenbanken konnte er auch. Allerdings ist er ein hässliches, unwartbares, langsames Monster geworden. Außerdem kann PHP keine Threads, was für Sachen wie Timer erforderlich ist.hustbaer schrieb:
/C#/Java/...
Das würde mich erstens nicht stolz machen und zweitens halte ich von diesen Sprachen nicht besonders viel. (Auch wenn ich sie beide kann.)
hustbaer schrieb:
Ansonsten... woher soll die langfristige Motivation kommen, falls es dir nicht darum geht nen IRC Bot zu verwenden?
Mir geht es darum, endlich mal ein Projekt umzusetzen, und vor allem Threads mal anzuwenden. Und, wie oben schon genannt, einen flotten Bot zu haben.
-
314159265358979 schrieb:
Im IRC gibt es diverse Bot-Hoster, die verwenden alle IRC-Bots, die in Sprachen wie TCL geschrieben sind und dadurch saulahm. Ich wills besser machen.
Es würde mich schon arg wundern, wenn ein TCL-Bot langsam ist, weil er in TCL geschrieben ist. Ich hab mal einen kleinen IRC-Bot in Python geschrieben und die Plugins dafür in Bash. Und Bash ist nun so ziemlich die langsamste Sprache überhaupt, weil für fast jede Code-Zeile ein neuer Prozess gestartet werden muss. Das ist um Größenordnungen langsamer als jede gängige Skriptsprache. Der Bot hat keine spürbare Latenz.
-
@Christoph
ACKEin TCL/PHP/Perl/C#/Java/... Bot ist dann saulahm und/oder ein unwartbares Monster, wenn er scheisse geschrieben ist. Nicht weil er in TCL/PHP/Perl/C#/Java/... geschrieben ist.
--------------
314159265358979 schrieb:
Im IRC gibt es diverse Bot-Hoster, die verwenden alle IRC-Bots, die in Sprachen wie TCL geschrieben sind und dadurch saulahm. Ich wills besser machen.
s.o.
Weil C++ eine orentliche, flotte Sprache ist.
Das trifft auf C#, Java und z.B. Lua auch zu. Und PHP/Perl/... sind zwar nicht wirklich "flott", aber sicher "flott genug".
Java werde ich auf meinem VServer sicherlich nicht installieren
Weil?
und Interpreter-Sprachen sind mir zu langsam
s.o.
oder unterstützen keine Threads.
Sind auch nicht wirklich nötig, gibt ja noch Prozesse und asynchrone APIs.
Ich hatte (habe) ürsprünglich einen PHP Bot, der zur Laufzeit Befehle hinzufügen konnte. (PHP Code ins IRC, in ne Datei schreiben und danach laden.)
Datenbanken konnte er auch. Allerdings ist er ein hässliches, unwartbares, langsames Monster geworden.s.o.
Außerdem kann PHP keine Threads, was für Sachen wie Timer erforderlich ist.
Nicht unbedingt erforderlich.
Das würde mich erstens nicht stolz machen
Dagegen kann ich jetzt nicht viel sagen. Ausser dass ich es für sinnlos halte, sich das Leben unnötig schwer zu machen, indem man das falsche Werkzeug für eine Aufgabe verwendet.
und zweitens halte ich von diesen Sprachen nicht besonders viel. (Auch wenn ich sie beide kann.)
Ich glaube nicht dass du *wirklich gut* Java und/oder C# kannst. Zumindest nicht gut genug, um beurteilen zu können, was von Java oder C# "zu halten ist"
Mir geht es darum, endlich mal ein Projekt umzusetzen,
Das alleine ist nach meiner Erfahrung zu wenig.
und vor allem Threads mal anzuwenden.
Reicht auch nicht dafür ein Projekt wirklich *fertig* zu machen. Sobald man sieht, dass man das, was man lernen wollte/einsetzen wollte gelernt/eingesetzt hat, ist der Dampf raus.
Und, wie oben schon genannt, einen flotten Bot zu haben.
Wie schon gesagt: dafür brauchst du kein C++. Und IMO auch nicht unbedingt Threads. Obwohl sie u.U. nicht schaden werden.
(Wobei Threads die Sache eher einfacher machen, die "echte Herausforderung" wäre das alles ohne Threads zu machen, aber so, dass es trotzdem flutscht und 100 Bots gleichzeitig hosten kann )
-
hustbaer schrieb:
Ich glaube nicht dass du *wirklich gut* Java und/oder C# kannst. Zumindest nicht gut genug, um beurteilen zu können, was von Java oder C# "zu halten ist"
Ich habe angefangen, die STL in Java zu implementieren. (Zumindest das Design habe ich versucht, möglichst ähnlich zu halten.)
Ich kann dir Code liefern, wenn du darauf bestehst, ich kann diese Sprachen gut genug. (Wobei ich Java besser kann.)Es würde meinen Stolz verletzen, den Bot nicht in C++ zu schreiben.
-
In Java wäre es viel zu einfach - da fehlt die Herausforderung.
-
antijava schrieb:
In Java wäre es viel zu einfach - da fehlt die Herausforderung.
Einer ders kapiert hat - hurray!
-
314159265358979 schrieb:
hustbaer schrieb:
Ich glaube nicht dass du *wirklich gut* Java und/oder C# kannst. Zumindest nicht gut genug, um beurteilen zu können, was von Java oder C# "zu halten ist"
Ich habe angefangen, die STL in Java zu implementieren. (Zumindest das Design habe ich versucht, möglichst ähnlich zu halten.)
Das sagt mir eigentlich nur, dass du Java als "way of doing it" einfach nicht verstanden hast
(Oder nicht akzeptiert, nur die Unterscheidung ist irrelevant, wenn es darum geht ob du beurteilen kannst was die Sprache "taugt")Es würde meinen Stolz verletzen, den Bot nicht in C++ zu schreiben.
Dann mach mal. Du hast das Thema ja schon ne gute Zeit lang ins Auge gefasst. In der Zeit müsstest du das längst fertig haben. Ist ja kein extrem grosses Projekt.
Halte dich an das Motto "just do it".
Überleg nicht tagelang rum wie du dieses oder jenes designen könntest, was du hier oder da noch feilen könntest/hübscher machen etc.
Setzt dich einfach hin, überleg dir ein grobes Konzept wie die einzelnen Teile zusammenspielen sollen ("Design"), und dann implementier es. Geh' beim Erstellen des Konzepts/Designs nicht zu sehr in die Tiefe, sieh lieber zu dass du die Breite vollständig abdeckst.
Und wie gesagt: implementier es.
Auch dabei wieder: nicht zu sehr auf Perfektion achten.Und zwar aus mehreren Gründen: erstmal fehlt dir für "Perfektion" einfach die Erfahrung. Und dann, selbst mit 10+ Jahren Erfahrung bekommt man es auch nie "perfekt" hin. Alle möglichen Lösungen haben Vor- und Nachteile, diese "perfekt" gegeneinander abzuwägen und dann den "perfekten" Kompromiss zu finden, ist einfach unmöglich.
Gut genug ist gut genug
Und beim nächsten mal hast du mehr Erfahrung, und machst weniger Fehler. Oder zumindest andere Fehler.Aber eins ist sicher: wenn du nie was fertig machst, dann kannst du auch kaum wertvolle Erfahrung sammeln. Oder anders gesagt: die Grösse der Projekte die du umsetzen kannst, ohne dass am Ende ein "unwartbares Monster" rauskommt, wird vermutlich nicht wachsen.
Noch eins:
Ein Projekt fängt damit an, dass man sich genau überlegt was es können/tun soll. Und vor allem: es niederschreibt.
