temporarily unavailable

efraim@desire.camelot.de (Alexander Koch) writes: |> *** Efraim Nickname collision KILL from root@desire.camelot.de (from |> +Uni-Stuttgart.DE) wegen des KILL siehe bitte unten... |> *** You have been rejected by server Uni-Stuttgart.DE |> *** Use /SERVER to reconnect to a server Erstens: never join irc using a root account. Aber: Du solltest alt genug sein, selbst zu wissen, was Du Dir zutraust und was net, nur heul danach net rum, wenn was passiert is. Zweitens: Was eine Nick-collision ist, weisst Du? Wenn nein: Im IRC ist es so, dass NickNames eindeutig sein muessen, weil daran eben die User unterschieden werden. Nun kann es dummerweise mal passieren, dass ein Nick doppelt auftritt (bei einem Net-Join zum Bleistift), dann werden beide Personen gekillt, um die Unstimmigkeit zu beseitigen und niemanden zu bevorteilen. Wenn ja: fein. |> *** Connecting to port 6667 of server irc.uni-erlangen.de |> *** Efraim Nick/channel is temporarily unavailable ja. Die Geschichte ist eine laengere welche. Sie begann so: Wenn zwei IRC-Server connecten, muessen sie eigentlich _sofort_ alle Status-Informationen austauschen, um ihre beiden Zustaende (und damit auch die der dahinter liegenden Server) abgleichen zu koennen, damit die beiden Netze zusammengefuehrt werden koennen. Das heisst aber, dass bei Netzen der Groesse des Ef-, Under- oder des IRCNet innerhalb einiger weniger Sekunden Informationen ueber mehr als 4.000 Channels und mehr als 13.000 User und natuerlich ueber deren MODEs ausgetauscht werden muessen. Das bedeutet Daten in der Groessenordnung von 3 bis 6 MB. Das bedeutet Peaks von 150 bis 300 KByte/Sekunde, damit das innerhalb vernuenftiger Zeit erledigt werden kann. Deshalb wird das Ganze dann auch Connect-Burst genannt. Damit sollte das Rahmenproblem ausreichend beschrieben sein. Um das etwas abzuschwaechen, hat der ircd2.9.* eine eigene Strategie, die auf folgender Annahme beruht: Die meisten Netsplits werden innerhalb kurzer Zeit behoben. Allerdings aendern sich in dieser Zeit nicht alle Statusinformationen, die meisten bleiben konstant. Die Strategie ist nun die: Wenn ein Netsplit auftritt, werden saemtliche Daten ueber das abgesplittete Netz fuer eine bestimmte Zeit (konfigurierbar - per default 15 min) weitergefuehrt. Kommt der Netjoin nun innerhalb dieser Zeitspanne, muessen nur noch die Aenderungen ausgetauscht werden - also wesentlich weniger Daten. Dieses Verhalten bedingt aber einige Vorsichtsmassnahmen. Angenommen Nick xyz verschwindet aufgrund eines Netsplit, dann existieren alle Daten ueber ihn trotzdem noch eine gewisse Zeit weiter. Angenommen nun, in dieser Zeit versucht ein anderer User, sich als xyz dem Netz bekannt zu machen. Dann gibt es natuerlich Unstimmigkeiten. Prinzipiell duerfte er das, weil der andere ja nicht mehr existiert. Der alte User ist JETZT aber trotzdem quasi als Geist immernoch da. Deshalb fuehrt der ircd2.9 einen neuen Status ein: Nick/channel is temporarily unavailable Diesen Status bekommt ein Objekt (Nick, Channel etc.) immer dann, wenn es durch myterioese Umstaende verschwunden ist (Kill, Quit im Split etc.) und behaelt den fuer eine konfigurierbar lange Zeit und wird erst dann richtig geloescht. |> *** Closing Link: [efraim@194.97.87.225] (Ping timeout) Dieses Ereignis bedingt keine Schliessung der Verbindung, d.h. der Client kann einfach ein neues NICK senden und allet geht weiter (so wie bei: Nick is already in use). Wenn das nicht kommt, fliegt der Client eben - wie ueblich - wenn er ne Zeit lang nix sagt. |> *** Connection closed from irc.uni-erlangen.de: Remote end closed connection ...und dann wird auch die Connection geschlossen. |> *** Connecting to port 6667 of server irc.uni-erlangen.de |> *** Efraim Nick/channel is temporarily unavailable ...und wenn der Client bloed is und der User ebenfalls und autoreconnected, obwohl ihm jede MOTD mitteilt, dass er das nicht tun soll, dann passiert sowas. |> *** Efraim Nick/channel is temporarily unavailable |> |> Ich war da mindestens eine Stunde lang nicht im irc, /whowas efraim meldete vielleicht ein anderer? |> mir auch nichts. Ja, wenn ein Client unter myterioesen Umstaenden verschwindet, ist sein Zustand noch etwas unklar... Da isser net (weil, er is ja verschwunden), also meldet ihn WHOIS net. Richtig weg isser auch net (weil, seine Status-Infos sind ja noch immer vorhanden), also ist er auch noch nicht in die WHOWAS Liste eingetragen, also kann ihn WHOWAS auch net melden. |> Any explanation? Das passiert mir in letzter Zeit haeufiger (No |> authorisation). Das er nach Stuttgart bei Erlangen ein unavailable bringt, No Authorization ist nun wieder was ganz anderes. |> ist klar, der Abstand war zu kurz, auch der gleichzeitige Ping timeout ist |> erklaerbar. |> Aber dass der mich mit einem KILL rauswirft, erscheint mir raetselhaft. In dem Fall war das wohl eine Nick-Collision mit einer anderen Sorte von Geist: In unseren Zeiten, in denen Verbindungen langsam sind und Bandbreite eher schmal ist und in denen es sogar noch Regionen gibt, die wesentlich schlimemr dran sind, als *.de kann es schonmal passieren, dass: 1. ein Server wegsplittet 2. dieser Server woandershin connected 3. dieses woanders ueber das Verschwinden des Servers aus seiner ersten Connection aber noch garnicht informiert ist (Laufzeiten im Netz) In diesem einfachen Fall, wird der connect einfach abgewiesen. In unguenstigeren Faellen (einen solchen zu konstruieren fehlt mir mometan die Lust) kann es allerdings passieren, dass Dir nicht Server-Geister sondern Objekt-Geister (Nick, Channel etc.) ueber den Weg laufen. Sowas nennt man dann desync (von: nicht synchronisiert). Und da Objekte eindeutige Namen haben muessen, kann es dann schonmal passieren, dass ein Objekt geKILLt wird, weil es auf einmal doppelt da ist. BitKoenig PS: Kann das mal bitte irgendwer irgendwohinschreiben, in einer Form, dass man darauf verweisen kann? Ich hab kein Bock, mir staendig wegen derselben Sache den Mund fusselig zu reden. -- Mario "BitKoenig" Holbe <Mario.Holbe@RZ.TU-Ilmenau.DE> http://WWW.RZ.TU-Ilmenau.DE/~holbe/ Uebrigens... Wer frueher stirbt ist laenger tot!