nachhaltigBeobachtet

Nochmal zum Thema dezentrale Vernetzung: eben ist mir ein weiteres Programm in die Finger geraten, welches teilweise verspricht, was Collanos Workplace nicht halten konnte. RetroShare verbindet Personen ohne zentralen Dienst - allerdings nur, wenn sich nicht beide hinter einem Firewall mit NAT befinden. Ansonsten braucht es einen RetroShare-Server mit fixer IP, welchen man selber aufstellen kann.

Retro Stuss @ 27.06.2007 14:10 CEST
Danke für den Hinweis, habe herausgefunden, dass KEIN Server notwengdig ist und RetroShare auch durch die Firewall und den Router verbindet, da jetzt UpnP dadrin ist.
Das war eine Fehlmeldung von der CT, dass RetroShare einen Server braucht. Nochmal: is ist völlig Serverlos und daher wird auch nix geloggt.
Sehr guter Messenger, der bald hoffentlich ICQ und Skype ersetzt.

Reto Stauss @ 27.06.2007 16:37 CEST
Danke für den Hinweis (wenn ich auch etwas skeptisch bin bezüglich Quelle). Und übrigens, orgineller Name.

Peter Helfenstein @ 13.07.2007 00:02 CEST
Hallo Reto
Etwas spät, doch noch ein etwas technischer Kommentar zum positiven, doch wegen dem zentralen Benutzerverzeichnis auch sehr kritischen Feedback zum Collanos Workplace in diesem und im Blog vom 18. Mai 2007:

1. Ports:
Der Collanos Peer kommuniziert mit seinen Kollegen, wenn nicht anders möglich, zu deren Port 80 (http), respektive zum Port 443 (https) des Servers mit den Benutzerprofilen (Central User Directory). Normalerweise macht diese Kommunikation auch durch "Feuerwände" kein Problem. Die Verbindung zu diesen Ports ist für die Browser bereits ermöglicht.
Ich denke, dass Collanos auf jeden Fall nicht mehr Probleme mit Enterprise Firewalls hat, wie skype und die meisten Instant Messenger.

Es mag daher etwas verwirrlich sein, wenn wir empfehlen, die Collanos Workplace die Kommunikation mit Port 9701 anderer Peers zu erlauben. Dies liegt jedoch daran, dass wenn die tcp-Verbindungen zu diesem Port der Kollegen eine effizienter sind als die Kommunikation zu Port 80.

2. Central User Directory, zentrale Services:
Die Einführung des Collanos Central User Directory ist effektiv ein Bruch mit der reinen p2p Archiektur der bisherigen Lösung. Wir legen die Benutzerprofile zum Zugriff durch alle User auf einem zentral Peer ab. Somit kann jeder Benutzer zu jeder Zeit herausfinden, wenn alles er zu seinem Team einladen kann, unabhängig ob die anderen Teilnehmer gerade online sind, oder ihr Profil schon mit ihm synchronisiert haben.

Der Kompromiss in gegenüber einer reinen p2p Architektur bringt dem Benutzer mindestens im Moment noch grössere Aktualität des Benutzerverzeichnis und die Möglichkeit, andere immer sofort einladen zu können, ob sie nun schon je gleichzeitig mit ihm online waren oder nicht.

Die Collanos p2p-Architektur, die auf Sun's Open Source JXTA Basis (http://www.jxta.org) aufsetzt, erlaubt uns den Aufbau einer reinen p2p Infrastruktur. Jeder Peer kann im Prinzip alle im Netzwerk notwendigen Rollen wahrnehmen, also bei Bedarf Services für alle anderen anbieten. Wir gehen zum Teil bewusst nicht so weit und stellen anfänglich selbst oder über Partner dedizierte Infrastruktur-Peers zur Verfügung. Hiermit können wir eine bessere Verfügbarkeit und anfänglich den Benutzern eine bessere Skalierbarkeit sicherstellen. Langfristig und mit etwas mehr Erfahrungen im weltweiten Einsatz können wir jederzeit auf solche Entscheide zurückkommen.

Es geht uns aber in erster Linie darum, ein kollaboratives Netzwerk zu schaffen, das die Vorteile von p2p für die User voll nutzt, andererseits dank gewissen Kompromissen in der Architektur keine grösseren Nachteile gegenüber Server-basierten Systemen in Kauf nehmen muss. Schade, dass die vielen starken Funktionen unserer "weitgehendst reinen p2p"-Teamplattform die Schatten der paar Kompromisse in der Architektur (noch) nicht überstrahlen! Wer weiss, vielleicht teilen wir doch mal einen Space im Collanos Netzwerk. Mich würde es freuen, herzlichen Dank für den Feedback.