Index of /dev/null

October 2009 Archives

October 2009 Archives

Chronologie eines außergewöhnlichen Programmierwettbewerbs

Donnerstag, 15.10.2009, 16:14 Uhr

Ein unspektakulärer Arbeitstag neigt sich dem Ende zu. Im Posteingang erscheint eine Verlautbarung der DENIC-Mitgliederliste. Von einem BGH-Urteil ist die Rede, von neuen Domainrichtlinien. Da per Gerichtsbeschluss die Registrierung der Domain vw.de angeordnet worden sei, sollen auch vergleichbare Domainnamen freigegeben werden, die bisher nicht zugelassen waren: ein- und zweistellige Domains, Zifferndomains, sowie existierende Toplevel-Domains und deutsche Autokennzeichen.

Das bedeutet: keine Beschränkungen mehr, abgesehen von der Maximallänge und dem zugelassenen Zeichensatz, sowie der international üblichen Regel, dass Domainnamen nicht mit einem Minus beginnen oder enden dürfen.

Es ist klar, dass unter diesen Namen nicht wenige sind, die man mit fünf- bis sechsstelligen Beträgen handeln werden wird.

Im dritten Absatz offenbart sich dann die eigentliche Brisanz dieser Nachricht. Man muss zweimal hinschauen: Die Registrierung der neuen Domains ist ab "25.10.2009 9:00 Uhr (MESZ)" freigegeben. First come – first served.

Prompte Nachfrage eines Mitgliedes: Der 25.10. sei ein Sonntag und außerdem der Tag, an dem um 3:00 Uhr von MESZ auf MEZ umgechaltet wird, ob das bekannt sei? Und ob wirklich MESZ gemein sei?

Donnerstag, 15.10.2009, 16:43 Uhr

Achja, es wird offiziell korrigiert: Starttermin ist Freitag, der 23.10.2009, 9:00 MESZ. Das ist in einer Woche.

Währenddessen: der Geschäftsführer erscheint zur spontanen Krisensitzung im Entwickler-Büro. Wir müssen sehr schnell zwei Dinge gleichzeitig tun:

  • Einen Landrush für unsere Kunden vorbereiten, damit sie ihre Bestellungen vormerken können.
  • Unsere Teilnahme an der Vergabe am 23.10. vorbereiten.

Schon während des Gesprächs wird ein Webformular für die Kunden aufgesetzt, zum Vormerken der gewünschten Domainnamen. Auch hier gilt: First come – first served. Wir einigen uns auf Freischaltung zum Dienstag, 20.10.2009, 12:00 Uhr MESZ. Ein Eil-Newsletter ist zu formulieren. Alle anderen Projekte sind zurückzustellen.

Freitag, 16.10.2009, 14:43 Uhr

Eine erste interne Testversion für das Vormerk-Formular und die zugehörige Datenbankstruktur ist fertig. Es soll ab Montag für die Kunden sichtbar sein.

Währenddessen erfolgen erste Entwicklungsschritte für die Teilnahme am DENIC-Landrush. Die Registrierung soll per SMTP via PGP-signierter E-Mails im MRIv2-Format erfolgen. Wir benutzen schon lange nicht mehr die SMTP-Schnittstelle der DENIC, sondern die Echtzeitschnittstelle RRI (XML per dediziertes TCP-Protokoll). Es gilt also zunächst, MRIv2 zu lernen. Die technische Dokumentation wird studiert: Wie müssen die Antrags-Mails genau aussehen?

Freitag, 16.10.2009, ca. 16:00 Uhr

Die ersten MRIv2-Mails werden erfolgreich abgesetzt und verarbeitet, zunächst einfach Updates für bestehende Test-Domains. Unser PGP-Key funktioniert, man muss aber bei IDN-Domains mit dem Encoding aufpassen.

Wir werden alle Vormerkungen mit festen Kontakt-Handles und einer festen Delegation auf DENIC-Nameserver absetzen um überflüssige Probleme zu vermeiden. Erfolgreiche Registrierungen können später auf die gewünschten Eintragungen geändert werden. Also ist wenigstens schon mal klar, wie die Anträge genau auszusehen haben.

Währenddessen ist eine heiße Diskussion auf der Mitgliederliste entbrannt. Wieso, das BGH-Urteil sei doch schon 29.09.2009 gefällt worden? Achso, es war dem BGH-Anwalt der DENIC am 15.10.2009 offiziell mitgeteilt worden.

Die technische Dokumentation zum geplanten Landrush wird nun beinahe beinahe stündlich geändert. Allseits herrscht Verwirrung. Wo soll man hinsenden? Was ist mit einer Test-Umgebung? Wie ist die zu erreichen und ab wann? Und wie genau ist die Policy für das Einliefern der Mails nun überhaupt zu verstehen? Eine dedizierte IP-Adresse pro Mitglied und dann maximal 4 Mails pro Minute. Aber was heißt das genau?

Montag, 19.10.2009, 10:00 Uhr

Unsere dedizierte IP-Adresse für die Teilnahme am Landrush wird angemeldet. Damit können wir am Testbetrieb teilnehmen.

Auf der Mailingliste toben mittlerweile erbitterte Auseinandersetzungen und verwirrte Nachfragen. Gleichzeitig werden allenthalben juristische Schritte angedroht, befürchtete Übervorteilungen angeprangert und Details des SMTP-Protokolls diskutiert.

Montag, 19.10.2009, ab 16:00 Uhr

In der Dokumentation wird verwirrenderweise explizit auf die Möglichkeit des SMTP-Pipelinings hingewiesen, obwohl das doch allenfalls dazu dienen kann, die selbe Mail an verschiedene Empfänger in einem Bulk abzusenden? Das ist hier sinnlos, denn man müsste stattdessen verschiedene Mails möglichst schnell an den selben Empfänger absenden. Tatsächlich ergeben erste Tests, dass man scheinbar nichteinmal mehrere Mails innerhalb der selben TCP-Connection absetzen kann:

"421 too many messages in this connection"

Insgesamt ist unklar, wie genau die ACL funktioniert. Teilweise kann man mehr als 4 Mails pro Minute absetzen, dann auch wieder weniger, möglicherweise je nachdem wie viele Versuche man unternimmt. Eine diesbezüglich Anfrage an den DENIC-Support wartet vergebens auf Antwort.

Dienstag, 20.10.2009, 10:00 Uhr

Unser Vormerk-Formular wird einem firmeninternen Landrush-Test unterzogen. Keine technischen Probleme.

Dienstag, 20.10.2009, 12:00 Uhr

Unser Vormerk-Formular wird für die Kunden freigeschaltet. Innerhalb weniger Sekunden gehen ca. 25.000 Anfragen ein, während wir ängstlich beobachten, wie die CPU des Webservers an der Decke klebt. Nach einigen Minuten beruhigt sich die Lage. Wir haben zunächst ungeprüft alles angenommen, um nur ja nicht berechtigte Anfragen fälschlicherweise abzulehnen. Das wäre im Nachhinein nicht mehr gut zu machen, da die Reihenfolge dann nicht mehr klar wäre.

Nach Bereinigung von Dopplern und ungültigen Domainnamen bleiben ca. 2500 Vormerkungen übrig.

Dienstag, 20.10.2009, 13:39 Uhr

Offenbar ist sich DENIC selbst noch nicht völlig im Klaren darüber, was genau mit 4 Mails pro Minute gemeint sein soll:

"[...] Derzeit arbeiten wir an der Optimierung der Mail-ACL. Bitte beachtet, dass es dadurch zu Anpassungen kommen kann, die Ihr zeitnah berücksichtigen müsst. [...]"

Unabhängig von der ACL ist jedenfalls klar, dass es im zu implementierenden Algorithmus für unser Landrush-Tool vor allem auf zwei Dinge ankommt:

  • Möglichst exakte Startzeit (welcher Zeitpunkt innerhalb des SMTP-Dialogs zählt?)
  • Während des Laufs möglichst wenig Domains zu beantragen, deren Nichtverfügbarkeit bereits ermittelt werden kann.

Wir lassen also zwei Threads parallel laufen, einen der versucht, die Mails aus der Queue (nach welcher Strategie auch immer) abzusenden, und einen, der parallel durch vorausschauendes Prüfen der Verfügbarkeit erfolglose Anträge markiert.

Dienstag, 20.10.2009, 19:42 Uhr

DENIC gibt erstmals exakte Informationen über die Realisierung der ACL bekannt. Insbesondere wurde der Algorithmus vom bisher verwedeten "Sliding-window Verfahren", das auf in undurchsichtiger Weise aufgrund extrapolierter Sendegeschwindigkeit berechneten Zeitfenstern beruhte, umgestellt auf das sog. "Rate-limiting Verfahren nach dem Token-bucket Algorithmus". Demnach sollen tatsächlich immer maximal 4 Mails pro echter Zeitminute angenommen werden, unabhängig von der Anzahl der Sendeversuche.

Mittwoch, 21.10.2009, 08:00 Uhr

Eigentlich wollten wir heute zum technischen Meeting der DENIC nach Frankfurt fliegen. Zwei Flüge waren lange gebucht und werden nun verfallen. Keine Zeit für Meetings.

Mittwoch, 21.10.2009, 08:55 Uhr

Wir nehmen erstmals an einem Massentest teil. Wie im geplanten Livebetrieb wird der Mailserver bereits um 08:55 gestartet, und Mails vor 09:00 Uhr werden zunächst angenommen und dann mit einer entsprechenden Fehlermeldung beantwortet.

Diese Vorgehensweise ist für den Landrush-Programmierer angenehmer als die sonst häufig angewandte Methode, erst ab Startzeit Connections zu akzeptieren, da man hierbei leicht in einen Timeout zur Startzeit schlittern kann und sich dieses Verhalten außerdem nur schwer simulieren lässt. Überhaupt hat dieser Landrush mehr etwas von einem raffinierten Strategie-Spiel als die sonst üblichen Massensprints, wo es gilt, parallel mit maximal vielen Connections auf den Server einzuprügeln.

Mittwoch, 21.10.2009, 09:00 Uhr

Überraschend am Massentest gegenüber dem üblichen Testbetrieb ist zunächst, dass der Mailserver offenbar vor dem Ansturm von weniger als 300 Mitgliedern mit je einer Connection ziemlich in die Knie geht. Die 4-Mails/Minute-Policy stellt sich als Farce heraus, da sich die SMTP-Dialoge dermaßen schleppend hinziehen, dass einzelne Mails schon 20-30 Sekunden brauchen. Auffallend ist außerdem, dass wiederholt Connections abgelehnt werden:

"421 Too many concurrent SMTP connections from this IP address",

Obwohl die vorherige Connection durchaus geschlossen und auch die Schließung durch den Server bestätigt worden war.

Mittwoch, 21.10.2009, 10:08 Uhr

Die ersten Antwortmails des Registrierungssystems treffen nach knapp einer Stunde ein. Mitglieder berichten von unerwarteten Antworten wie etwa

"ERROR: 56000000013 Technical error"

und anderen sonderbaren Phänomenen. Die Datenbank scheint auch vor dem Test nicht oder nur teilweise zurückgesetzt worden zu sein. Irgendwas scheint da gehörig gegen die Wand zu laufen.

Mittwoch, 21.10.2009, 10:08 Uhr

DENIC kündigt einen weitereren Massentest für 15:00 Uhr an.

Mittwoch, 21.10.2009, ab 11:00 Uhr

In diesem Test haben wir keine einzige interessante Domain abbekommen. Wir werden die Zeit bis zum Nachmittag nutzen, um den zweiten Thread zur Prüfung der Verfügbarkeit hinzuzufügen.

Die Verfügbarkeit von Domains ermitteln wir per RRI-Abfrage. Das scheint etwas effizienter und zuverlässiger als whois zu sein. Bei noch verfügbaren Domains, die nicht den bisherigen DENIC-Richtlinien entsprechen, antwortet DENIC mit einem Fehler bzgl. des Domainnamens:

Invalid format of value for keyword "Domain"

Somit interpretieren wir jede Antwort, die nicht besagt, dass die Domain vergeben ist, als "verfügbar".

Mit Hilfe einer speziellen Test-Tabelle, die zufällig verteilt einerseits die ein- und zweistelligen, und andererseits garantiert verfügbare Nummerndomains enthält, lässt sich der Parallelbetrieb von Abfragen und Senden auch außerhalb der Massentests testen, da somit eine gemischte Queue von vergebenen und freien Domains zur Verfügung steht. Unser Abfrage-Thread sucht vor jedem Sende-Intervall vier freie Domains aus der Liste, und zwar möglichst knapp vor dem Sendefenster, um eine möglichst hohe Zuverlässigkeit des Ergebnisses zu gewährleisten. Fraglich bleibt natürlich, wie aktuell die Antwort überhaupt ist.

Mittwoch, 21.10.2009, 15:00 Uhr

Startschuss Massentest, die Zweite. Wir sind jetzt gut aufgestellt. Da für den Eingangszeitstempel der Abschluß des DATA-Commands entscheidend ist, sollte der erste SMTP-Dialog vor der eigentlichen Startzeit begonnen werden. Unklar ist allerdings, welcher Zeitpunkt zwischen dem Senden des abschließenden "." am Ende des DATA-Commands und der Antwort des Servers am Ende zählt, zumal diese Zeitspanne ungewöhnlich groß ausfällt. Hier sind es ganze 6 Sekunden und wir bekommen das abschließende "250 OK" gut 5 Sekunden nach 15:00 Uhr, das ist vermutlich viel zu spät, um eine Chance auf die ersten Namen zu haben.

Mittwoch, 21.10.2009, 15:08 Uhr

Umso erstaunlicher, dass die ersten Mails mit "Too early" beantwortet werden, das heißt, sie sind beim Server vor 15:00 Uhr angekommen?

Dann kommt noch ein "Too early" und noch eins. Entsprechende Proteste auf der Mailingliste machen schnell klar: Der Test ist serverseitig fehlgeschlagen, alles wird mit "Too early" beantwortet.

Mittwoch, 21.10.2009, 15:41 Uhr

DENIC entschuldigt sich: Der Startschuss war versehentlich in den November verlegt worden. Ein erneuter Massentest wird für 16:00 Uhr angekündigt.

Mittwoch, 21.10.2009, 16:00 Uhr

Startschuss Massentest, die Dritte. Diesmal kommen zwar keine "Too early"-Antworten, dafür werden aber fortwährend Verbindung abgwiesen:

421 Too many concurrent SMTP connections from this IP address; please try again later.

Das ist merkwürdig, da wir definitiv für jede Mail eine eigene Connection öffnen und schließen. Es dauert dann jeweils bis zu einer Sekunde, bis eine neue Verbindung hergestellt werden kann. Es scheinen sich serverseitig verschiedene Dienste zeitweilig uneins über das Bestehen einer Connection zu sein.

Fazit: das Verhalten des Servers ist ausgesprochen indeterministisch und man hat den Eindruck, dass sich das Registrierungssystem durchaus in einer eher frühen Entwicklungsphase befindet und die Tests nicht nur der Entwicklung der Clients, sondern auch des Servers dienen.

Die wichtigste Beobachtung ist aber, dass wir immernoch zu viele Mails vergebens absenden, da die Verfügbarkeitsprüfung während der Massentests erheblich langsamer voran kommt als im Normalbetrieb. Unsere Prüfschleife sucht sich aus der Queue stets die 4 nächsten freien Domains heraus, wofür im Normalbetrieb etwa 4 Sekunden, unter Massentestbedingungen aber bis zu 20 Sekunden nötig sind.

Mittwoch, 21.10.2009, 19:06 Uhr

DENIC kündigt für den morgigen Tag nun doch noch zwei weitere Masentests an, um 9:00 Uhr und um 13:00 Uhr.

Dieser Abend wird genutzt, um die Strategie der Verfügbarkeitsabfrage zu verbessern. Wir werden nicht mehr, wie bisher, ab einem bestimmten Zeitpunkt vor Beginn des nächsten Sendefensters nach 4 freien Domains suchen, sondern den Thread praktisch pausenlos immer wieder von vorne nach freien Domains suchen lassen. Damit werden die als nächstes anstehenden Domains zwar immer wieder erneut geprüft, aber das Prüfintervall bleibt dabei unabhängig von dem praktisch unkalkulierbaren Sendefenster.

Die zweite Baustelle ist der exakte Startzeitpunkt. Eigentlich müsste man, um den extrem zeitkritischen Start optimal abzupassen, den SMTP-Dialog direkt programmieren, so dass man mit der ersten Mail hinreichend früh beginnt und das abschließende "." am Ende des DATA-Commands bis zur exakten Startzeit hinauszögern kann. Dafür ist aber die Zeit zu knapp, und die von uns benutzte SMTP-Library unterstützt natürlich nicht ein so spezielles Timing.

Der Arbeitstag dauert heute bis 23:00 Uhr und wird morgen um 8:00 Uhr beginnen.

Donnerstag, 22.10.2009, 08:00 Uhr

Vorbereitung auf den heutigen ersten Massentest. Auf der Mitgliederliste werden weiterhin Detailfragen des ACL diskutiert und von einigen eine Verschiebung des Registrierungstermins gefordert.

Donnerstag, 22.10.2009, ab 09:00 Uhr

Der Massentest startet. Der SMTP-Server scheint nun noch langsamer als gestern zu reagieren. Außerdem wird ungefähr jede 3. Mail mit "Too many concurrent SMTP connections" abgelehnt. Beim Beobachten des Logfiles ist man im Grunde froh, überhaupt einige Mails einliefern zu können.

Donnerstag, 22.10.2009, 09:56 Uhr

DENIC räumt ein, dass das Problem der abgwiesenen Connections reproduzierbar ist:

"[...] Unsere Tests haben ergeben, dass der entsprechende Prozess zum Beenden der Connection unter Last länger dauert als gewohnt. Nach Aussen wird die Connection zwar als geschlossen bestätigt - der Mailserver ist aber tatsächlich noch beim schliessen. [...]" [sic]

Man soll es eben dann immer wieder neu versuchen, bis man wieder eine Connection bekommt.

Donnerstag, 22.10.2009, 10:10 Uhr

DENIC gibt Messergebnisse zum Massentest bekannt. Es wurden von insgesamt 156 verschiedenen IP-Adressen aus pro Minute bis zu 3422 Versuche zur Mailannahme registriert. Wenn von jeder IP nur 4 Mails pro Minute eingeliefert würden, käme man nur auf 624.

Natürlich versucht wohl niemand mehr, nur noch 4 Mails pro Minute abzusetzen, nachdem man gemerkt hat, dass einerseits außerhalb der Masentests teilweise durchaus auch mal 5 oder 6 Mails in einer Minute angenommen werden und andererseits das Einliefern einer einzigen Mail während der Massentests bis zu 20 Sekunden dauern kann.

In Anbetracht dessen, dass der für 13:00 Uhr angekündigte Test voraussichtlich der letzte sein wird, lässt die Ankündigung, das Serversystem "weiter zu optimieren" auf nichts Gutes hoffen. Man wird sich womöglich erneut auf ein verändertes Verhalten des Servers einstellen müssen, ohne weitere Gelegenheit zum Testen zu haben. Um 15:00 Uhr soll das Testsystem dann ganz abgeschaltet werden. Aber niemand will Änderungen implementieren, die man nicht mehr testen kann.

Donnerstag, 22.10.2009, 12:51 Uhr

DENIC lässt ein neues Statement zum 4-Mails/Minute-ACL verlauten:

"[...] hochgezählt wird zu dem Zeitpunkt, wenn der Envelope der Mail geschrieben wurde."

Leider können ja offenbar mehrere Sekunden zwischen Abschluss des DATA-Commands und der folgenden Bestätigung "250 OK" vergehen. Wann innerhalb dieser Zeitspanne nun der Envelope geschrieben wird, ist für den Client nicht feststellbar. Ein exaktes Timing bzgl. des ACL ist somit schlichtweg unmöglich. Man muss hintereinander versuchen, Mails loszuwerden, egal ob zwischendurch Connections abgewiesen werden oder die Einlieferung per ACL abgelehnt wird, anders geht es nicht.

Donnerstag, 22.10.2009, 13:00 Uhr

Der letzte Massentest startet. Wir haben unsere Startzeit diesmal um 2 Sekunden zurückgesetzt, um den richtigen Startzeitpunkt wenigstens ungefähr auszuloten. Sollte der erste Antrag mit "Too early" beantwortet werden, so werden wir auf den vorherigen Wert zurückschwenken.

Es wird sofort klar: Diesmal kommt überhaupt keine Connection zustande. Der Server meldet kein Banner, offenbar werden alle Connections bereits firewallseitig abgelehnt.

Donnerstag, 22.10.2009, 13:06 Uhr

Der Abbruch des Massentests wegen Netzwerkproblemen wird bekanntgegeben. Ein neuer Test wird für 14:00 Uhr anberaumt.

Donnerstag, 22.10.2009, 13:48 Uhr

Der für 14:00 Uhr geplante Massentest wird wegen der noch bestehenden Netzwerkproblematik abgesagt.

Donnerstag, 22.10.2009, 14:42 Uhr

DENIC meldet, dass ein Versuch, das Problem der abgelehnten Connections zu umgehen, gescheitert ist. Es wird auf die bei den vorangegangen Tests benutzte Konfiguration zurückgegriffen. Nun sollen noch zwei Massentests um 15:30 Uhr und um 16:30 Uhr stattfinden.

Donnerstag, 22.10.2009, 15:26 Uhr

DENIC gibt bekannt, dass der Test um 15:30 Uhr nicht starten kann, weil zusätzlich Zeit für das Zurückgehen auf die frühere Lösung benötigt wird. Über den neuen Zeitplan soll zeitnah informiert werden.

Donnerstag, 22.10.2009, 15:55 Uhr

DENIC gibt den weiteren Zeitplan bekannt: Neue Massentests um 16:30 Uhr und um 17:00 Uhr. Abschaltung der Testumgebung um 17:30 Uhr.

Donnerstag, 22.10.2009, 16:33 Uhr

Der nächste Versuch ist gestartet. Das Einliefern der Mails funktioniert jetzt wieder, dauert aber teilweise über 30 Sekunden. Wir brechen nach kurzer Zeit ab, um unsere Testumgebung für den letzten Test um 17:00 Uhr rechtzeitig zurücksetzen zu können.

Donnerstag, 22.10.2009, 17:00 Uhr

Der letzte Test ist gestartet. Wir haben nun den Startzeitpunkt so weit zurückgesetzt, dass mehrere Anträge mit "Too early" beantwortet werden, woraus sich nun ungefähr der bestmögliche Startzeitpunkt erraten lassen sollte.

Freitag, 23.10.2009, 08:00 Uhr

Noch eine Stunde bis zum Start. Unser Tool wird auf Livebetrieb umgestellt. Es kommt jetzt nur noch darauf an, vor Aufregung ja keine Einstellung zu übersehen. Es muss die richtige Startzeit eingestellt sein, die richtige Datenbank geladen und der richtige Server angesprochen werden.

Mit Hilfe eines vorbereiteten Tools werden für die anstehenden Aufträge die PGP-signierten Auftragsmails generiert, die später abgesendet werden müssen.

Freitag, 23.10.2009, 08:30 Uhr

DENIC meldet, dass die Domains e.de, f.de, g.de, x.de, y.de, z.de, br.de, dw.de, hr.de und sr.de aufgrund kurzfristig zugestellter einstweiliger Verfügungen von der Registrierung ausgenommen sind. Gerade noch früh genug, um diese Aufträge in der Datenbank als gesperrt zu markieren.

Freitag, 23.10.2009, 08:38 Uhr

DENIC gibt bekannt, dass nicht nur vw.de, sondern auch o2.de aufgrund von Gerichtsentscheidungen bereits registriert wurden.

Freitag, 23.10.2009, 08:55 Uhr

Letzte Prüfung der Checkliste. Die Konfiguration ist auf den Livebetrieb umgestellt. Die automatische Synchronisierung mit fremden Zeitgebern ist angehalten, damit die Systemzeit ausschließlich durch den NTP-Server der DENIC synchronisiert wird. Der Domain-Robot, sowie alle Dienste, die gewöhnlich RRI-Connections mit DENIC aufbauen, sind angehalten, denn nur nur eine einzige RRI-Connection ist zugelassen.

Freitag, 23.10.2009, 08:57 Uhr

Unser Tool wird gestartet. Es lädt sich den Inhalt der Datenbanktabelle in den RAM, baut die TCP-Connection zum Mailserver auf und wartet von da an auf den Startzeitpunkt.

Das Rauchverbot im Entwicklerbüro wird vorübergehend aufgehoben.

Freitag, 23.10.2009, 08:59 Uhr

Gespannt wird der Beginn des ersten SMTP-Dialogs auf der Konsole mitgelesen. Die Einleitung des DATA-Blocks erfolgt eine halbe Sekunde vor 9:00 Uhr:

2009-10-23 08:59:59,449 >> RCPT TO:<auto@nd.denic.de>
2009-10-23 08:59:59,459 << 250 Accepted
2009-10-23 08:59:59,479 >> DATA
2009-10-23 08:59:59,520 << 354 Enter message, ending with "." on a line by itself

Freitag, 23.10.2009, 09:00 Uhr

Es dauert 6 Sekunden bis zur Bestätigung des ersten DATA-Blocks. Mit der ersten Domain werden wir somit wohl kaum durchkommen, aber wären wir früher gestartet, hätten wir genausogut leicht in das "Too early" laufen können. Ein Glücksspiel, wie so oft im Leben dann leider doch mal wieder ohne Hauptgewinn.

Alles Weitere ist ein Automatismus. Zäh wird Auftrag um Auftrag abgesetzt, während 30 Sekunden nach 9 Uhr planmäßig der zweite Thread startet, um parallel die nächsten Domains auf Verfügbarkeit hin zu prüfen.

Die Unwägbarkeiten bei diesem Rennen sind groß. Beispielsweise bleibt unser Antrag auf die Domain 1.de, den wir um 09:00:42 absetzen, erfolglos, obgleich um 09:00:38 noch die Verfügbarkeit dieser Domain bestätigt wurde. Wieviel Zeit zwischen dem Entgegennehmen eines Auftrags und der eigentlichen Registrierung einer Domain mitsamt Anzeige im RRI auf DENIC-Seite vergeht, weiß niemand.

Freitag, 23.10.2009, 09:02 Uhr

Wie man später erfahren wird, sind zu diesem Zeitpunkt bereits 85 Domains registriert, d.h. das eigentliche Rennen um die wichtigen Namen ist so gut wie gelaufen. Dennoch werden noch alle Domains als verfügbar angezeigt. Erstmals um 09:02:34 wird eine Domain mit Status "connect" angegeben.

Das Rennen um die hinteren Plätze wird noch den ganzen Tag über andauern. Unter dem Strich sind wir zu 8% mit unseren Aufträgen erfolgreich. Das ist keine so schlechte Quote. Andere Mitglieder waren dadurch erfolgreicher, dass sie sich zu Pools zusammengeschlossen und ihre Listen untereinander optimiert haben. Davon abgesehen waren die Bedingungen für alle Mitglieder im Wesentlichen gleich schwierig.

Die Gewinner der ganzen Veranstaltung sind ohnehin Sedo und vor allem die Rechtsanwälte, die nun in ihr eigenes Rennen einsteigen können. Noch im Laufe des Tages wird z.B. bekannt, dass in einem kleinen Haus mit vielen Briefkästen irgendwo in Florida plötzlich erstaunlich viele Firmen mit ein- und zweistelligen Initialen gegründet wurden. Und andere Geschichten.

Unser Rennen haben wir gewonnen, denn wir haben aus den Gegebenheiten das Bestmögliche gemacht. Alles Weitere wäre Glück gewesen.

While customizing my mt blog, I was wondering how to abbreviate long entry titles on particular places in a nice way. Well, mt provides template tag modifiers such as trim-to, but my aim was to do it more nicely, i.e. replacing anything behind the first three (or any other maximum) words by an ellipsis. For instance,

"more than three words"
should be shortened to
"more than three ..."
while a three-word-sentence should remain as it is.

The solution is a simple regex, of course. In Perl style,

s/ˆ(\S+(?:\s+\S+){2})(\s+\S+)+/$1 .../
does the job, because it doesn't match on three words or less. Equivalently, within mt template tags:
<$mt:EntryTitle regex_replace="/ˆ(\S+(?:\s+\S+){2})(\s+\S+)+/","$1&ensp;&hellip;"$>

did they change their api or what? did I miss something? 8-{

Today my good old paypal ipn script failed to post back to www.paypal.com/cgi-bin/webscr in order to verify a payment notification as usual. Strange! They said:

HTTP/1.1 301 Moved Permanently

It seems they are expecting the payment parameter as a GET query now,while I sent data by POST until now. It worked fine until yesterday. Urgh, it's about money, so I've to check this out promptly. :(

Well, my script is too old and too simple to handle 301 automatically, but fortunately it's clever enough to report the error.