Verbesserung einer XMPP-Bibliothek für den Einsatz in verteilter Paarprogrammierung

Größe: px

Ab Seite anzeigen:

Download "Verbesserung einer XMPP-Bibliothek für den Einsatz in verteilter Paarprogrammierung"

Käte Buchholz
vor 8 Jahren
Abrufe

1 Verbesserung einer XMPP-Bibliothek für den Einsatz in verteilter Paarprogrammierung Diplomarbeit Henning Staib Tutor: Karl Beecher und Stephan Salinger

2 Inhalt - Ausgangssituation - Aufgabenstellung - Lösungsansätze - Bytestream Patch - weitere Patches - Auswertung 2

3 Ausgangssituation - Kommunikation von über das Netzwerk mittels XMPP - XMPP (Extensible Messaging and Presence Protocol) - XML basiertes Protokoll zum Austausche von Nachrichten, Statusinformationen und Daten zwischen den Teilnehmern des Netzwerkes - zusätzliche Dienste definiert in XEPs (XMPP Extension Protocols) - Service Discovery zum Auffinden von Diensten - Multi-User-Chat - Datenaustausch über Bytestream, In-Band Bytestream, Jingle 3

Teilnehmern des Netzwerkes - zusätzliche Dienste definiert in XEPs (XMPP Extension Protocols) - Service

4 Ausgangssituation Klient 1 Klient 2 Klient 3 XMPP- Server 1 XMPP- Server 2 XMPP- Server 3 Klient 4 Klient 5 Klient 6 Klient 7 Klient 8 Klient 9 4

5 Ausgangssituation - verwendet XMPP-Bibliothek - Probleme in die auf zurückzuführen sind - Pakete zum Hinzufügen und Entfernen von Kontakten können verloren gehen - Projektsynchronisation - über Jingle - keine Unterstützung für verbindungsorientiertes Protokoll (TCP) - fehlerhafte Ermittlung von IP-Adressen - lange Initialisierungsphase (~ 20s) - FileTransfer - kein Stream möglich (nur Datenaustausch mit festgelegter Länge) - nicht bidirektional - basiert auf Bytestream und InBand Bytestream die beides der Spezifikation nach unterstützen - keine separate Schnittstelle für Bytestream und InBand Bytestream - schlechtes Timeout-Management führt zu Verbindungsabbruchen 5

Initialisierungsphase (~ 20s) - FileTransfer - kein Stream möglich (nur Datenaustausch mit festgelegter Länge) - nicht bidirektional - basiert auf Bytestream und InBand

6 Einschub Probleme Jingle XMPP Server (Alice) (Bob) 6

7 Einschub Probleme Jingle XMPP Server Jingle / TCP (Alice) (Bob) 6

8 Einschub Probleme Jingle XMPP Server Jingle / TCP (Alice) falsche IP-Adresse Firewall (Bob) 6

9 Einschub Probleme Jingle XMPP Server (Alice) (Bob) 6

10 Einschub Probleme XMPP Server (Alice) (Bob) 7

11 Einschub Probleme XMPP Server direkte Verbindung (Alice) (Bob) 7

12 Einschub Probleme XMPP Server nur unidirektional (Alice) (Bob) 7

13 Einschub Probleme XMPP Server nur unidirektional (Alice) (Bob) 7

14 Einschub Probleme XMPP Server (Alice) nur unidirektional (Bob) 7

15 Einschub Probleme XMPP Server (Alice) nur unidirektional falsche IP-Adresse Firewall (Bob) 7

16 Einschub Probleme XMPP Server (Alice) (Bob) 8

17 Einschub Probleme XMPP Server indirekte -Verbindung (Alice) (Bob) 8

18 Einschub Probleme XMPP Server nur unidirektional (Alice) (Bob) 8

19 Einschub Probleme XMPP Server Timeout nur unidirektional Timeout (Alice) (Bob) 8

20 Einschub Probleme IBB XMPP Server (Alice) (Bob) 9

21 Einschub Probleme IBB XMPP Server IBB IBB (Alice) (Bob) 9

22 Einschub Probleme IBB XMPP Server IBB IBB nur unidirektional (Alice) (Bob) 9

23 Einschub Probleme IBB XMPP Server IBB IBB nur unidirektional nur <message>-stanzas keine Flusskontrolle wie bei <iq>-stanzas (Alice) (Bob) 9

24 Ausgangssituation - Probleme beim Open Source Projekt - letztes offizielles Release zunächst hauptsächlich von Jive Software Entwicklern vorangetrieben, seit 2008 der Community überlassen - wenig Aktivität der bestehenden Entwickler - bestehende Patches der Community werden ignoriert - restriktiver Zugang zur Entwicklergruppe - teilweise kein Wissen / Verantwortlichkeit für bestimmte Komponenten - über 70 offene Probleme im Bugtracker - Spezifikation bereits implementierter Komponenten hat sich geändert - dadurch veraltete bzw. fehlerhafte Implementierungen - mangelnde Code-Dokumentation - inkonsistente Strukturierung / Formatierung - verhältnismäßig Unit-Tests mit Abhängigkeit zu einem XMPP-Server 10

25 Aufgabenstellung - Verbesserung - Bytestream - Roster - Evaluation Jingle Startup - aufgrund der Komplexität und des Zeitrahmens verworfen - stattdessen IBB - InBand Bytestream - -Community - Wie kann die Community eines durch eine Firma kontrollierten Open-Source- Projektes reaktiviert werden? - Welche Erfolgschancen hat eine Abspaltung des Projektes? - Wie kann die Qualität der Entwicklerbeiträge einer Open-Source-Community gesteigert werden? - Mitarbeit in - Releases - Tests - Bugfixes - Reviews 11

26 Lösungsansätze - Entwicklung von Patches für - zielgerichtet auf Probleme von - genügen höheren Qualitätskriterien als bestehende die ignoriert wurden - Beachtung des Kontextes eines Problems - Ursache des Problems lösen, nicht Symptome - Unit-Test um zukünftige Fehler und Regressionen zu vermeiden - Aufnahme in die -Entwicklergruppe - Impulse zur Reaktivierung der Community geben 12

27 Bytestream Patch - Extrahieren der Schnittstelle für Bytestream - bietet Funktionalität über die Anwendung zum Dateitransfer hinaus - Verbesserung der Funktionalität - basierend auf aktuellem Stand der XEP-0065 Spezifikation - Konfigurierbarkeit - lokale IP-Adressen - Port - Verfügbarkeit des lokalen Proxy - Timeouts - Usability der Schnittstelle - Unit-Tests - testen der Funktionalität - Verbesserung der Wartbarkeit - einfacheres Einpflegen von Änderungen - Erstellung der Test-Schnittstelle Protocol - unabhängig von XMPP-Server-Implementierung - erlaubt Tests anhand der Protokollspezifikationen - Verbesserungsvorschläge für Spezifikation (XEP-0065) 13

28 Einschub public void shouldnegotiatesocks5bytestreamandtransferdata() throws Exception { // get Socks5BytestreamManager for connection Socks5BytestreamManager bytestreammanager = Socks5BytestreamManager.getBytestreamManager(connection); // create responses in the order they should be queried according to XEP-0065 // build discover info that supports the feature DiscoverInfo discoverinfo = creatediscoverinfo(targetjid, initiatorjid); discoverinfo.addfeature(socks5bytestreammanager.namespace); // return that is supported if target is queried protocol.addresponse(discoverinfo, Verification.correspondingSenderReceiver, Verification.requestTypeGET);... // build used stream host response Bytestream streamhostusedpacket = createbytestreamresponse(targetjid, initiatorjid); streamhostusedpacket.setsessionid(sessionid); streamhostusedpacket.setusedhost(proxyjid); 14

29 Einschub Protocol // return used stream host info as response to the bytestream initiation protocol.addresponse(streamhostusedpacket, new Verification<Bytestream, Bytestream>() { public void verify(bytestream request, Bytestream response) { assertequals(response.getsessionid(), request.getsessionid()); assertequals(1, request.getstreamhosts().size()); StreamHost streamhost = request.getstreamhost(); assertequals(response.getusedhost().getjid(), streamhost.getjid()); } }, Verification.correspondingSenderReceiver, Verification.requestTypeSET);... // call the method that should be tested BytestreamSession session = bytestreammanager.establishsession(targetjid, sessionid);... } // verify protocol flow protocol.verifyall(); 15

30 weitere Patches - InBand Bytestream Implementierung mit extrahierter Schnittstelle analog zum Bytestream Patch - Frühzeitiges Registrieren des RosterListeners - RosterListener nur bei Änderungen informieren Behebung seit langem bestehender Probleme in - Verbesserung des Delayed Delivery Parser - Verbesserung der Robustheit des Message-Parsers und I18N - I18N für Message Subjects 16

31 Auswertung - Reaktion der -Entwickler auf die Patches - Nutzerkonto für Bugtracker - Beginn von Code-Durchsichten - später Aufnahme in die nicht-öffentliche Gruppe Community Planning - Code-Durchsicht für Bytestream Patch wurde nicht abgeschlossen - Patch für RosterListener durchgesehen, aber dennoch nicht dem SVN hinzugefügt - weitere Patches führten zu keinen Reaktionen und auch keinen weiteren Code- Durchsichten - die beiden aktiven Entwickler waren anderweitig beschäftigt 17

32 Auswertung - Reaktivierung der Community - Analyse bestehender Abspaltungen (Forks) - ein bestehender Fork seit Juli 2009 nicht mehr weiterentwickelt - neuer Fork vom Februar 2010 kaum Aktivität und keine neuen Entwickler - Erstellung eines Dokumentes mit Richtlinien für -Entwickler - enthält Hinweise zu - Code-Formatierungen - der Package-Struktur - Qualitätskriterien für Patches - bewährten Entwicklungsmethoden - Erstellen von Unit-Tests - Erzeugung von Patch-Dateien - wurde mit -Entwicklern abgestimmt aber nicht veröffentlicht - Aufnahme neuer Mitglieder durch Mentorship-Programm geregelt - seit Oktober 2009 keine weiteren Entwickler hinzugekommen 18

33 Auswertung - Entwicklungen seit Juni Umstellung der Plattform-Software von Ignite Realtime - Verschiebung nicht-öffentlicher Dokumente in die öffentliche Gruppe Contributors - dadurch alle Dokumente unfreiwillig veröffentlicht - Erstellung eines Vorschlags für eine Roadmap zur Weiterentwicklung - wenig Reaktionen - keine Diskussion und Weiterentwicklung der Roadmap - im August 2010 Zugriff auf SVN - alle entwickelten Patches eingecheckt - alle damit verbundenen Bugtracker-Einträge geschlossen 19

34 Auswertung - Verbesserungen in - Entwicklung von Patches für kleinere Bugfixes - Code-Durchsichten - Umbau des Netzwerkmoduls von - Umstellung der Verwendung von Jingle/FileTransfer auf die Verwendung von Bytestream / InBand Bytestream - Zuverlässigkeit beim Herstellen von Verbindungen erhöht - Geschwindigkeit der Verbindungsherstellung erhöht - Reduzierung der Code-Komplexität - Verbesserungen an der Bytestream Spezifikation - gefundene und gemeldete Inkonsistenzen und Fehler behoben 20

35 Diskussion 21

36 Danke 22

Ähnliche Dokumente

Behandlung von Netzwerk- und Sicherheitsaspekten in einem Werkzeug zur verteilten Paarprogrammierung

Behandlung von Netzwerk- und Sicherheitsaspekten in einem Werkzeug zur verteilten Paarprogrammierung Institut Mathematik und Informatik - 15. April 2010 Agenda 1 Einleitung 2 Saros Architektur Daten senden