Google Wave on ollut viime aikoina aika kuollut, mutta päätin silti kokeilla tämän keskustelun inspiroimana oman wave-palvelimen pystyttämistä. Tämä osoittautui täysin mahdolliseksi seuraavilla komponenteilla:

• Ubuntu 9.10
• ejabberd (XMPP-palvelin)
• Google Wave Federation Prototype Server

Tämä wave-palvelin ei tarjoa Google Waven kaltaista webbikäyttöliittymää, vaan XMPP-pohjaisen rajapinnan, johon voi ottaa yhteyttä wave-clientillä. Softan mukana tulee konsolipohjainen clientti, joka näkyy oheisessa kuvakaappauksessa.

Federaation juju on siinä, että jossain vaiheessa oikeasta Google Wavestakin voi avata minun itseni hostaamia waveja ja osallistua niissä käytäviin keskusteluihin. Esimerkiksi tämän blogin kommenttikeskustelut voisi tarjoilla waveina, joita voi seurailla ja joihin voi osallistua Google Wavesta tai mistä tahansa muustakin wave-järjestelmästä käsin.

Se on vielä minulle vähän epäselvää, miten blogissa voisi tarjota kommentointimahdollisuuden kunkin omaa wave-tiliä käyttäen. Pitäisi kai olla jokin linkitystapa, joka avaa kyseisen waven Google Waveen tai johonkin muuhun wave-järjestelmään.

Apple saa paljon vihoja siitä, etteivät iPhone ja iPad tue Flashia. Mutta nyt Flash-tuki on disabloitu myös Firefoxin Maemo-versiosta. Taustalla on Flash-pluginin kehno toimivuus monilla saiteilla:

The Adobe Flash plugin used on many sites degraded the performance of the browser to the point where it didn’t meet our standards. If you wish to enable our experimental plugin support, you will be able to manually via about:config, but do so at your own risk.

Mielestäni Appleenkin kohdistettu badwill on nyt syytä kohdistaa todelliseen syypäähän eli Adobeen, joka ei tunnu saavan aikaiseksi toimivia Flash-plugineja oikein millekään alustalle.

Minulta kesti hetken selvittää, että Chrome 5 -selainta ei saa Macille vielä beta-channelin kautta, vaan se pitää asentaa dev-channelista. Nämä molemmat kanavat löytyvät Googlen Early Access Release Channels-sivulta.

Toisin sanoen kyseessä ei ole vielä beta-versio (tämän hetkinen Mac-beta on 4.x) vaan kehitysversio. Otin kuitenkin käyttöön Chrome 5.0.307.1 devin ja huomasin ilokseni, että tässä versiossa on mukana Bookmark Sync. Chrome osaa nyt kirjautua Google-tunnuksilla sisään ja synkronoida kirjamerkit eri koneiden kesken.

Täytyy kokeilla hetken aikaa, onko dev-versio riittävän stabiili käyttää. Aiempaan beta-versioon voi palata suhteellisen helposti lataamalla vain Chromen uudelleen beta-channelista ja vetämällä sen vanhan päälle. Preferenssit ja historiat saattaa joutua tyhjentämään.

Halusin palauttaa käytössäni olleeseen N900-puhelimeen tehdasasetukset ja poistaa kaiken henkilökohtaisen informaation. Tämä osoittautui haastavammaksi kuin osasin odottaa.

Käytännössä koko laite täytyy fläshätä uudelleen näiden ohjeiden mukaan. Fläshäys tapahtuu kahdessa osassa: ensin asennetaan uudelleen käyttöjärjestelmä ja sitten "vanilla data image". Operaatio tehdään komentoriviohjelmalla.

Lisäbonuksena Nokian flash-3.5-työkalu ei toimi Windows 7:ssä (eikä tiettävästi Vistassa), koska se käyttää unsigned-ajureita. Niiden asentaminen vaatisi PC:n buuttaamisen jotain nappulaa pohjassa pitäen. Itse en viitsinyt tähän lähteä, vaan käytin suosiolla netbookkini Ubuntu 9.10:tä. Ilmeisesti flash-työkalu toimii myös Mac OS X:ssä, mutta ei ollut Maccia käden ulottuvilla.

Viime aikoina Node.js on vilahdellut vähän väliä web-maailman blogeissa. Itse olen lukenut lähinnä tämän esittelyn, mutta se riitti kiinnostumaan aiheesta.

Node.js:n perusajatuksena on viedä selaimista tuttu JavaScriptin asynkroninen luonne palvelinpuolelle. Jokainen web-suunnittelija on joskus kirjoittanut tämän tapaisen koodinpätkän:

var msg = 'Sekunti kului';
setTimeout(function() {
    alert(msg);
}, 10000);

Idea on, että selain ei jää 10 sekunniksi jumiin odottelemaan ajan kulumista. Sen sijaan se ajastetaan setTimeout()-funktiolla jatkamaan ohjelman suoritusta 10 sekunnin kuluttua. Odottelun aikana skripti ei kuluta selaimen resursseja millään lailla. Erityisen tärkeää on, että skriptiä varten ei tarvitse varata omaa dedikoitua prosessia tai säiettä CPU:sta täksi ajaksi.

Closurejen ansiosta msg-muuttuja on edelleen käytettävissä, kun skriptin ajo jatkuu 10 sekunnin kuluttua. Tämä tekee asynkronisesta ohjelmoinnista JavaScriptillä yksinkertaista ja selkeää.

JavaScript palvelinpuolella

Kuvitellaan, että ylläoleva skripti ajetaankin palvelinpäässä ja se tekee pelkän odottelun sijasta tietokantahaun, joka kestää 10 sekuntia. Lopuksi se palauttaa vastauksen HTTP-pyyntöön. Oletan tässä, että tietokantahaku tehdään CouchDB:hen REST-pyyntönä jQueryn avulla:

jQuery.getJSON('http://.../_view/recent', function(data) {
    response.sendHeader(...)
    response.sendBody('<html>....</html>');
});
// Oikeasti tätä ei tehtäisi Node.js:ssä jQueryllä.

Mekanismi on täsmälleen sama kuin selaimen JavaScriptissäkin. Sillä välin kun REST-pyyntöön odotellaan vastausta, skripti ei varaa dedikoitua prosessia tai säiettä. Se aktivoituu vasta sitten, kun tietokanta lopulta palauttaa vastauksen hakupyyntöön.

Tämä tarkoittaa, että palvelin voi käsitellä tuhansittain yhtaikaisia hakupyyntöjä, jotka eivät jää varaamaan prosesseja tai säikeitä CPU:sta. Tyypillinen prefork-Apache-palvelin taas pystyy palvelemaan vain noin 100-200 yhtaikaista pyyntöä, koska jokaiselle luodaan erillinen prosessi koko pyynnön ajaksi.

Ei MySQL:lle?

Asynkronisen web-palvelimen edellytys on, että sivuja muodostettaessa käytetään asynkronisia I/O-operaatioita. Tämä tarkoittaa yleensä lähinnä tietokantapyyntöjen tekemistä non-blocking-yhteyksillä. Pyyntö lähetetään ensin tietokantapalvelimelle, jonka jälkeen ei jäädä odottelemaan vastausta, vaan pannaan ohjelma nukkumaan kunnes vastaus saapuu joskus myöhemmin.

CouchDB:lle tämä malli sopii mainiosti, koska se toimii natiivisti juuri näin. Tietokantahaku lähetetään ensin CouchDB:lle HTTP-pyyntönä, ja jonkin ajan kuluttua siihen saadaan HTTP-vastaus.

Mikä parasta, CouchDB toimii sisäisestikin ilman säikeitä. Yhtaikaisten asiakkaiden määrälle ei ole sinänsä rajoitusta. Pyyntöjen käsittely vain kestää vähän pitempään, kun palvelin kuormittuu.

MySQL:n client-protokolla on taas suunniteltu blokkaavaksi ja se muodostuu monesta eri vaiheesta. Asiakas lähettää ensin handshake-paketin johon palvelin vastaa vastaavalla paketilla. Sitten asiakas lähettää autentikointipaketin ja odottelee jälleen vastausta. Sitten lähetellään erilaisia prepare- ja execute- ja fetch-paketteja ja odotellaan aina kuhunkin vastausta. Yhteyden muuttaminen asynkroniseksi vaatisi koko asiakaskirjaston ja sen rajapintojen uudelleensuunnittelun puhtaalta pöydältä.

Tämän lisäksi MySQL toimii sisäisesti säiepohjaisesti. Kun uusi asiakas avaa siihen yhteyden, asiakkaalle luodaan säie yhteyden ajaksi. Näitä säikeitä voi olla vain tietty määrä yhtaikaa käynnissä. Jos pitkäkestoisia kyselyitä kasaantuu riittävästi, uudet asiakkaat eivät pääse enää sisään ja palvelin alkaa herjata virheilmoituksia.

Miksi säikeet ovat huono juttu

Tämän koko asynkronisuuden pihvi on siinä, että säikeet (kuten prosessitkin) ovat raskaita. Käyttöjärjestelmiä ei ole suunniteltu siten, että palvelinohjelmat voisivat luoda tuhansia tai kymmeniä tuhansia säikeitä asiakkaita palvelemaan. Jokaiselle säikeelle täytyy pitää yllä esimerkiksi erillistä stack-muistialuetta ja muuta kontekstitietoa, ja niiden skedulointiin ja context-switchaamiseen kuluu ylimääräistä prosessoriaikaa.

Asynkroninen I/O taas on huomattavasti kevyempää, koska muistissa pidetään käyttöjärjestelmän puolesta lähinnä muutaman tavun kokoisia deskriptoreita/pointtereita per yhteys. Linuxin epoll-rajapinta on suunniteltu siten, että yhteyksien määrällä ei ole nopeudelle suoraan merkitystä, koska deskriptorit ja callback-funktiot etsitään O(1)-algoritmeilla. Palvelinsofta voi huoleti ladata epoll-rajapintaan kymmeniä tuhansia rinnakkaisia I/O-operaatioita, ja odotella sitten kaikessa rauhassa niiden valmistumista.

Django tallentaa normaalisti salasanat SHA1-hasheina, joissa on mukana myös 5-merkkinen salt. Mutta jos salasanoja replikoi jostain toisesta systeemistä Djangoon, ne voi tallentaa myös MD5-hasheina tai ilman salttia. Tämä tarkoittaa, että melkein mistä tahansa tyypillisestä web-pohjaisesta käyttäjärekisteristä on suhteellisen helppoa replikoida käyttäjätunnukset ja salasanat Djangoon.

Djangon itse luoma salasanakenttä näyttää tietokannassa suurin piirtein tältä:

sha1$abcde$9f228544172d611cbfb5b8c7111f51aac0a166ba

Kentässä on siis peräkkäin algoritmi (sha1), salt (abcde) ja itse hashi (9f228544172d611cbfb5b8c7111f51aac0a166ba) dollarimerkeillä eroteltuna.

Jos oletetaan, että legacy-järjestelmässä on käytetty pelkkää MD5-hashia ilman saltteja, niin siellä tietokantakenttään on tallennettu luultavasti jotain tällaista:

5f4dcc3b5aa765d61d8327deb882cf99

Tämä voidaan replikoida suoraan Djangoon kirjoittamalla salasanakenttä tietokantaan tässä muodossa:

md5$$5f4dcc3b5aa765d61d8327deb882cf99

Vanha salasana toimii nyt normaalisti sisäänkirjautumiseen. Kun salasanaa sitten joskus vaihdetaan, se korvautuu uudella SHA1-hashilla, jossa on salt mukana.

PS. Papukaijamerkki kaikille hakkereille, jotka osaavat päätellä tuosta, mitä salasanaa käytin esimerkeissä. ;-)

Apple julkaisi äsken odotetun iPadin, mutta wow-faktori jäi puuttumaan. Laite tekee periaatteessa ihan samaa kuin aiemmatkin netbookit ja tabletit: antaa surffata nettiä, kirjoittaa sähköpostia ja lukea e-kirjoja.

Toisaalta alkuperäinen iPhone oli ihan samanlainen julkistus. Se ei ollut ensimmäinen kännykkä, jossa oli kosketusnäyttö tai webbiselain. Sen sijaan se oli ensimmäinen kännykkä, jossa nämä ominaisuudet toimivat todella hyvin.

Näkisin iPadin samanlaisena tuotteena. Se toteuttaa netbookien ja tablettien tyypilliset käyttötarkoitukset niin hyvin, että iPadin jälkeen ei enää huvita koskeakaan Microsoftin jumitteleviin kynätabletteihin tai Asuksen hitaisiin ja painaviin netbookkeihin. Apple on perinteisesti aina onnistunut optimoimaan käyttöjärjestelmän nopeuden hardwaren tasoa vastaavaksi. Ja iPad painaa 680g siinä missä kaikki netbookit ovat järjestään yli 1kg.

Itse olen tottunut kanniskelemaan mukanani 1140g painoista Eee PC 901:tä (asennettuna Chromium OS ja Ubuntu 9.10). Lisäksi tarvitsen yleensä virtalähteen ja Wekkulan 3G-yhteyttä varten. Niin ja 290g painoisen Kindlen e-kirjojen lukemiseen.

Jos pienen ja kevyen iPadin akku kestää koko päivän ja yksi laite korvaa nämä kaikki vermeet laukussani, vaihdan kyllä siihen. Varsinkin jos Amazonin Kindle for iPhone toimii iPadissa yhtä hyvin kuin Applen oma iBooks.