schwierigkeiten mit aktueller netpd-strukur

viele aufgaben, die für netpd sehr wichtig sind, beispielsweise die synchronisation aller einstellungen der patches, passiert im moment auf der client seite. da vordergründig alle clients als gleichwertig behandelt werden, tatsächlich aber jeweils ein client zum chef erhoben wird, gibt es probleme, wenn dieser chef ausfällt (-> absturz, verbindung weg usw.), da dessen aufgaben von niemandem mehr übernommen werden. ein solches system ist nicht optimal einfach, da gegen aussen alle als gleichberechtigt erscheinen sollen, intern aber ein chef bestimmt wird, der bei ausfall ersetzt werden müsste, was nur mit viel nutzlosem traffic zu realisieren wäre (frage an den chef:bist du noch da? alle 5s oder so) zudem muss jeder client potenziell genug intelligent sein, um die chefrolle übernehmen zu können, obwohl diese 'fähigkeit' gar nicht benutzt wird.

client based -> server based

grundsätzlich kann man sagen, dass es viel komplizierter ist, wenn viele gleichberechtigte sich untereinander selbst organisieren müssen. dies geht vielleicht auch nur dann, wenn die gleichberechtigten unter sich einen chef ausmachen. da aber diese gleichberechtigten auch nur menschen sind (sie können krank werden, arbeitsunfähig werden, sterben), führt der ausfall eines gleichberechtigten in chef-position zum ausfall des ganzen systems.
besser wäre es, man würde die aufgaben des chefs nicht an einen gleichberechtigten delegieren, sondern eine neue uebermenschliche instanz schaffen, welche die chef-aufgaben übernimmt. bezogen auf ein client-server-system, wie es netpd ist, wäre der server diese uebermenschliche instanz. der server ist insofern übermenschlich, dass ohne ihn gar nichts mehr geht. für die gleichberechtigten würde dies bedeuten, dass sie effektiv alle gleichberechtigt wären, da sie alle untertanen des servers würden. auch dürften die gleichberechtigten relativ dumm sein, da sie nie mehr die chefrolle einnehmen müssten.

wie würde ein solches server basiertes system in netpd aussehen?

der server würde deutlich mehr aufgaben übernehmen, als er es bis anhin getan hatte. die patches würden zuerst auf den server geladen und der server würde sie dann an alle weiteren clients verteilen. dump-anfragen würden immer an server geschickt. ein patch würde immer zuerst auf dem server geöffnet, dadurch wäre garantiert, dass für die client ein ansprechpartner vorhanden ist.

vorteile einer server basierten struktur

• kein chef mehr nötig
• -> es kann kein chef mehr ausfallen

// kommentar von charlie: naja, wenn der server chef ist kann der genau so ausfallen, wie jeder andere auch. nur halt mit verheerenderen folgen.

• viel weniger traffic, da jeder client nur noch mit server kommunizeren muss
• patches, die einen chef benötigen (wie mx) können einfacher realisiert werden
• keine anfrage-rückanfrage-geschichte mehr nötig, da die patches immer zuerst auf dem server geöffnet würden. aktuelle probleme, welche verusacht werden durch unterschiedliche reihenfolgen, wie patches geöffnet werden, wären behoben.
• automatisches versionen-check-system wäre einfacher zu realisieren.

nachteile

• standalone betriebsfähigkeit wäre schwieriger zu implementieren

// kommentar von charlie: das würde ich nicht umbedingt sagen, eine einfache lösung wäre es, in den creator oder so einen kleinen "online" toggle zu bauen der entscheidet, ob der netpd-server im netz genutzt wird, oder auf dem eigenen rechner einer gestartet wird; man wird also selbst zum server, einen client gibt es vorerst nicht (man kann anderen natürlich die eigene ip mitteilen, und sie so teilhaben lassen). das hätte unter umständen zufolge, dass das netpd-paket direkt mit serverpatch an user ausgeliefert wird.

//// kommentar von enrique auf // kommentar von charlie:
ich denke das würd ganz gut funktionieren.

//// kommentar von enrique auf // kommentar von charlie:
dies würde jedoch zu einer totalen abhängigkeit von creator führen. bedenke creator hatte früher nur(<- im positiven sinn) die aufgabe ein patch rauf/runter zu laden und zu öffnen. ist es nicht wunderbar wenn aufgaben so transparent definiert sind?


//// kommentar von roman
(diese diskussion hätten wir vielleicht trotzdem lieber im forum geführt.. wobei hier geht es eingetlich auch ganz gut.)
eni: es wäre nicht eine totale abhängigkeit von creator, sondern netpd-system wäre dann in erster linie eng mit server verknüpft. klar wäre dies auch eine abhängigkeit vo creator, wenn dieser die serverfunktion für standalone-betrieb übernehmen müsste....

• der server wäre deutlich mehr absturzgefährdet, da alle patches auch server geöffnet würden.

// kommentar von charlie: okay, das wird in der tat ein problem werden, da die sicherheit stark gefährdet ist, wenn jeder durch fehlerbehaftete oder gar böswillige patches (viele arten pd zu crashen sind bekannt) den server lahmlegen kann. eine kleine maßnahme wär es, die patches so zu entwickeln, dass sie auch in eine art server-mode starten können, also ohne gui, ohne dsp, nur das was nötig ist, um den laden am laufen zu halten (das würd zwar meinem obigen beispiel für standalone server-sessions widersprechen, aber es gibt bestimmt für alles eine lösung.

// kommentar von enrique: man könnte alles filtern und nur subpatches und netpd-abstractions zulassen. auch könnte man netpd abs für den server-user auf die x (dump) funktionen beschränken. ok mir fiel grad auf dass das wohl in patches die netpd-abs dynamisch erzeugen nicht möglich ist (ev qseq2).

kommentare? ergänzungen? bitte einfach reinschreiben....

gruss roman

//kommentar von charlie: bei genauerer betrachtung wird aus meinem traum einer anarcho-kommunistischen revolution wohl eher eine server-diktatur. netpd, beherrscht von einer maschine...

// kommentar von enrique auf client based -> server based : grundsätzlich ist es komplizierter wegen dem chef, der meiner meinung nach nicht zwingend nötig ist. ich glaub dass ein gutes anarcho system möglich ist variante 3 (ohne delays und ohne doppelte dumps).

//kommentar von enrique auf schwierigkeiten mit aktueller netpd-strukur:
gehen wir mal ein Schritt zurück. abgesehen von user die später dazukommen läuft netpd perfekt (bitte korrigieren wenn ich falsch liege). in einer perfekten welt, in der niemand abstürzten würde und alle von anfang an dabei wären, hätten wir KEINE PROBLEME. nun die frage ist wieviel energie, zeit und verkomplizierung (sorry dieses wort gibts nicht) ist gerechtfertigt um dieses problem zu anzugehen (nicht davon zu sprechen wieviel aufwand roman schon dafür betrieben hat). eine verkomplizierung könnte auch unvorhersehbare neue probleme hervorrufen.

mich stört der gedanke wegen diesem (blöden) problem soviel arbeit zu machen und schon gemacht haben (hier wieder einmal danke an roman)

mein hauptanliegen ist dass wir erstmal nichts überstürzen. am liebsten hätte ich wenn wir alle möglichen varianten notieren ev. auch vor und nachteile. dann ev. demokratisch abstimmen? und wenn möglich zusammen entwickeln.

ich bin mir klar dass der neue auch eine liste bekommen muss welche patches schon offen sind. ich hab mich damit nie richtig beschäftigt glaube aber dass wir damit auch nie probleme hatten (in keinen systemen seit netpd-x)

variante 1
name :
- übermenschchef (server diktatur)
idee, problem & vorteil :
- siehe oben

variante 2
name :
- anarchistische handarbeit
idee :
- weglassen des chef systems . dump manuell ausführen [; netpd-x dump(.
- dies könnte ev auch von einem anderen user gemacht werden was mich zu variante 3 führte
probleme :
- neuer müsste im chat einen user fragen ob er auf den dump-bang drücken könnte
vorteil :
- wenn jemand offline war könnte jemand der online'r auf den dump-bang drücken (oder umgekehrt)

variante 3
name :
- erweitertes kommunistisches system
idee :
- weglassen des chef systems. neuer user tut sich selbst auf default settings. dann dumpprereq und erste socket die antworted ein dumpreq. eigentlich wie erstes x-system ich seh aber nicht warum man hier ein delay braucht.
probleme :
-
vorteile:
-

variante 4
name :
- spiegel welt (abgeänderte server diktatur)
idee :
- server hat ein user am laufen der chef ist, alle patches aufmacht aber alle objecte rausfiltert ausser netpd- abs auch wären die netpd- abs auf x sachen reduziert .
problem :
- unvorhersehbare probleme
- erzeugte netpd-abs (was wohl der grund sein wird dass dieses system nicht geht)
vorteil :
- weniger netzverkehr
- ich bin sicher es gibt noch weitere vorteile

variante 5
name :
- ?
idee :
- ?
problem :
- ?
vorteil :
- ?

// kommentar von enrique randbemerkung : mir gefällt diese art dialog. es wird wohl richtig voll hier.

KIS : keep it simple Mike

it makes music and it sings songs Mark

isn't that what it's all about ?

YO HOMI.... danke euch, charlie und eni, für eure kommentare......

ohne chef gehts nicht. es ginge bei netpd-x, wenn man das system abschaffen würde, dass patch immer einen dump braucht. das problem ist, dass der erste (init-)-dump gebroadcastet wird. wenn man einen zusätzlich kanal einführen würde, also init-dump nicht über netpd-broadcast, sondern intern. so könnte man zumindest verhindern, ein delay verwenden zu müssen, da man dann einfach mal (ohne potentiellen anderen usern die presest zu zerstören) sich selbst dumpen könnte. trotzdem wäre ein solches system nicht sauber. denn wären schon einige leute am sounden und ein neuer kommt hinzu, dann würden die patches des neuen dumprequest an alle anderen clients senden und die würden dann alle einen dump schicken (sind ja dann alle gleichberechtigt). ich finde diese variante deswegen sehr unschick. ich finde chef-variante nicht perfekt, aber edler gelöst.

// enrique
ich glaube der erweiterte kommunismus geht. es ist wäre das letzte netpd system biz verändert. folgerndermasen : 1. (init-)-dump intern 2. sowas wie ein showall machen um socket zu bekommen mit dem man dann die erste socket um ein dump fragen kann.
scheint mir edel und sauber. bitte um kommentare

//// roman
yo, hast ja voll recht. fast genau so war es ja früher, ein neuer fragte nämlich, wer alles da ist und schickte dann dem ersten, der sich gemeldet hat, einen dumprequest. nur war das problem, dass wenn keiner antwortete, er irgendwann mal einen init-dump senden musste. wenn man aber diesen init-dump auf loadbang und intern machen würde, dann bräuchte man nicht zu warten auf die antwort, ob andere noch da seien. will sagen, intern sich selbst dumpen und altes system wäre vielleicht gescheiter als das aktuelle chef-system.

grundsatzfrage 1: wieviel aufwand nur für usability?

ein system kann für den user gar nicht genug einfach zu bedienen sein. ich finde sogar (gut, ich übertreibe jetz ein wenig), eine verbesserung der usability rechtfertig jeden aufwand. ich vertrete vehement die meinung, dass es lohnt, sich gedanken darüber zu machen, wie man netpd noch userfreundlicher einerseits, und auf der anderen seite transparenter, was die internas angeht, machen könnte.

// enrique
ich stimm dir 100% zu dass es sich lohnt gedanken zu mache und neue systeme zu besprechen.
...wie man netpd noch userfreundlicher einerseits, und auf der anderen seite transparenter...
nicht zu letzt netpd selbst stabil zu machen

grunsatzfrage 2: lohnt es sich noch, weiterhin alles (netpd-abs, creator, server..) diskret getrennt zu halten?

aus einem gefühl heraus, wäre es mir irgendwie lieber, wenn man alles getrennt halten könnte. aber diese idee zum grundprinzip zu erheben wäre vermutlich nicht intelligent. dieses prinzip muss hinterfragt werden: was für gründe rechtfertigen dieses prinzip? bringt dieses prinzip aus user-perspektive irendwelche vorteile? könnte man gewisse probleme einfacher lösen, wenn man dieses prinzip aufgeben würde? ich will mich hier nicht für das eine oder andere entscheiden, aber sich solche fragen zu überlegen ist sicher nicht schädlich. ich selber muss mir immer wieder bewusst machen, dass netpd vermutlich ganz anders aussehen würde, hätten wir/ich es heute geplant. es ist was anderes, wenn man einem bestehenden system immer wieder neue features hinzufügt, als wenn man ein system von grund auf neu plant mit allen gewünschten features. viel dinge in netpd sind heute so, weil sie zum zeitpunkt der implementierung so gut in das bestehende system passten. es ist aber auch berechtigt zu fragen, ob man nicht vielleicht das system so anpassen will, dass sich gewünschte features einfacher implementieren lassen.

// enrique
weiterhin alles (netpd-abs, creator, server..) diskret getrennt zu halten?...
...ich will mich hier nicht für das eine oder andere entscheiden...
was ist das andere ? keine netpd-abs und creator und server in einme patch ? ich würde gerne über neue ideen diskutieren verstehe deine hier aber nicht.

//// roman
mit diskret meine ich: netpd-abs bieten NUR netpd-funktionalität, creator tut NUR patches rumschieben und server tut NUR messages an andere weiterleiten, also strikte aufgabentrennung. alternativ dazu könnte man sich eine struktur vorstellen, bei der diese trennung aufgehoben würde (was jetzt schon bisschen der fall ist, da creator und netpd-x miteinander reden). bei der server basierten variante wäre dies ja ganz stark der fall, da der server ebenfalls für netpd-funktionalität zuständig wäre (dump kriegte man vom server) und auch mit creator kommunizieren würde (die patches würde man auch beim server anfordern).

yoyo, roman