HIVEnet und Seriennummer als ID

[digger]

Hab mal meine Vorstellungen skizziert. Aber da gibts noch einige dicke Ungereimtheiten deren Lösung mich aber sehr reizt ... bin schon kräftig dabei mir Gnutella und Co. zur Brust zu nehmen.

[sid]

evtl. kann ich einen hive für wenig geld (ist ja nicht viel stromverbrauch - evlt sponsoring vom provider) im rechenzentum unterbringen. Sowas können wir dann aber besprechen wenn das System läuft

[digger]

Danke ... also ich glaub wir werden mehr primäre Nodes mit statischer Adresse haben als andersrum. Wir haben hier ebenfalls Zugriff auf ein Rechenzentrum mit 3 Carrier-Einspeisungen, da können wir HIVEs ohne Ende stationieren und redundant über verschiedene Routing-Wege und in verschiedenen IP-Segmenten anbinden.

Heutzutage haben ja wirklich viele IT-(interessierte)-Leute über den einen oder anderen Weg Zugriff auf heftige Internet-Ressourcen ... ich denke wir können uns voll und ganz auf die Programmierung unserer Ideen konzentrieren, der Rest kommt dann.

[laserjones]

Mann, wenn ich jemals eine Firma gründen sollte, stelle ich euch alle ein. Das ist ja echt Wahnsinn, wie hier die Kreativität sprießt. Vor zwei Tagen habe ich das HIVEnet erstmals in diesem Forum als Idee erwähnt, und heute legt digger schon ein erstes Konzept vor ... und das freiwillig!

[Rainer]

Gute Ausarbeitung, digger.
Was mir aber noch abgeht wäre ein "Broadcast" an alle Hives. Auch kann ich mit deinem jetzigen Konzept nicht am mehrere Drohnen gleichzeitig dieselbe Nachricht senden, da für die Empfänger-ID ja nur 4 Byte vorgesehen ist. Ich kann also nicht an alle Hives Weltweit ein "Heute gibts Freibier bei digger im Garten" schicken (was Dir wahrscheinlich eher Recht ist ).
Spam können wir ja wahrscheinlich in einem so privaten Netz ausschließen. Sollte also kein Problem sein.

Oder habe ich da was überlesen in Deinem PDF ?

Was noch cool wäre, wenn man ein System integrieren könnte, bei dem ich eine Zeitlang unabhängig von primären Drohnen sein könnte. Wenn jede Drohne seine nächsten beiden Nachbarn kennt, kennt jeder jeden. Irgendwie sollte also jede Drohne jede andere nach dem Ziel fragen können, wenn die primären nicht da sind (warum auch immer). Das geht natürlich nur, wenn mind. 1 sekundäre online war bevor die primären ausgefallen sind. Failover ist immer gut
Neu online kommende Drohnen haben dann natürlich schlechte Karten. Ist ja kein fixes erstes Ziel da ... aber die Drohnen die online waren vor dem Ausfall der primären könnten normal weitermachen. Naja, ist vll. ein bißchen sehr "konstruiert". Kann ja eigentlich kaum vorkommen, da genug primäre Drohnen.

[EDIT]
Was mir gerade so einfällt. Da alle Drohnen ja Softwaretechnisch "Gleiche unter Gleichen" sind, könnte eine primäre Drohne eine sekundäre Drohne zur primären "promoten" wenn zuwenig andere Primäre online sind. Wenn diese ehemals sekundäre Drohne vom Netz geht, wirds halt eine andere.
[/EDIT]

Gruß.
Rainer

[digger]

Du kannst ja den HIVE deine Nachbarn bei dir einfach als primäre Drohne anlegen. Dann müsste man sich noch Bedingungen und ein System überlegen ob und wie diese dann an andere Drohnen verteilt wird.
Da sich das ganze HIVEnet ja über verschiedenste Wege selbst aktualisieren soll, muss man sicher noch jeden Eintrag mit einer Seriennummer versehen um von mehreren gleichen Einträgen der Drohneliste zu erkennen welches der aktuellere ist. (Falls eine primäre irgendwann wieder zu einer sekundären gemacht wurde oder ähnliches).

Broadcast ist cool und einfach zu regeln, dafür können wir einfach eines der Flag-Bits nehmen. Wenn es gesetzt ist wird der Empfänger ignoriert und die Nachricht bei alle den primären Drohnen bekannten Nodes abgelegt ... ich bau es noch in den Plan ein.

Inzwischen ist mir noch vieles eingefallen was ich nicht bedacht habe .. Verfallsalter einer Nachricht etc.

Gruss digger

[Cromax]

vielleicht koennen wir ja ein kleines tool basteln, welches seinen aktuellen status zum beispiel an diese seite uebermittelt. wenn dann jemand einen neuen hive gebaut hat, schaut er einfach hier nach, sucht sich eine node raus und gibt die in seinem hive ein und schon ist er im hivenet und kann sich alle anderen infos ziehen ..

vielleicht koennte man auch unterschiedliche kommunikationswege einbauen .. wenn ein hive ueber seine gespeicherten adressen einfach keine verbindung bekommt, koennte er ja auch eventuell zum beispiel per email nachfragen .. einfach einen kleinen mailclient entwickeln der auf anfrage von einem hive seine adressdaten zurueckschickt .. oder per jabber =) also dass man andere netze als reserve benutzt .. sodass wirklich jeder hive eine verbindung findet .. prioritaet sollte natuerliche das hauseigene hivenet .. nur wenn halt ein neuer hive ins netz will, sollte es mehrere einfache moeglichkeiten geben, kontakt mit dem hivenet aufzunehmen und dafuer wird halt erst mindestens ein kontakt benoetigt und dieser sollte moeglichst einfach und schnell realisierbar sein

[laserjones]

vielleicht koennen wir ja ein kleines tool basteln, welches seinen aktuellen status zum beispiel an diese seite uebermittelt. wenn dann jemand einen neuen hive gebaut hat, schaut er einfach hier nach, sucht sich eine node raus und gibt die in seinem hive ein und schon ist er im hivenet und kann sich alle anderen infos ziehen ..

Dann wäre es doch noch besser, eine ganz simple Webseite (oder auch nur eine FTP-Datei) unter einer festen URL abzulegen, wo die IPs der aktuellen primären Drohnen zeilenweise abgelegt sind. Die kann sich ein neuer HIVE dann eigenständig runterladen, wenn wir die URL ins Betriebssystem einbauen. Im Idealfall muss er das dann nur einmal im Leben tun.

Idealerweise könnten die primären Drohnen diese Liste sogar eigenständig aktuell halten, indem sie sich dort an- und abmelden (was mit FTP wohl einfacher wäre als mit HTTP). Allerdings müsste dann auch der Fall abgedeckt sein, dass eine Drohne ungeplant ausfällt, ohne sich abzumelden. Die anderen Primären müssten also regelmäßig die ganze Liste auf Erreichbakeit durchprüfen. Oder ein Tool auf dem Webserver pingt die Liste durch und löscht nicht erreichbare.

Das Ganze durchbricht zwar wieder etwas die Idee vom "reinen" HIVEnet, aber da es sich im Grunde nur um eine Komfortfunktion für Neueinsteiger (und um ein absolutes Worst-Case-Fallback) handelt, hätte ich dagegen nichts einzuwenden. Andererseits könnte man argumentieren, dass man diese seltenen Fälle (neuer HIVE oder Ausfall aller primären Drohnen) dann eher manuell abwickelt wie im vorigen Beitrag vorgeschlagen und das HIVE-Betriebsystem frei von festen URLs hält. Ist eine Frage der Philosophie - für mich persönlich wäre beides OK.

[Cromax]

mittlerweile gefaellt mir persoenlich auch die idee mit dem jabber server am besten .. jabber ist auch absolut dezentral .. jeder der moechte koennte dieses jabbertool auf seinen hive installieren und auf der website wird angezeigt welche jabber-id's gerade online sind .. kommt ein neuer hive, fragt der nach einer aktiven jabber-id .. der nutzer geht auf die seite, sucht sich eine aktive jabber-if raus und gibt die auf seinem hive ein und schon erhaelt dieser alle informationen, die er braucht, inklusive der anderen jabber id's, falls er mal laenger vom netz sein sollte oder sich aus irgendeinem anderen grunde, alle seine bekannten hive adressen nicht mehr gueltig sind und schon fragt er ueber seine bekannten jabber-id's die aktuellsten informationen ab .. jabber ist auch komplett opensource und hat sowas rebellisches ein im gegen alle anderen wuerde gut zum hive passen finde ich und waere eine gute loesung fuer ein "ausfallsystem" oder ein "erster-einstieg-system" =)

[drohne235]

Interessante Ideen. Der erste Schritt wird aber sein zu untersuchen was der TCP/IP-Stack überhaupt alles kann und was evtl. noch fehlt. Ich habe davon überhaupt keine Ahnung und wollte es ja aus diesem Grund mal wirklich auf unterer Ebene ergründen. Und nicht zu vergessen: Der Netzwerkcode selbst muß erst noch in Administra integriert werden. An sich keine große Sache, es könnte höchstens vom Platz ein wenig eng werden, müssen wir mal schauen. Aber man muß immer sehen das der momentane Stand der Entwicklung "Werkstattniveau" hat, d.h. ich habe von unten angefangen einzubauen was ich für meine Experimenten und Tests brauchte. Das mußte nicht alles optimal sein sondern in vertretbarer Zeit funktionieren, also besteht da noch sehr viel Potential zu optimieren. Am liebsten wäre mir ja noch ein dynamischer Code wie bei Regnatix und Bellatrix, so das man ihn zur Laufzeit austauschen kann. Das ist eigentlich kein Problem das zu realisieren, aber ich habe noch nicht die elegante und einfache Variante gefunden wie für die beiden anderen Chips. Aber das kommt noch, da bin ich ganz sicher.