Koaxkabel schreibt zwingend einen Bus vor, dessen Maximallänge 185m nicht übersteigen sollte. Pro Strang dürfen maximal 30 Stationen angeschlossen werden. Allerdings dürfen mehrere Stränge über Repeater/Hubs verbunden werden, um das Netzwerk zu vergrössern. Maximal dürfen sich 5 Repeater in einem Netz befinden, ein Paket darf über maximal 4 Stränge gehen und dabei durch nicht mehr als 3 Repeater gehen. Das ist die sogenannte 5-4-3-Regel. Durch eine Bridge oder einen Switch wird diese Regel aber aufgehoben, da an jedem Port eines Switches ein vollkommen neuer Strang beginnt. Leider gilt diese Regel auch nur für 10 MBit/s Ethernet (10BaseT oder 10Base2).

Koaxkabel sollte heute nur noch in Notfällen oder kleineren Runden zum Einsatz kommen, da diese Technik umständlich, fehleranfällig und veraltet ist. Bei Neuinstallationen darf laut DIN sogar kein Koax mehr verlegt werden ! Dafür gibt es die segensreiche Erfindung der Twisted Pair Verkabelung. Twisted Pair Kabel ist grundsätzlich erstmal ein Kabel mit 8 Adern, die paarweise (Pair) verdrillt (Twisted) sind. Twisted Pair Kabel gibt es in verschiedenen Kategorien von 1 bis inzwischen 7. Die Kategorie bezieht sich auf die maximale Frequenz mit der elektrische Signale über dieses Kabel geschickt werden können. Interessant für eine Lanparty-Verkabelung ist eigentlich nur Kategorie 5 (Cat 5). Für ISDN reicht theoretisch Cat 2 und für 10BaseT reicht Cat 3 aus, aber erstens kriegt man das heute nur noch ziemlich schwer und bei dem äusserst geringen Preisunterschied sollte jeder klar denkende Zocker sofort Cat 5 einsetzen. Cat 5 ist spezifiziert bis 100 MHz und somit für Übertragungen mit 100 MBit/s (100BaseTX) geeignet. Natürlich kann man darüber auch 10BaseT, Token Ring oder ISDN fahren. Vorsicht vor Kabeln, die nicht nach Cat 5 sondern nach Level 5 spezifiziert sind ! Diese Kabel sind nicht BIS 100 MHz getestet sondern nur BEI 100 MHz. Es kann also theoretisch sein, dass 100BaseTX funktioniert, 10BaseT aber nicht ! Sollte heute zum Glück nicht mehr zu kriegen sein. Es wäre natürlich zu einfach, wenn das schon alles wäre, und so gibt es Cat 5 auch wieder in verschiedenen Arten: UTP ist Unshielded Twisted Pair. Keine Schirmung und inzwischen (hoffentlich) von der Genfer Konvention geächtet. S/UTP bedeutet Screened Unshielded Twisted Pair. bei diesem Kabel ist das komplette Adernbündel mit einer Metallfolie (Screen) geschirmt. Eigentlich DAS Standardkabel für Lanpartys. STP bedeutet Shielded Twisted Pair. Bei diesem Kabel sind zwar die einzelnen Adernpaare geschirmt, jedoch nicht das gesamte Kabel. Wird für Token Ring und FDDI eingesetzt. Zum Schluss der König der Cat 5 Strippen: S/STP, Screened Shielded Twisted Pair. Zusätzlich zu den einzelnen Adernpaaren ist hier auch das komplette Bündel nochmals geschirmt. Optimaler Schutz aber auch schon recht dick und unflexibel. Theoretisch die Creme de la creme, aber definitiv nicht notwendig. Sogar die Verrückten von Zock-a-lot geben sich mit S/UTP zufrieden, und dann könnt ihr das auch.

Twisted Pair wird immer als Stern verlegt, d.h. von einem zentralen Verteiler (Hub/Switch) geht jeweils ein Kabel zu einem Rechner oder zu einem weiteren Hub/Switch. Wird 100BaseTX eingesetzt, dürfen pro Strang nur 2 Hubs vorhanden sein und die maximale Ausdehnung zwischen 2 Stationen darf maximal 205m sein. Danach muss wieder ein Switch kommen, oder das Netz ist zu Ende. Manche Hersteller lassen zwar grössere Ausdehnungen zu, wenn nur Komponenten (Hubs/Switches/Karten) dieses Herstellers eingesetzt werden, aber da das auf einer Lanparty wohl nie vorkommen wird, ist es auch egal. Fällt unter die Kategorie "Nice to know".

Grundsätzlich empfiehlt es sich als Zentrale im Netzwerk einen oder mehrere Switches zu haben, die über eine genügend grosse Anzahl an Ports verfügen, um alle Server daran anzuschliessen. Weiterhin kommen an den Switch die Hubs mit den Clients sowie der Rechner von Müllhalde dran. Wenn mehrere Switches im Zentralbereich (Backbone) notwendig sind, sollte man darauf achten, dass diese Switches untereinander breitbandig verbunden sind, da man sich sonst einen Flaschenhals baut.

Ein Beispiel: 2 Switches mit je 24 Ports stehen im Backbone. An jedem Switch hängen 7 Server (und Mülhaldes Rechner !). Wenn jetzt an jeden Switch 16 Hubs mit Clients angeschlossen werden, feuern die Clients mit einer theoretischen Bandbreite von 1600 MBit/s auf den Switch. Wenn jetzt diese Clients aber dummerweise alle auf einen Server wollen, der am anderen Switch angeschlossen ist, und die beiden Switches über den verbleibenden 100 MBit/s Port verbunden sind, passen da selbst bei Full Duplex Betrieb jur 200 MBit/s durch. Und schon hat man einen schönen Flaschenhals.

Ok, dieser Fall wird seltenst eintreten, aber selbst wenn nur die Hälfte der Clients auf den anderen Switch will, fehlen euch theoretisch 600 MBit/s an Bandbreite. Also muss man die Bandbreite zwischen den Switches erhöhen, und/oder die Anzahl der angeschlossenen Hubs reduzieren.

Erhöhung der Bandbreite: Das kann man entweder durch Gigabit Ethernet Module die die Switches verbinden (teuer !), durch Zusammenfassen von 2 bis n Fast Ethernet Ports zu einem logischen Link zwischen den Switches oder durch "Stacken" der Switches erreichen. Dieses Zusammenfassen ist meist herstellerproprietär und funktioniert nur zwischen Switches vom gleichen Hersteller. Bei Cisco heisst das Fast Ethernchannel, bei 3Com Port trunking und Cogent nennt das Duralink. Nebenbei sorgen diese gebündelten Links für Ausfallsicherheit. Stacken ist das Verbinden von Switches über ebenfalls proprietäre Highspeedlinks, die im Prinzip die Backplanes der Switches koppeln. Bei 3Com Geräten (z.B. Superstack II 3300) geschieht das über den sogenannten Matrix-Port. Über diesen können serienmässig 2 Switches miteinander verbunden werden, durch Einsatz eines Matrix-Moduls sind bis zu 4 Switches in einem Stack möglich. Das bedeutet dann 96 geswitchte 10/100 MBit/s-Ports. Wenn das immer noch nicht reicht, nach oben gibt es fast keine Grenze, nur werden die Kisten dann langsam RICHTIG teuer.

In unserem Beispiel nehme man also 8 Server pro Switch, 12 Hubs pro Switch und verwende die restlichen 4 Ports, um einen 800 MBit/s Full Duplex Link zwischen den Switches aufzubauen. Das reicht zwar immer noch nicht, um den oben beschriebenen Extremfall abzudecken, aber wenn die Hälfte (statistisch guter Wert) der Clients immer auf den anderen Switch will, wären das 600 MBit/s und somit hättet ihr noch eine Reserve.

Faustregel: Der Backbone kann gar nicht fett genug sein !

3.1.1 Fehlersuche in der Verkabelung

Koaxkabel:

Im worst case (der nach Murphy immer dann auftritt, wenn eure Fete in vollem Gange ist und grade die fetten Turniere laufen) legt euch ein defekter Stecker das komplette Netz lahm (Tritt meistens bei selbstgebastelten Kabeln auf, was wieder beweist, dass es dumm ist, am falschen Ende zu sparen). Dann heisst es Multimeter und Ersatzstrippen auspacken und auf zum Fehlerschiessen (Troubleshooting) gehen.

Vorgehensweise bei Koax: Mit dem Multimeter den Widerstand an einem (nicht aufgesteckten) T-Stück messen. Der Widerstand am T-Stück bei einem korrekt terminierten Strang 25 +/-2 Ohm (2x 50 Ohm parallel, wir erinnern uns an den Physikunterricht ?) betragen. Messt ihr unendlichen Widerstand ist kein Terminator angeschlossen oder beide sind defekt. Bei 50 Ohm ist nur ein Terminator angeschlossen oder einer ist kaputt. Wenn ihr keinen (oder sehr geringen) Widerstand auf dem Kabel habt, ist irgendwo ein Kurzschluss auf dem Kabel/T-Stück/Kupplung/Netzwerkkarte/Terminator. Wenn es kein Terminator ist, alle Stationen bis auf 2 vom Netz trennen. Wenn diese beiden sich sehen können (Test mit Ping oder Quake), einen Rechner nach dem anderen anschliessen (immer weiter pingen) bis der Fehler auftritt. Bei dem Übeltäter das T-Stück tauschen. Wenn das nicht hilft, Netzwerkkarte prüfen. Bei manchen Karten kann onboard eine Terminierung eingeschaltet werden. Weg damit ! Ist die Karte richtig konfiguriert ? Wenn ja, austauschen. Sehen sich die beiden anfänglichen Stationen schon nicht, ist entweder einer der beiden Rechner der Übeltäter (Verfahren wie oben) oder ihr habt ein Kabelproblem. Dann wird das Kabel auf ein Stück mit 2 T-Stücken und 2 Endwiderständen verkürzt. Wieder messen, um Terminator auszuschliessen. Wenn das immer noch nicht klappt, anderes Kabel/T-Stück nehmen. Sobald es mit 2 Stationen funktioniert, ein weiteres Stück des Strangs dazuhängen. Wenn das klappt, an dieses Stück auch einen Rechner anschliessen. Diese Prozedur solange fortführen, bis der Übeltäter isoliert ist.

Twisted Pair Kabel:

Beim Twisted Pair fällt immer nur die Station aus, deren Karte/Kabel/Hubport defekt ist. Alle anderen sollten unbeeinträchtigt bleiben, es sei denn, eine Karte produziert Störungen, die vom Hub weitergegeben werden. Einfach den Port am Hub, das Kabel, oder die Karte (in dieser Reihenfolge) wechseln, dann sollte das Problem behoben sein. Wenn alle Stationen an einem Hub Probleme haben, ist entweder der Hub, das Kabel vom Hub zum Switch oder der Port am Switch Asche. Switch-Port, Kabel und dann den Hub wechseln. Wenn alle (wirklich alle) Stationen Probleme haben, ist entweder euer Switch Schrott (das wird nicht billig), ihr habt gerade einen Stromausfall oder ihr habt eine oder meherere der Grundregeln der Ethernet-Verkabelung missachtet (Loop gebaut ?).

3.2 Repeater/Hubs

Zuerstmal: Repeater = Hub. Punkt. Die Funktion ist absolut identisch. Repeater hiessen die Teile, als noch Koaxverkabelung "in" war (damals war auch noch alles aus Holz !). Im Zeitalter der strukturierten Verkabelung fand man Repeater auf einmal nicht mehr cool genug, also musste das Kind einen neuen Namen kriegen. Und siehe, es ward der Hub geboren. Ein Hub ist ein ziemlich dummer elektrischer Verteiler und Verstärker nach dem Prinzip Fire and Forget, der alles was auf einem Anschluss reinkommt, auf all seinen Anschlüssen wieder rausschreit. Dabei kümmert er sich weder um Inhalt noch um Ziel des Pakets, ja sogar Kollisionen mit anderen Paketen sind ihm egal. Sollen die Rechner das Paket einfach nochmal schicken, OSI Layer 2 kümmert sich schon drum. Hubs sind die simpelste Möglichkeit, ein Twisted Pair LAN mit mehr als 2 Stationen aufzubauen.

3.3 Bridges/Switches

Bevor jetzt jemand schreit: Bridge = Switch, muss ich erstmal sagen: JEIN ! Von der Funktion her ja, vom Verfahren her nein. Bridges wurden entwickelt, um 2 oder mehr Stränge miteinander zu verbinden, Pakete aber nur in den Strang zu schicken, in dem das Paket auch gebraucht wird. Eine Bridge lernt die MAC-Adressen der angeschlossenen Geräten und leitet ein Paket aus Strang A nur in Strang B weiter, wenn die Zielstation auch in Strang B ist. Ansonsten kriegt Strang B nichts davon mit. Dieses Verfahren reduziert den Traffic und damit die Kollisionen im Netz. Eine Bridge verbindet also Kollisionsdomänen. Während die ersten Bridges aber noch jedes Paket komplett analysierten und dieser Algorithmus oft softwarecodiert war, verfolgen Switches einen anderen Ansatz. Ein Switch leistet prinzipiell das gleich wie eine Bridge, analysiert jedoch nicht das komplette Paket sondern nimmt das Paket nur soweit auseinandern, bis er die MAC-Adresse der Zielstation herausgefunden hat. Daraufhin schaut er wie eine Bridge in seine Tabelle, um rauszufinden, an welchem seiner Ports die Zielstation angeschlossen ist und schaltet die beiden Ports, die miteinander reden wollen über seine Backplane direkt zusammen. Da ein Switch heutzutage sowas aber nicht mehr softwaremässig erledigt, sondern die komplette Intelligenz in hochspezialisierten Chips (ASICs) sitzt, ist ein Switch um ein vielfaches schneller als eine klassische Bridge. Ein Switch ist also eine Multiport-Highspeed-Bridge. Die Backplane ist ein entscheidendes Kriterium bei einem Switch. Wenn ein Switch 8 100BaseTX Ports hat, können dort theoretisch 8 Stationen mit je 100 MBit/s angeschlossen sein, die natürlich auch noch Full Duplex betreiben wollen um alle Kollisionen zu elimieren. Macht also 4 Paare mit je 200 MBit/s Bandbreite. Die Backplane des Switches sollte also im Optimalfall 800 MBit/s verkraften können, sonst kann der teure Switch, den ihr euch von was weiss ich abgespart habt, unter Last zum Flaschenhals werden !

3.4 Router

Ein Router verbindet prinzipiell verschiedene Netze miteinander. Dabei ist es egal, ob die Netze auf 10MBit, 100Mbit, Token Ring, FDDI, ISDN oder sonstwas aufbauen, es kommt nur aus das Protokoll im Layer 3 an. Es werden also die logischen Netze miteinander verbunden, so dass zwei Segmente in denen z.B. IP gesprochen wird miteinander kommunizieren können. Um das zu bewerkstelligen, muss ein Router jedes Paket, dass an ihn geschickt wird, auseinandernehmen, bis er die Zieladresse rausgefunden hat. Anhand der Zieladresse und seiner Routing-Tabelle (in der steht, über welches Interface oder weiteren Router das jeweilige Zielnetz zu erreichen ist) kann der Router entscheiden, auf welchem seiner Interfaces (es können theoretisch beliebig viele sein) das Paket rausgeschickt wird. Das hat den Vorteil, dass nur im Quell- und Zielnetz (und eventuellen dazwischen liegenden Netzen) das Paket überhaupt auftaucht. Alle anderen Netze, haben damit nichts zu tun, brauchen sich also nicht darum zu kümmern und haben somit auch keinen Traffic. Vom Effekt her machen Switches etwas ähnliches, aber ein Switch leitet Broadcasts weiter, was ein Router nicht tut (es sei denn, man sagt es ihm explizit). Warum brauche ich überhaupt einen Router ? Für eine reine LAN-Party braucht ihr überhaupt keinen Router, denn selbst wenn ihr über die 254 gültigen Adressen eines Class-C IP-Netzes hinauskommt (wer solche Parties veranstaltet, sollte das hier nicht lesen müssen !), nehmt ihr einfach ein Class-B Netz/Maske und seid saniert, denn um den Bereich von 65.535 Adressen auszulasten... Spätestens, wenn ihr eine Internet-Anbindung für eure Gäste während der Party anbieten wollt, braucht ihr einen Router, der euer Ethernet-IP-Netz mit dem Internet verbindet. Das muss natürlich nicht unbedingt eine von den edlen Hardware-Kisten sein, ein Linux-Rechner mit einer Ethernet- und einer ISDN-Karte tut es für den Anfang auch.

11000000 10101000 00000001 00000000 = 192.168.1.0 heraus.

Ping wird ausgeführt für 192.168.1.1 mit 32 Bytes Daten:

Antwort von 192.168.1.1: Bytes=32 Zeit<10ms TTL=255

Antwort von 192.168.1.1: Bytes=32 Zeit<10ms TTL=255

Antwort von 192.168.1.1: Bytes=32 Zeit<10ms TTL=255

Antwort von 192.168.1.1: Bytes=32 Zeit<10ms TTL=255

Ping-Statistik für 192.168.1.1:

Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.:

Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

C:\WINDOWS>

Euer Rechner schickt zuerst einen ARP-Broadcast los, um die MAC-Adresse zu der anzupingenden IP-Adresse rauszufinden. Nachdem die Antwort des Zielrechners eingetroffen ist, wird ein ICMP-Echo-Request an den anderen Rechner geschickt, dieser beantwortet sie mit ICMP-Echo-Reply Paketen, nachdem er ebenfalls durch einen ARP-Request eure MAC-Adresse rausgefunden hat.

Wenn ihr eine Rückmeldung wie Zeitüberschreitung der Anforderung oder Zielhost nicht erreichbar erhaltet, stimmt etwas nicht.

In einem Netz ohne Router (d.h. eure Workstation hat kein default gateway) kann folgendes passieren:

Zeitüberschreitung der Anforderung/Request timed out: Die IP-Adresse gibt es nicht in eurem Netz, bzw. der Rechner ist gerade nicht an.

Zielhost nicht erreichbar/Destination host unreachable: Die Adresse, die ihr anpingt befindet sich in einem anderen Subnet und eure WS weiss nicht, wie sie dahin kommen soll (kein Router vorhanden).

In einem gerouteten Netz (d.h. es gibt einen Router und eure WS hat ihn als default Gateway eingetragen) kann folgendes passieren:

Zeitüberschreitung der Anforderung/Request timed out: Die IP-Adresse gibt es nicht in eurem Netz, bzw. der Rechner ist gerade nicht an. Wenn die angepingte Adresse in einem anderen IP-Netz liegt, ist die Station dort nicht vorhanden oder kennt den Rückweg in euer Netz nicht, da sie kein Gateway eingetragen hat. Dann kommt euer Paket zwar am Ziel an, die Antwort kommt jedoch nie zurück. Es könnte auch sein, dass der/ein Router, der die Verbindung zwischen den Netzen herstellt, den Rückweg in euer Netz nicht kennt. Probiert einfach auf der anderen Station (sofern sie läuft) den Ping in umgekehrter Richtung. Dort muss dann ein Zielhost nicht erreichbar/Destination host unreachable. Überprüft auf dieser Station das default Gateway und eventuelle Router dazwischen, ob der Weg klar definiert ist.

Zielhost nicht erreichbar/Destination host unreachable: Eure Station weiss nicht, an welchen Router das Paket zu schicken ist, damit es das Ziel erreicht, oder der/ein Router auf dem Weg kennt den Weg nicht. Prüft, ob das richtige default Gateway eingetragen ist und ob alle Router die korrekten Einträge haben.

4.3 LAN-Party-relevante Dienste

Hier wird noch nicht auf die Konfiguration der einzelnen Dienste eingegangen, sondern es werden nur die wichtigsten vorgestellt und es wird erklärt, was sie machen und warum man sie brauchen könnte.

4.3.1 DHCP

Wofür brauche ich DHCP, was sind Vor- und Nachteile ? Es ist extrem wichtig, darauf zu achten, dass keine IP-Adresse doppelt vergeben wird, denn dann werden die Rechner mit den identischen Adressen ihre TCP/IP-Stacks deaktivieren (oder zumindest der, der es zuerst bemerkt) und nichts mehr in Richtung TCP/IP unternehmen. Um diese Verteilung sicher zu stellen, teilt ihr entweder jedem Teilnehmer SCHRIFTLICH seine IP-Adresse und die Maske mit (ob er sie auch richtig eintragen kann, ist eine andere Sache), oder ihr weist jeden Teilnehmer darauf hin, dass die IP-Adressen automatisch per DHCP vergeben werden. Dazu ist es notwendig, dass alle Rechner, die keine feste IP-Adresse benötigen, so eingestellt werden, dass sie diese automatisch anfordern. Server sollten eine feste Adresse haben. Könnt ihr euch das Chaos vorstellen, wenn nach einem Absturz/Reboot der NT-Server auf dem HTTP-und FTP-Server laufen eine ganz andere IP-Adresse hat ? Wie soll man den dann noch wiederfinden ? Natürlich müsst ihr darauf achten, dass der DHCP die Adressen der Server nicht auch noch an die Clients verteilt. Ein DHCP-Server kann aber mehr als nur IP-Adressen zuweisen. Er kann eine Unmenge an Parametern an die Clients übergeben, wie z.B. das default Gateway, den primären und sekundären DNS-und/oder WINS-Server, die Subnet-Maske, die Broadcast-Adresse, den Timeserver, das zu benutzende X-Display und lauter so einen Kram. Die meisten davon braucht ihr nicht, aber die Übergabe von default Gateway und Nameservern ist schon extrem praktisch. Ihr könnt auch festlegen, ob ein Client die Adresse aus einem Pool erhält, oder ob die zu vergebende Adresse fest der MAC-Adresse des Clients zugeordnet wird. Dieses Verfahren stellt sicher, dass ihr wisst, wer welche IP-Adresse kriegt, dürfte allerdings auf grösseren Parties nicht praktikabel sein, da ihr dafür vorher die MAC-Adressen der Client wissen solltet. Nachteil des DHCP-Servers ist ganz klar, dass es davon nur einen geben sollte. Wenn jetzt irgendein Spassvogel (aus Bos- oder Dummheit) einen zweiten DHCP-Server laufen lässt, der unter Umständen vollkommen blödsinnige Adressen (oder die gleichen wie ihr) verteilt, kriegen und nehmen die Clients die Adresse von dem Server, der zuerst antwortet, auch wenn diese Adresse den Rechner aussperrt. Beispiel: Ihr verwendet 192.168.1.0/255.255.255.0 und lasst den Bereich 100 bis 254 verteilen. Der andere Server verteilt Adressen 1.2.3.4 bis 1.2.3.254. Ein Rechner mit so einer Adresse wird natürlich nie im Leben eure Gameserver finden und das Geschrei geht los. Ich würde in die Rules einer Party reinschreiben, dass jeder, der ausser den Admins einen DHCP laufen lässt, einfach rausfliegt, denn so ein Server ist (wenn auch nicht ganz einfach) zu lokalisieren und damit auch zu entsorgen. Davor schützt ihr euch natürlich mit festen IP-Adressen. Somit habt ihr auch anhand der Platzverteilung einen Überblick, wer welche Adresse hat. Wenn alle brav ihre Adresse richtig eintragen, wird es keine doppelten IPs geben und der DHCP des Möchtegern-Hackers kratzt euch soviel wie es die deutsche Eiche kratzt, wenn sich die Wildsau an ihr schabt. Natürlich muss man dann voraussetzen, dass jeder seine IP und Maske richtig einträgt und eventuell auch default Gateway, DNS-und WINS-Server korrekt hinzufügt, und das klappt im Leben nicht auf Anhieb. Make it idiotproof, and someone will make a better idiot !

4.3.2 DNS

4.3.3 FTP

Ein FTP-Server ist quasi ein Muss für eine Party. FTP stellt die ideale Möglichkeit dar, um Patches, Mods, Maps und Treiber zur Verfügung zu stellen. Den Sinn und die Bedienung eines FTP-Clients muss und werde ich hier nicht erklären. Natürlich kann man per FTP auch Warez, MP3z, Pornz and other evil Ztuff zur Verfügung stellen, aber das muss/darf man ja nicht. Das machen die User schon untereinander per Windows-Freigabe ;-).

4.3.4 HTTP

Ein Webserver ist ebenfalls essentiell für eine LAN-Party und mit einem Browser kann wohl jeder umgehen, sonst könntet ihr das hier ja nicht lesen. Auf dem Webserver könnt und sollt ihr Informationen wie z.B. die Namen/Adressen der Gameserver optisch ansprechend publizieren, eine Turnieranmeldung und -ergebnisbekanntgabe kann ebenfalls darüber realisiert werden, oder ihr macht es wie Octogon: In Ermangelung eines eigenen Caterings haben die Jungs auf ihrer Intranetseite einen McDonalds-Bestellservice eingerichtet. Dort kann jeder eintragen, was er haben will, bei den Orgas bezahlen, und einmal pro Stunde wird der Kram zentral geholt. Hat bis auf ein paar vergesse Getränke prima funktioniert :-).

4.3.5 ICQ/IRC

Macht auf grösseren Parties Sinn, um z.B. seine Turniergegner zu finden. Bei Kellerparties oder 20 bis 50 Mann Sessions ist er noch nicht nötig, da diese Feten überschaubar genug sind, um mal eben durch den Keller/Saal nach seinem Gegner zu rufen oder grade hinzugehen. Wenn aber meherere 100 in der Halle sitzen, von denen man vielleicht 20-30 kennt kann ein kleiner Chat die Sache enorm erleichtern, da dann die physikalische Location des Gegners keine Geige spielt. Ausserdem kann so ein kleiner Chillout-Chat ganz lustig sein.

4.3.6 NBNS/WINS