docs/pws2009/anyevent.pod

=encoding utf-8

=head1 AnyEvent - Eine Welt ohne Religion

In diesem Vortrag möchte ich die neuesten Entwicklungen in Sachen
AnyEvent vorstellen (asynchrones IPv4/IPv6, asynchrones DNS, TLS uvm.), sowie
einige Hintergrundinformationen zu bestehenden Event-Modulen auf CPAN,
sowie Benchmarks, vorstellen.

Doch zuerst: der Titel klingt sicherlich etwas seltsam - was bedeutet er?

Nun, AnyEvent ist, wie im Namensteil "Event" steht, ein Event-Model
bzw. eine Event-Bibliothek.  Event-Module oder -Bibliotheken stellen
im allgemeinen Funktionalität bereit, mit derer man auf Ereignisse
(Events), warten kann, speziell Ereignisse der Art "Zeitpunkt soundso
ist erreicht" und "File Descriptor soundso kann jetzt nichtblockierend
gelesen/geschrieben werden."

Derartige Event-Bibliotheken gibt es zuhauf (Tk, Glib, Event, EV uvm.),
doch trotz der offensichtlichen Vorteile Event-basierter Programmierung
(z.B. beinahe automatische Parallelisierbarkeit) werden sie kaum in
CPAN-Modulen eingesetzt.

Meiner Meinung nach liegt der Grund schlicht darin, daß alle diese
Event-Bibliotheken exklusiv sind: sie dulden niemanden neben sich. Wie
bei den meisten Religionen auch, muss man sich einem dieser Modelle
ausliefern. Konkret bedeutet dies für Modul-Autoren: benutzt man
z.B. Glib in seinem Modul, muss auch jeder Benutzer dieses Modules Glib
benutzen, was natürlich eine starke Einschränkung darstellt, vor allem,
wenn das Modul selbst eigentlich nur "irgendwelche" Events benötigt, die
im Prinzip jede beliebige Event-Bibliothek liefert.

Einige Module auf CPAN haben versucht, aus dieser Not eine Tugend zu
machen: POE z.B. kann andere Event-Module als Implementation benutzen (in
der Praxis funktioniert das zwar nur mit einigen wenigen, aber die Idee
zählt). Lieder verschlimmert dies das Problem nur: POE z.B. verlangt
beinahe religiöse Glaubensbekenntnisse und ist kein bisschen kompatibler,
im Gegenteil: obwohl POE Backends für Gtk+ und Event besitzt, kann man
POE-Module nicht in einem Gtk+ oder Event-basiertem Programm benutzen:
setzt man POE in seinem Modul ein, so muss auch jeder Benutzer des Moduls
POE benutzen, sowie auch das Hauptprogramm selbst.

AnyEvent dagegen ist I<grundsätzlich> anders: Im Stile von anderen
C<Any*>-Modulen ist es lediglich eine Schnittstelle zu diesen. Dabei passt
es sich an jedes unterstützte Event-Modell an, ohne daß sich die API
ändert. Das bedeutet, daß man getrost Module benutzen kann, die AnyEvent
benötigen und intern auch benutzen, aber der Benutzer des Moduls sieht
davon erstmal nichts und kann jede beliebige Event-Bibliothek benutzen.

AnyEvent ist 100% Pure-Perl, und kommt mit eigener, schneller,
Event-Bibliothek, so daß auch auf Systemen, wo kein anderes Event-Modell
verfügbar ist eventbasiert Programmiert werden kann.

=head2 AnyEvent am Beispiel AnyEvent::CouchDB

Ein gutes Beispiel dafür ist C<AnyEvent::CouchDB>. Außer im Namen,
kommt AnyEvent in der API dieses Moduls nicht vor. Eine einfache
Datenbankabfrage sieht dementsprechend auch ganz langweilig aus:

   my $data = $db->view('users/all', { key => 'b' })->recv

Obwohl die Abfrage selbst Ereignisgesteuert ist, muss man als Benutzer
des Moduls kaum darunter leiden, lediglich die Zweiteilung der Aufgabe in
"Start-Phase" (C<view>-Methode) und "Resultat-Phase" (C<recv>-Methode) ist
typisch. Daß intern AnyEvent werkelt, fällt nicht auf, außer, daß die
Abfrage in einem laufenden Tk/Gtk usf.-Programm dieses nicht anhält.

Die Vorteile erscheinen, wenn man mehrere Abfragen "gleichzeitig"
(genauer: miteinander verflochten) ausführt:

   my @data = map $_->recv,
                 map $db->view ('users/al', { key => $_ }),
                    qw(key1 key2 key3 key4);

Auch hierbei muss man nicht darauf achten, welches Event-Modul benutzt
wird (oder ob man überhaupt ein spezielles benutzt) - es funktioniert
einfach.

Richtig Spaß macht es, wenn man realisiert, daß man praktisch alle
AnyEvent-benutzenden Module beliebig kombinieren kann, und Aufgaben
quasi "im Hintergrund" erledigen kann, z.B. mit C<AnyEvent::CouchDB> und
C<AnyEvent::HTTP>:

   $db->view('users/all', { key => 'b' })->cb (sub {
      my $data = shift->revc;
      # daten erhalten
   });

   AnyEvent::HTTP::http_get "http://www.porttracker.co.uk", sub {
      my $html = $_[1];
      # daten erhalten
   };

   # hier kann man weitere Dinge erledigen

Und all das kann man in den eigenen Modulen nutzen, ohne sich irgendwie
auf ein bestimmtes Event-Modell festzulegen.


=head2 AnyEvent - Grundlegendes

AnyEvent selbst wurde letztes Jahr an dieser Stelle ausführlich
vorgestellt, daher möchte ich hier nur eine kurze Übersicht
bzw. Einführung in AnyEvent als rein Event-Bibliothek geben:

Wie viele anderen Bibliotheken auch, benutzt AnyEvent das Konzept eines
"Watchers", einem Objekt, daß wie ein Wachhund auf ein bestimmtes
Ereignis reagiert (watch/watcher = Wache/Beobachter) und bei eintreten
eine Aktion auslöst, z.B. aufrufen eines Callbacks.

Diese Watcher gibt es für die folgenden Ereignistypen:

=over 4

=item Zeit - timer

   my $timer = AnyEvent->timer (after => 7, cb => sub {
      warn "Sieben Sekundne sind abgelaufen!";
   });

Timer können nach einer gewissen Zeit ablaufen, oder wiederholt (z.B.
alle 3s) Ereignisse auslösen und Callbacks aufrufen.

=item I/O auf File Handles - io

   my $watcher = AnyEvent->io (fh => *STDIN, poll => 'r', cb => sub {
      my $line = <STDIN>;
      #  zeile von stdin gelesen
   });

I/O-Watcher beobachten einen File Handle und können einen Callback
aufrufen, wenn gelesen oder geschrieben werden kann.

=item Signale - signal

   my $quit = AnyEvent->condvar;

   my $term = AnyEvent->signal (signal => "TERM", cb => sub {
      $quit->send;
   });

   ...

   $quit->recv

Mit Signal-Watchers kann man synchron auf das Auftreten von Signalen
warten.

Das obige Beispiel benutzt eine "condition variable" um mit dem
Hauptprogramm zu kommunizieren (mehr info s.u.).

=item Kindprozesse sterben sehen - child

   my $w = AnyEvent->child (pid => $pid, cb => sub {
      warn "pid $pid hat sich beendet\n";
   });

Eher selten benötigt, aber sehr schwer zu implementieren (wenn man es
richtig tun möchte :) sind Child-Watcher: mit diesen kann man auf das
Beenden von ge-fork-ten Prozessen warten.

=back

=head3 Wenn man mal nichts tun möchte

Event-basierte APIs haben eines gemein: Im allgemeinen werden Vorgänge
nur gestartet und laufen dann quasi-parallel im Hintergrund ab.

Aber wenn man nun genügend solche Vorgänge gestartet hat, möchte man ja
irgendwann auch mal auf die Ergebnisse warten.

Dies erledigt entweder das Hauptprogramm, indem es die entsprechenden
Funktionen der Event-Bibliothek aufruft (z.B. C<Event::loop> oder C<main
Gtk>), oder man benutzt sogenannte "condition variables", mit denen man
auf das eintreten eines bestimmten Zustands warten kann.

"Condition Variables" sind so etwas wie "Rendezvouspunkte" zwischen dem
Erzeuger von Daten oder einem Ereignis (z.B. C<AnyEvent::CouchDB->view>
oder C<AnyEvent::HTTP::http_get>, aber auch genauso C<< AnyEvent->timer
>>) und dem Konsumenten (der Benutzer dieser Funktionen, der die Daten
haben oder einfach auf das Ereignis warten möchte).

=head1 Neues!

Auf zu neuen Ufern - im letzten Jahr hat sich viel getan, sowohl in
AnyEvent selbst, als auch in Sachen "andere Module die AnyEvent benutzen".

=head2 Altes!

Die wichtigsten Eigenschaften von AnyEvent sind allerdings beim
alten geblieben:

=over 4

=item * Die API hat sich kaum verändert, bzw. ist 100%
rückwärtskompatibel.

=item * AnyEvent ist nach wie vor "Pure-Perl".

=item * Der Event-Teil ist nach wie vor getrennt von den anderen Teilen,
daß Event-Modul ist klein und wenn man bezahlt nur für daß, was man
benutzt.

=back

Aber nun zu den Neuigkeiten:


=head2 AnyEvent::Strict

Aus Geschwindigkeitsgründen macht AnyEvent selbst keine
Parameterprüfung, ganz einfach deshalb, weil die Prüfung meistens mehr
Zeit in Anspruch nimmt als der Rest der Funktion.

Für einen erfahrenen AnyEvent-Benutzer ist das in der Praxis kein
Problem, aber wenn man die API noch nicht genau kennt, können sich so
Fehler einschleichen (z.B. alte Event-Hasen benutzen gerne C<fd> statt
C<fh> um einen I/O-Watcher zu erzeugen).

Daher bietet AnyEvent optional eine strenge Prüfung aller
Parameter an. Die kann man ganz einfach aktivieren, in dem man die
Environment-Variable C<PERL_ANYEVENT_STRICT> auf C<1> setzt, was auf allen
meinen Entwicklungsrechnern der Fall ist.

Falls man diese Prüfung grundsätzlich wünscht (was ich ganz dringend
I<nicht> empfehle, siehe aber den Punkt "keine Religion"...), kann man diese
auch immer aktivieren:

   use AnyEvent;
   use AnyEvent::Strict;

   # jetzt wird brutal geprüft.

Ich gebe zu, daß war sicher noch nicht der Brüller, aber sehen wir
weiter:

=head2 Anyevent::Util

Dies ist meine Grabbelkiste für nützliche aber eklige Funktionen:

=over 4

=item fork_call BLOCK $callback

Führt den angegebenen BLOCK in einem separaten Prozess aus und ruft
danach den $callback mit den Resultatwerten auf. Ist ideal, um lange
Berechnungen in einen separaten Prozess zu verlagern:

   fork_call {
      find_primes_till 1e9
   } sub {
      warn "alle primzahen bis 10**9: ", join " ", @_;
   };

Die Funktion leaked allerdings unter Windows, aber ich habe bisher noch
keinen weg gefunden, unter einem native-win32-Perl zu forken und das Kind
sauber zu beenden (ich glaube, es gibt keinen)...

=item my $guard = guard BLOCK

Führt den angegebenen BLOCK aus, wenn C<$guard> zerstört wird. Ist
bei ereignisgesteuerter Programmierung total hilfreich, um Sachen
aufzuräumen.

Wenn es vorhanden ist, benutzt AnyEvent das C<Guard>-Modul (ja, das ist
Schleichwerbung).

=item fh_nonblocking $fh, $nonblocking

Einen File Handle non-blocking zu machen, ist nicht ganz einfach (Windows,
Windows, kaputt, kaputt...). C<AnyEvent::Util> erledigt dies mit
furchtbaren Hacks unter Windows und elegant überall sonst.

=back

Immer noch nicht überzeugt? Ok, dann machen wir mal mit
Netzwerkprogrammierung weiter:


=head2 AnyEvent::Socket

Sockets in Perl haben ein paar gravierende Nachteile: non-blocking
connects sind extrem umständlich, IPv6 und IPv4 brauchen völlig
inkompatible APIs, DNS blockiert den gesamtem Prozess und liefert darüber
hinaus auch nur altmodische IP-Adressen.

Anders mit AnyEvent::Socket:

   tcp_connect "www.google.com", "80", sub {
      my ($fh) = @_
        or die "www.google.com: $!";

      ...
   };

Dieser Aufruf löst zuerst C<www.google.com> auf - im Hintergrund, ohne
das Programm anzuhalten - und baut dann, ebenfalls im Hintergrund, eine
TCP-Verbindung dorthin auf.

Es versteht sich von selbst, daß Multi-Homed Hosts genauso unterstützt
werden wie IPv6, und das ohne zusätzliche XS-Module.

C<tcp_connect> kann aber noch mehr. Z.b. auf Jabber-server connecten, was
mit Perl alleine fast unmöglich ist, da man mit Perl keine SRV-Records
auflösen kann:

   tcp_connect "jabber.org", "xmpp-server=5269", sub {
      # Die pseudo-XML-Kacke parsed ihr bitte selbst...
   }, 60; # <- timeout
 
Der Name C<tcp_connect> ist leider etwas naiv, tatsächlich werden auch
andere Protokolle unterstützt, z.B. local unix sockets:

   tcp_connect "unix/", "/tmp/.X11-unix/X0", sub { ...

Listening-Sockets funktionieren prinzipiell genauso einfach, z.B. hier
für einen TCPv6-Port:

   tcp_server "::", 80, sub {
      my ($fh, $host, $port) = @_;
   
      # jede neue Verbindung führt zu einem Aufruf dieses Callbacks
   };

Oder einen beliebigen TCPv4-Port:

   tcp_server "0", undef, sub {
      my ($fh, $host, $port) = @_;
      ...
   }, sub {
      my ($thishost, $thisport) = @_;
   
      warn "bound to port $thisport\n";
   };

Leider muss man sich selbst darum kümmern, ob IPv6-Sockets auch auf IPv4
hören - üblicherweise ja, aber die BSDs haben natürlich mal wieder
verbockt und halten sich nicht ans RFC.

Komplizierteres ist immer möglich - anderes als z.B. C<IO::Socket> hat
man volle Kontrolle über die eigentliche Socket und braucht nicht für
jeden etwas spezielleren Wunsch extra Support.

Und anders als bei anderen Lösungen funktionieren diese Funktionen auch
unter Windows korrekt (modulo Tk, daß wie üblich zu kaputt ist, um
non-blocking connects stabil zu kriegen, aber AnyEvent arbeitet auch um
diese Bugs herum).

Neben diesen beiden Funktionen gibt es in AnyEvent::Socket eine Unmenge an
Utility-Funktionen zum parsen/anzeigen von IP-Adressen, Socket-Adressen
und DNS:

   $ipn = parse_ipv4 $dotted_quad
   $ipn = parse_ipv6 $textual_ipv6_address
   $ipn = parse_address $text
   $text = AnyEvent::Socket::aton $ipn
   ($host, $service) = parse_hostport $string[, $default_service]
   $sa_family = address_family $ipn
   $text = format_address $ipn
   $text = AnyEvent::Socket::ntoa $ipn
   inet_aton $name_or_address, $cb->(@addresses)
   $sa = AnyEvent::Socket::pack_sockaddr $service, $host
   ($service, $host) = AnyEvent::Socket::unpack_sockaddr $sa
   resolve_sockaddr $node, $service, $proto, $family, $type, $cb->([$family, $type, $proto, $sockaddr], ...)

Hier verweise ich auf die Dokumentation. Einzig C<parse_hostport>
möchte ich genauer erklären: Selbst die Aufgabe, einen Hostnamen und
einen Port anzugeben, ist nicht ganz einfach wenn man es richtig machen
will. C<parse_hostport> nimmt ein oder zwei Strings und zerlegt diesen in
Host und Port, z.B. diese:

   www.linux.org
   www.x.de:443
   www.x.de:https=443
   127.1:22
   ::1
   affe::1
   [10.0.1]:80
   [www.x.org] 17
   10.0.0.1 smtp

Richtig, IPv6 macht das ganze deutlich komplexer. Und IPv6 ist die
Zukunft, ob man das nun gut findet oder nicht :/

Ach ja, Stichwort IPv6 - es kann auch furchtbar nervig sein, wenn
Programme grundsätzlich die IPv6-Adresse bevorzugen, die gerade nicht
erreichbar ist. Der Standard bei AnyEvent ist zur Zeit IPv4 den
Vorzug zu geben, was sich allerdings über die Environment-Variable
C<PERL_ANYEVENT_PROTOCOLS> beeinflussen lässt.


=head2 AnyEvent::DNS

Nur am Rande möchte ich AnyEvent::DNS erwähnen. Ursprünglich war es nur
dazu gedacht, die Adressen für C<AnyEvent::Socket> zu resolven. Das Modul
ist aber ein kompletter Stub-Resolver, der beliebige DNS-Record-Typen,
EDNS0, IPv6 und virtual circuit mode supported.

Das Modul ist in der Praxis ca. halb so schnell wie z.b. EV::ADNS (braucht
natürlich viel mehr Speicher, blockiert aber im Gegensatz zu EV::ADNS
nie).

Es gibt Hilfsunktionen (hier nur eine Auswahl):

   AnyEvent::DNS::a $domain, $cb->(@addrs)
   AnyEvent::DNS::mx $domain, $cb->(@hostnames)
   AnyEvent::DNS::srv $service, $proto, $domain, $cb->(@srv_rr)
   AnyEvent::DNS::ptr $domain, $cb->(@hostnames)
   AnyEvent::DNS::reverse_lookup $ipv4_or_6, $cb->(@hostnames)
   AnyEvent::DNS::reverse_verify $ipv4_or_6, $cb->(@hostnames)

Und eine Resolver-Klasse:

   use Data::Dumper;
   use AnyEvent::DNS;
   AnyEvent::DNS::resolver->resolve (
      "google.com", "*", my $cv = AnyEvent->condvar);
   warn Dumper [$cv->recv];
  
   # gekürztes Ergebnis:
   # [
   #   [ 'google.com', 'soa', 'in', 'ns1.google.com', 'dns-admin.google.com',
   #     2008052701, 7200, 1800, 1209600, 300 ],
   #   [
   #     'google.com', 'txt', 'in',
   #     'v=spf1 include:_netblocks.google.com ~all'
   #   ],
   #   [ 'google.com', 'a', 'in', '64.233.187.99' ],
   #   [ 'google.com', 'mx', 'in', 10, 'smtp2.google.com' ],
   #   [ 'google.com', 'ns', 'in', 'ns2.google.com' ],
   # ]


=head2 AnyEvent::Handle

Nun zum ehrgeizigsten Teil der Neuerungen: C<AnyEvent::Handle>.

Die Probleme, die dieses Modul lösen möchte, kommen in der Praxis
häufig vor: Formatted-I/O, Pipelining und TLS-Verschlüsselung.

Früher habe ich immer ad-hoc Lösungen für diese Probleme implementiert,
da mir schlicht die Erfahrung gefehlt hat, wie man alle diese Features in
ein allgemeines Perl-Modul "gießt".

C<AnyEvent::Handle> versucht diese Lösung zu
sein: AnyEvent::Handle-Objekte sind Wrapper um existierende File
Handles. Im folgenden beschreibe ich die Lösung, die AnyEvent::Handle
für die oben beschriebenen Probleme bietet:

=over 4

=item Formatted I/O

Um auf ein AnyEvent::Handle-Objekt zu schreiben, benutzt man
C<push_write>. Das C<push> deutet darauf hin, daß es einen Puffer für
die Daten gibt, und C<push_write> hängt die Daten einfach an diesen an:

   $hdl->push_write ("GET / HTTP/1.0\015\012\015\012");

Mit mehr als einem Argument fordert man zusätzliche Formatierungen an,
die meisten dieser Formatierungen gibt es sowohl für die Schreib- als
auch die Leseseite:

   $hdl->push_write (netstring => "xyz");        # djb netsrings
   $hdl->push_write (packstring => "w", "data"); # benutzt pack()
   $hdl->push_write (json => [1, 2, 3, 4]);      # benutzt JSON
   $hdl->push_write (storable => $ref);          # benutzt Storable

Schreiben ist einfach, Lesen ist schwieriger. Anders als beim Schreiben
enthält der Puffer keine Daten, sondern die Callbacks, die der Reihe nach
aufgerufen werden, wenn Daten eintreffen.

Die Flexibilität entsteht dadurch, daß man Callbacks ans Ende des Puffers anhängen kann:

   $hdl->push_read (json => sub { my $data = $_[1] });

Aber auch vor dem Anfang einschieben kann:

   $hdl->unshift_read (json => sub { my $data = $_[1] });

Interessant ist dies vor allem, weil man hierdurch recht einfach auch
komplexe Protokolle mit Pipelining implementieren kann.

Man kann jederzeit eigene Typen global für alle Handles hinzufügen, die
existierenden Typen sind neben denselben wie für die Schreibrichtung:

   $hdl->push_read (line => $eol, $cb);          # zeilen
   $hdl->push_Read (regex => $accept[, $reject[, $skip]); # uiuiuiui

=item Pipelining

Pipelining bedeutet, daß man auf einer bestehenden Verbindung mehrere
Anfragen gleichzeitig losschickt. Die Herausforderung liegt darin, daß
man beim Empfang der Antworten flexibel auf Ausnahmen reagieren können
muss.

Bei HTTP beispielsweise weiß man erst nach Parsen des Headers, wie lang
der Body wird.

AnyEvent::Handle erledigt dies mit einer Kombination aus C<push_read> und
C<unshift_read>:

   # sende requests
   for (@urls) {
      $hdl->push_write ("GET $_ HTTP/1.0\015\012\015\012");
   }

   # parse antworten
   for (@urls) {
      # lese header
      $hdl->push_read (line => "\015\012\015\012", sub {
         my ($hdl, $header) = @_;

         my $content_length = extract "Content-Length", $header;

         $hdl->unshift_read (chunk => $content_length, sub {
            my ($hdl, $body) = @_;

            # fertig
         });
      });
   }

Der springende Punkt ist, daß C<unshift_read> erst I<nach> dem Empfang
des Headers ausgeführt wird. Dadurch kann man z.B. verschiedene Arten von
Antworten parsen, oder auf unerwartete Fehler reagieren, obwohl vielleicht
schon Antworten auf die nächsten Requests empfangen wurden.

=item TLS/SSL

TLS ist der Horror. Nicht nur, aber vor allem auch wegen der grauenvollen
OpenSSL-API (GnuTLS ist geringfügig besser, doch sucht man vergebens nach
einem guten Perl-Modul dafür). Der Beweis dafür ist, daß es praktisch
kein Modul gibt, daß non-blocking TLS connects korrekt und wirklich
non-blocking durchführt.

Es hilft auch nicht gerade, daß Net::SSLeay nur einen Bruchteil der
OpenSSL-API umsetzt.

AnyEvent::Handle (to boldly go...) versucht einen ganz neuen Ansatz für
diese Problematik, bei der OpenSSL vom eigentlichen File Handle komplett
getrennt wird, d.h. gar keinen Zugriff auf diesen hat. Dadurch wird
garantiert, daß OpenSSL auf gar keinen Fall blockieren kann.

=back

Mit AnyEvent::Handle wird so manches einfach. Hier ist z.B. ein (ganz
primitiver) HTTPS-Client (übrigens das komplette Programm):

   use AnyEvent;
   use AnyEvent::Socket;
   use AnyEvent::Handle;

   my $cv = AnyEvent->condvar;

   tcp_connect "www.google.com", "443", sub {
      my ($fh) = @_ or die;

      my $hdl; $hdl = new AnyEvent::Handle
         fh      => $fh,
         timeout => 60,
         tls     => "connect",
         on_eof  => sub {
            undef $hdl; # gibt handle frei
            $cv->send;  # isch hab' ferdisch
         },
         on_read => sub {
            my ($hdl) = @_;
            print $hdl->{rbuf};
            $hdl->{rbuf} = "";
         };

      $hdl->push_write ("GET / HTTP/1.0\015\012\015\012");
   };

   $cv->recv;

=back


=head2 Benchmarks

=head2 Ausblick auf CPAN
Revision:	1.1
Committed:	Wed Jan 14 00:58:49 2009 UTC (17 years, 8 months ago) by root
Branch:	MAIN
Log Message:	* empty log message *