Research and Development 1/^Archief/2009-2010/14/Implementatie van server-to-server en dialback

• 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.
• "Verslag" komt niet voor in de lijst (Logboek, Planning, Projectpagina, Pilot, Fase 1, Fase 2, Groepspagina, Feedback) met mogelijke waarden voor de eigenschap "Type".

Inleiding

Na het specificeren van de grootste delen van server-naar-servercontact en dialback zijn we overgegaan op het implementeren van die delen, en van daaraf de rest. Omdat we meer systematisch te werk wilden gaan in ons onderzoek dan we in het verleden deden, zetten we de resultaten van onze pogingen na het afmaken van de implementatie op deze pagina.

Opmerkingen vooraf

Daar waar de XMPP-versie leeg is gelaten, had een server geen version-attribuut in zijn <stream:stream>-element. Dit mag volgens de specificatie niet, maar servers zijn wel verplicht om het te ondersteunen. Waarschijnlijk is de Google Wave Sandbox-server zo vervelend mogelijk ingesteld, zodat servers tenminste voorbereid zijn op servers die de randjes van de specificaties opzoeken. Servers met een lege XMPP-versie sturen ook geen features. Daar waar geen XMPP-versie vermeld is, zal als feature wel dialback gebruikt worden, maar niet TLS. Dit wordt dan tussen haakjes weergegeven, maar is geen feature zoals gerapporteerd door de server.

Testopstelling

Deze tests zijn gedaan door middel van revisie 74 van de RUWave-repository. Het daadwerkelijke testprogramma is zeer klein en is te vinden in trunk/common/xmpptest. Dit programma maakt voor al zijn functionaliteiten gebruik van de klassen van QXmpp, waarvoor de versie uit de SVN-repository benodigd is. Deze versie is te vinden in trunk/common/qxmpp; door QXmpp volgens de aldaar gegeven qmake-instructies te compileren zal XmppTest ook correct functioneren.

Omdat veel servers een betrouwbaar SSL-certificaat vereisen, is dat te gebruiken met dit programma. Verder moet de luisterpoort altijd te bereiken zijn op de XMPP-server van het domein. Zie voor meer informatie de specificatie server-to-servercontact. In deze testopstelling werd gebruik gemaakt van de MacBook Pro van Sjors, met OS X 10.6.3; door middel van een SSH-tunnel werd al het verkeer van de XMPP-poort van dazjorz.com doorverwezen naar de laptop, omdat anders dialback nooit correct kan verlopen.

Methode

Steeds werd in XmppTest in de code aangegeven naar welke server verbonden is. In de tabel hieronder is te zien welke servers geprobeerd zijn. Daarna is uit de output van het programma via zowel stdout als het bestand "server.log", gekeken wat er over en weer gezonden werd. Deze gegevens zijn in de tabel opgenomen en naar aanleiding van alle output wordt er een inhoud gegeven aan de "Gelukt"-kolom.

Resultaten

Domein	Hostname	XMPP-versie	Features	Gelukt?	Opmerkingen
wavesandbox.com	xmpp-server.l.google.com		(dialback)	Ja	Geen TLS, want xmpp pre-1.0.
wave24z.com	wave24z.com	1.0	starttls,dialback,sasl[],compression[zlib]	Nee	Dialback-request verstuurd, controle vond nooit plaats en antwoord kwam ook niet, om onbekende redenen.
acmewave.com	primary.acmewave.com	1.0	starttls,dialback[optional]	Ja	Dialback was optioneel, dus niet uitgevoerd.
wave.dazjorz.com	dazjorz.com (naar zichzelf)	1.0	starttls,dialback	Nee	Wegens een bug in de implementatie ging de tweede handshake fout.
rtbserver.ath.cx	ruwave.org	1.0	starttls,dialback,sasl[]	Ja	Zelfde probleem als bij wave24z.com (zelfde software): Dialback-request verstuurd, controle vond nooit plaats en antwoord kwam ook niet.

Aanvankelijke conclusie

De tests verliepen minder goed dan verwacht. De verbinding met de server wave24z.com werd goed opgezet, maar die server had onze identiteit moeten controleren en daarop moeten antwoorden, maar dat gebeurde niet. Daarnaast zijn er waarschijnlijk enkele bugs in de implementatie waardoor de verbinding naar rtbserver.ath.cx (domein ruwave.org) niet lukte; daar moeten we nog naar kijken. In ieder geval is de conclusie op dit moment: de implementatie klopt op de meeste punten en kan met belangrijke servers een goede verbinding opstellen. We zullen proberen de bovengenoemde problemen nog op te lossen, maar willen daarmee niet te veel tijd verliezen, zodat we PubSub op tijd kunnen implementeren volgens de planning.

Interessante gebeurtenissen tijdens de tests

We waren er al eerder achter dat de server achter wavesandbox.com zich soms eigenaardig gedraagt. Daarbij hebben we een aantal ontdekkingen gedaan.

Onverwachte Dialback-requests

Bij het uitvoeren van een dialback-verificatie bij de Authoritive Server, stuurt de Google Wave Sandbox-server zelf ook een dialback-request. Dit waarschijnlijk omdat die server al verwacht die verbinding zelf ook veilig te willen gebruiken, en zichzelf alvast laat authentificeren zodat dat later goed kan.

Echter, de server authenticeert niet alleen zichzelf (wavesandbox.com), maar ook gmail.com. Dit komt waarschijnlijk omdat de specifieke server waarmee wij verbinding hadden, zowel Google Wave als Google Talk (Jabber) serveert. Beide protocollen werken via XMPP, en kunnen dus gebruik maken van dezelfde server. Door op deze manier verbindingen op te zetten, zijn er minder verbindingen nodig om data over te sturen tussen netwerken.

Dit probleem werd al meteen netjes afgehandeld door onze implementatie.

Stream actief houden op een niet-standaardcompliant manier

Elke minuut stuurt de Google Wave-server wat whitespace, zo zagen wij in onze serverlogs. Naar verwachting is dit om de stream actief te laten blijven. XMPP heeft extensies voor het actief houden van streams, "XMPP Ping" genaamd. Daarop hoort de andere kant dan een berichtje terug te sturen, zodat beide zijden weten dat de verbinding nog intact is. De Google-server doet dit dus op een aparte manier - veel implementaties zullen deze "keep-alive" niet eens in acht nemen, aangezien er geen geldige XML-stanza's in staan. Deze methode houdt echter geen extra problemen in voor ons.

Een plotseling 'presence'-bericht

Nadat de met Dialback geauthenticeerde stream opgezet was tussen de Google-servers en dazjorz.com, bleek Google na tien minuten plotseling een 'presence'-bericht te versturen. Dit bericht is bedoeld voor Jabber-clients, om zo de "beschikbaarheid" van een contactpersoon aan te geven: online, afwezig, bezet, offline etc. Omdat Google verbonden dacht te zijn met de "echte dazjorz.com-server", stuurde Google een bericht aan contactpersoon dazjorz@dazjorz.com; dit bericht werd door onze server genegeerd maar het was wel heel mooi om te zien dat de server praktisch al in het netwerk opgenomen was.

01:29:23.428 PROT IN >>
<presence from="nathansamson@gmail.com/Home9819763E" type="unavailable" to="dazjorz@dazjorz.com"/>
<<
01:29:23.428 DEBUG presence is not interesting

Connection timeouts

Wij hadden het al eerder gemerkt en dit bevestigde het: servers gedragen zich heel anders op het gebied van connection timeouts. Zoals al hierboven beschreven stuurt Google elke minuut wat whitespace om de verbinding actief te houden. Andere servers, met name OpenFire-servers, waren standaard zo ingesteld om gedurende lange tijd (minstens een uur) hun verbindingen open te houden. De server 'primary.acmewave.com' voor het domein 'acmewave.com', was de eerste server die wel duidelijk een maximale tijd had:

PROT IN >>
<stream:error><connection-timeout xmlns='urn:ietf:params:xml:ns:xmpp-streams'/></stream:error></stream:stream>
<<
DEBUG stream:error is interesting
WARNING Unknown error condition connection-timeout - emitting as unknown error
PROT OUT >>
</stream:stream>
<<
INFO Disconnected