Research and Development 1/^Archief/2009-2010/14/Aanvankelijke problemen in fase 1

• Property "Auteur1" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/14Gebruiker:Sjors Gielen" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
• Property "Auteur2" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/14Gebruiker:Rob ten Berge" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
• Property "Auteur3" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/14Gebruiker:Hans Harmannij" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
• Property "Auteur4" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/14" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
• Property "Type" (as page type) with input value "{{{type}}}" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.

Terwijl Hans werkte aan permanente opslag, hebben Rob en Sjors volgens de planning gewerkt aan het verbinden met andere Google Wave Federation-servers. Hierbij hebben we behoorlijk veel tegenslag gehad. Deze pagina is bedoeld om deze tegenslag te bewaren voor latere referentie.

Onduidelijke documentatie

Het feest begon met de onduidelijke documentatie. Google Wave bouwt voort op XMPP Core, maar XMPP Core is heel vaag op het gebied van server-naar-servercommunicatie - het enige dat het zegt is welke "XML Namespace" gebruikt moet worden bij het opzetten van de verbinding. Voor de rest wordt niets gezegd; dat is misschien expres gedaan, om de mogelijkheden zo groot mogelijk te maken, maar dan zou je verwachten dat de service die voortbouwt op XMPP Core wel specifieker is. Dat is niet het geval: de draft-specificatie van Google Wave praat over het bestaan van een "Host" en "Remote", in principe twee servers die communiceren, maar vertelt niets over communicatie tussen die twee.

Verbindingen met andere servers

Volgens de specificatie moeten twee servers die met elkaar willen communiceren meteen een beveiligde verbinding opzetten, door middel van TLS. Voor TLS zijn certificaten vereist. Die zijn in principe makkelijk te maken, maar omdat servers de identiteit van andere servers controleren door middel van die certificaten, moeten het "gecontroleerde" certificaten zijn. Die controle vindt plaats door derden, vaak voor een hoog bedrag. Daarbij wordt de gratis variant "CACert", die controle uitvoert op basis van vertrouwen vanuit de community, wegens veiligheidsoverwegingen niet geaccepteerd door veel servers. Er is een enkele certificate authority, StartSSL, die gratis certificaten uitgeeft voor XMPP-servers. Die wordt gebruikt door veel verschillende XMPP-servers, en hebben wij ook gebruikt. Het duurde echter lang voor we de certificaten klaar hadden staan.

Na een lange tijd proberen is het ons gelukt om een beveiligde verbinding op te zetten met andere servers, als servers. Hiervoor hebben we ook flink in de QXmpp-library gegraven en dingen veranderd, om een speciale server-to-servermodus toe te voegen, waarmee de verbinding zich anders gedraagt als in client-to-servermodus. Nu hadden we eindelijk volledige ondersteuning voor beveiligde verbindingen... maar de officiële Wave Sandbox-server ondersteunt geen beveiligde verbindingen. We hebben een bericht van het Google-team uit november gevonden waarin men zei dat dat expres was om dingen beter te kunnen testen, en dat TLS binnen een paar weken alsnog aangezet zou worden. Dat is echter niet gebeurd, en hiermee wijkt die server volgens ons af van de al zo onduidelijke specificatie.

Daarnaast specificeert een XMPP-extensie het bestaan van een "service discovery". Verschillende bronnen doen erop wijzen dat Wave Federation-servers deze service moeten aanbieden, maar als wij een "service discovery"-aanvraag sturen, krijgen we daar geen antwoord op. We hadden toch tenminste een "dat snap ik niet"-antwoord verwacht, maar die komt helaas niet.

Wij wilden dan graag zien wat twee servers normaal naar elkaar sturen. Ondanks dat we dat geprobeerd hebben, is het niet gelukt om een degelijke dump van dat verkeer te krijgen. De verbinding gebruikt TLS, maar als je de gehele sessie op bestand hebt plus de keys die daarbij horen, moet het mogelijk zijn om met de tool ssldump toch dat verkeer te krijgen; dat wilde echter ondanks vele pogingen niet lukken. Het programma zei dat de data niet gedecrypt kon worden zonder verder te vertellen waarom, ondanks dat wij de juiste keys ingevoerd hadden. Wij hebben daarnaast ook geen andere mensen gevonden die zo'n dump konden geven vanaf hun al werkende Wave-server.

Daarom wilden wij, stukje bij beetje, een mini-Waveserver bouwen die steeds een ge-hardcodet antwoord geeft, om te zien wat andere Wave-servers daarop sturen. Pas na lange tijd kregen we andere servers zover naar ons te verbinden. Dit lukte door een Wave-service te declareren op het domein "dazjorz.com", met SRV-records zoals in de XMPP-specificatie, en daarna op een bestaande Wave-server de gebruiker test1@dazjorz.com toe te voegen aan een wave. Daarop verbond die Wave-provider naar onze server, om via PubSub te vertellen over een nieuwe Wave. Het bleek echter dat door agressief optimaliseren de Wave-providers onthouden dat een server niet correct werkt, waardoor ze na een mislukte poging lang niet meer opnieuw proberen te verbinden. Het zou te tijdrovend worden om daarop te wachten per poging, dus dat idee hebben we ook laten vallen.

Uiteindelijk hebben we met sommige servers degelijke verbindingen op kunnen bouwen, die klaar waren voor verdere communicatie. Daarna liepen we weer tegen andere problemen aan.

Incomplete documentatie

De PubSub-specificatie zegt precies hoe zogenaamde nodes gepubliceerd kunnen worden, en hoe andere partijen op die nodes kunnen subscriben om op de hoogte gebracht te worden van events. De specificatie is expres vaag over die nodes, behalve dat het XML-structuren moeten zijn. Je zou daarom denken dat de Wave-specificatie daar dan specifieker over is, maar dat blijkt niet het geval te zijn. Er zijn, verspreid over verschillende documenten, veel voorbeelden te vinden van zo'n XML-structuur, zoals in het Wave Conversation Model.

Daar is te zien hoe een <conversation> bestaat uit verschillende <blips> en dergelijke. Er staat ook in die specificatie dat een hele Wave bestaat uit verschillende Wavelets, en dat die Wavelets weer bestaan uit verschillende Conversations. Echter, nergens in dat document staat waar het domein van PubSub werkelijk begint, en wat zo'n node precies is. Wij vermoeden dat een PubSub-node in het geval van Google Wave bestaat uit een lijstje <wavelet>-elementen die weer bestaan uit <conversation>-elementen, maar het staat verder nergens gespecificeerd en we hebben het nog niet kunnen vinden.

Al met al

We hebben wegens deze problemen slechts marginale vooruitgang geboekt, terwijl we er lang mee bezig zijn geweest. We kunnen beveiligde verbindingen opzetten met servers, maar weten niet wat we daarover moeten sturen. We gaan, om daar alsnog achter te komen, proberen bestaande Wave-implementaties door te lezen om te kijken hoe dat daar gedaan wordt. Hopelijk kunnen we zo de gaten in onze kennis alsnog aanvullen, en onze server netjes in het Wave-netwerk opnemen.