Scribd
Upload
21 views12 pages

Irc Ov

Uploaded by

Ayush Kushwaha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
21 views12 pages

Irc Ov

Uploaded by

Ayush Kushwaha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 12

Internet Technology & Web Engineering

Internet Relay Chat (IRC)

Dipl.-Inform. Matthäus Wander


Universität Duisburg-Essen
Overview

∙ Distributed system for real-time text chat


∙ Users have nicknames
∙ One-to-one chat between users
∙ One-to-many group chat in channels
∙ Multiple independent networks co-exist
∙ Each network consists of 1..n IRC servers
∙ Started in 1988, first RFC 1459 appeared 1993
∙ Current RFCs 2810-2813 are outdated
∘ RFCs describe version 2.10, reference implementation is 2.11
∘ Other networks use adapted server software

Distributed Systems Matthäus Wander 2


University of Duisburg-Essen
IRC Client

Distributed Systems Matthäus Wander 3


University of Duisburg-Essen
Architecture

∙ Client/Server
∘ Control data shared by all servers
∘ Chat messages routed as needed
∙ Multicast tree structure (no cycles)
∙ All servers trusted in a network
∘ Manual setup of server links
∙ Text-based data transfer
∙ TCP connections

Distributed Systems Matthäus Wander 4


University of Duisburg-Essen
IRC Protocol

∙ Text-based protocol
∘ 8-bit messages except NUL (0x00), CR, LF
∘ No character set specified (usually ISO 8859-1, recently UTF-8)
∘ Nickname characters: A..Z, a..z, 0..9, {, |, }, ~, [, \, ], ^, `, _, -
∙ Stateful session
∙ Asynchronous message communication
∘ No strict command/reply – reply may follow later
∙ Authentication optional
∘ Plaintext login/password (rarely for users)
∘ DNS Hostname Lookup
∙ SSL/TLS optional (rarely for users in popular networks)

Distributed Systems Matthäus Wander 5


University of Duisburg-Essen
Example Client Session
NICK Bob
USER Bob Bob random.ircd.de :Robert Example
:Uni-Erlangen.DE 020 * :Please wait while we process your connection.
:Uni-Erlangen.DE 433 * Bob :Nickname is already in use.
NICK MightyBob
:Uni-Erlangen.DE 001 MightyBob :Welcome to the Internet Relay Network
[email protected]
:Uni-Erlangen.DE 002 MightyBob :Your host is Uni-Erlangen.DE, running
version 2.11.1p1
[...]
JOIN #example
:[email protected] JOIN :#example
:Uni-Erlangen.DE 332 MightyBob #example :This is some topic
:Uni-Erlangen.DE 333 MightyBob #example [email protected]
1331976347
:Uni-Erlangen.DE 353 MightyBob = #example :@Alice @Bob MightyBob
:Uni-Erlangen.DE 366 MightyBob # example :End of NAMES list.
PRIVMSG #example :What’s up, guys?
:[email protected] PRIVMSG #example :Nothing much
QUIT :boooring
ERROR :Closing Link: MightyBob[[email protected]] ("boooring")

Distributed Systems Matthäus Wander 6


University of Duisburg-Essen
Message Format
JOIN #example
:Uni-Erlangen.DE 433 * Bob :Nickname is already in use.
:[email protected] PRIVMSG #example :Nothing much

∙ Prefix (optional)
∘ Client: unused
∘ Server: Indicates command originator
∙ Command
∘ Literal or numeric
∙ Up to 15 command parameters separated by whitespace
∘ Colon („:“) indicates last parameter
∘ Last parameter may contain whitespaces
∙ Line length ≤ 512 characters (including CR LF)

Distributed Systems Matthäus Wander 7


University of Duisburg-Essen
Channels

∙ Users can join and part channels


∙ First user joining becomes channel operator
∘ Can give operator privilege to other users
∘ Operator(s) can change channel modes, invite/kick users, …
∘ User loses privilege when leaving/disconnecting
∙ Operators set/unset channel modes
∘ MODE #foo +o Bob: give operator privilege
∘ MODE #foo +b *!*@*.de: ban hostmask (prohibit joining)
∘ Other modes: moderated, invite only, channel password, etc.
∙ Channel prefix determines type, e.g. #example
∘ # regular (mostly used)
∘ + modeless (no operators)
Distributed Systems Matthäus Wander 8
University of Duisburg-Essen
Server-to-Server Connections

∙ All IRC servers in network must know all other servers,


users, channels and modes
∘ Scalability issues in large networks
∙ No redundant pathes (acyclic network graph)
∘ If server link breaks down, the network splits
∙ If servers connect to each, the network joins
∘ Servers exchange known servers, users, channels and modes
∙ Nickname collision → drop both („KILL“ message)
∘ Abuse netsplits to drop other users
∙ Channel collision → merge users with their privileges
∘ Abuse netsplits to obtain chanop (channel takeover)

Distributed Systems Matthäus Wander 9


University of Duisburg-Essen
Handling Collisions

∙ Nickname/channel delay during netsplit


∘ Known nicknames remain blocked
∘ Known empty channels don‘t give chanop
∙ Timestamping creation time of nickname/channel
∘ Nicknames/channels remain available during netsplit
∘ When network joins, the older ones are privileged
∙ Assign unique user IDs
∘ If nickname collides, rename both users to their IDs
∙ Still, propagation delay can desync a channel
MODE #example MODE #example
-o Bob -o Alice
Alice Bob
Distributed Systems Matthäus Wander 10
University of Duisburg-Essen
Connection Timeout & Flood Control

∙ PING message to detect connection timeouts


∘ PING must be replied with PONG
∙ Users can cause high traffic in network
∘ Channel hopping, spamming users on other server
∙ Flood control with „penalty“ seconds
∘ For every user message, process and add +2 penalty seconds
∘ Penalty decrements when nothing is received (minimum: 0 sec)
∘ Do not process messages if penalty ≥ 10
∘ May add penalty seconds for ressource-intensive messages
∙ Allows for small bursts of up to 5 messages
∙ Drop user („Excess Flood“) if input buffer overflows

Distributed Systems Matthäus Wander 11


University of Duisburg-Essen
Conclusion

∙ Distributed real-time chat system


∙ Name collisions (drop other users, obtain chanop)
∘ DDoS attacks against IRC networks to cause netsplits
∘ Technical measures to reduce exploitation of collisions
∙ Still, consistency is not enforced (channels can desync)
∙ Scalability is limited, but not a serious problem anymore
∘ Ressources increased, number of users decreased
∙ RFC specification outdated
∙ No user privacy (see SILC for a secure system)

Distributed Systems Matthäus Wander 12


University of Duisburg-Essen

You might also like