Oblig4-Gruppe1)
Fra Hiofwiki
Innhold |
Materiell fra fremføring
Notater
Ideene bak RFC
En-til-en (one-to-one)
- Nesten alltid av klienter
- Server-server trafikk er nesten aldri grunnet servere som snakker sammen
- På grunn av sikkerhet: beskjeder blir sent EN vei. Korteste vei
En-til-mange (one-to-many)
- Til en liste: Ikke effektiv. Blir som unicast. Sender flere ”strømmer”. Samme prinsipp som å sende mail til mange. Bare ramser opp brukernavn
- Til en gruppe (channel): beskjeden blir levert EN gang til serveren som sender strømmen til kanalen
En-til-alle (one-to-all)
- Client-til-client. Aldri mulig da det ikke er noen kommando som lar en klient sende beskjed til alle andre klienter.
- Client-to-Server. Hvis man f.eks. blir med i en kanal, endrer brukerstatus eller f.eks. brukernavn.
- Server-to-Server. De fleste beskjeder som blir sendt mellom servere sendes til alle servere.
Valgfrie kommandoer
- AWAY - sender ut en status-melding satt til away.
- REHASH (o) - tvinger serveren til å lese konfigurasjonsfilen på nytt.
- RESTART (o) - tvinger serveren til å restarte.
- SUMMON - spør brukere som er på en host på en IRC-server om å joine IRC.
- USERS - lister opp brukerne som er koblet til serveren.
- WALLOPS - sender en melding til opperatørene som er online på en gitt server.
- USERHOST - returnerer informasjon om etterspurte brukere.
- ISON - returnerer hvorvidt en bruker er online eller ikke.
Autentisering
IP-adresse sendes først for å godkjennes Deretter sjekkes passord. Passord for klienten sjekkes hvis dette er krevd, og alltid passord serverene imellom. Blir mer og mer vanlig at brukernavnet til den ansvarlige bak tilkoblingen sjekkes og autoriseres, da ofte gjennom en sjekk opp mot en IDENT-server.
Implementering
På transportlaget brukers TCP siden det er en pålitelig og trygg nettverksprotokoll som passer bra til denne skalaen dataoverføring. Unix sockets er mellomleddet mellom transportlaget og applikasjonslaget der IRC ligger.
Kjente problemer
Skalering
Ved store sammenhenger passer ikke protokollen veldig bra, ettersom alle servere i et nettverk skal ha informasjon om alle andre servere i samme nettverk i tillegg til samtlige brukere.
Skal også vite om alle endringer som skjer, når de skjer.
Labler
Det er 3 typer labler i IRC-protokollen. Brukernavn (nick), kanaler og servere.
Brukernavn
Brukernavn er vel så bra å ha når man skal snakke sammen og identifisere hverandre, men de kan endres hele tiden, og hvis to brukere prøver å skaffe samme brukernavn, vil enten en mislykkes eller begge vil bli fjernet ved å bruke KILL
Kanaler
Alle servere skal alltid vite om alle kanaler og hvem som er i dem. Dette er ikke bare et skaleringsproblem, men også et personvernsproblem.
Tilsvarende og konkurrerende protokoller
MIcrosoft lagde i 1998 en videreutvikling av IRC-protokollen som de kalte IRCX. Der X'en står for extensions. Protokollen definerer et par nye funksjoner, deriblant SASL-autentikasjon (sikkerhetsautentikasjon når du kobler deg til en server), metadata om en server (informasjon om serveren) og full støtte for UTF-8 (i brukernavn, servernavn osv). Denne protokollen var proprietær, altså ikke åpen. Protokollen ble brukt på Microsoft Exchange 5.5, og senere videreutviklet inn i MSN Chat. Microsoft utviklet også MSN .NET Messenger Service. Dette var ingen videreutvikling av IRC-protokollen, men en tjeneste som allikevel har en del fellestrekk med IRC. Denne tjenesten som de fleste kjenner til, kan brukes gjennom flere klienter i tillegg til MSN sin egen Messenger. De fleste bruker sikkert f.eks. Adium. Det finnes flere, blant annet BitlBee, Meebo, KMess (Linux) og Mercury Messenger.
Hvordan har protokollens utviklet seg? Hvilke eldre RFC-er er den eventuelt basert på?
Protokollen baserer seg ikke på noen tidligere RFC'er, men som nevnt tidligere så brukte Oikarinen Bitney Relay chat service som inspirasjon til sin første IRC-klient. Det har i senere tid blitt utviklet flere nye protokoller (RFC 2810, RFC 2811, RFC 2812 og RFC 2813) som beskriver nye funksjoner. Men disse forandringene har ikke blitt mye brukt.
