252 lines
11 KiB
Plaintext
252 lines
11 KiB
Plaintext
Portland State University Computer Science Group David Westgate
|
|
Request for Comments: CS594 30 Nov 2023
|
|
|
|
|
|
Internet Relay Chat Protocol
|
|
|
|
Status of This Memo
|
|
This memo defines a personal re-implementation of the already well established Internet Relay Chat Protocol, by presenting a simplified version using a subset of the full feature list defined in RFC 1459. This protocol does not add anything new to the well established IRC protocol, and is intended for academic purposes.
|
|
|
|
Abstract
|
|
The IRC Protocol was developed in the late 1980's as a simple method for internet users to communicate in real time, with the ability to organize various combinations of groups of users. Although once a popular means of internet communication, IRC has to some extent become niche as other instant messengers and social media platforms have become mainstream. IRC is uniquely fascinating from a privacy perspective in that anyone can run a server for their friends or the world and ensure they are the custodians of their data.
|
|
|
|
|
|
Table of Contents
|
|
|
|
1. Introduction, Scope
|
|
2. Protocol Overview
|
|
2.1. Basic Features
|
|
2.2. Opcodes
|
|
2.3. Communication Flow
|
|
3. Server
|
|
3.1. Server Initialization
|
|
3.2. Handling Clients
|
|
3.3. User Management
|
|
3.4. Room Management
|
|
3.5 Commands
|
|
3.5.1 0 - Quit
|
|
3.5.2 1 - List connected users
|
|
3.5.3 2 - List rooms
|
|
3.5.3 3 - Broadcast message
|
|
4. Client
|
|
4.1. Client Initialization
|
|
4.2. User Interaction
|
|
4.3. Commands
|
|
4.3.1 {message}
|
|
4.3.2 /msg [room] {message}
|
|
4.3.3 /list [room]
|
|
4.3.4. /join {room name}
|
|
4.3.5. /leave {room name}
|
|
4.3.6. /quit
|
|
5. Error Handling
|
|
5.1 Codes
|
|
5.2. Errors
|
|
5.2.1 Client attempts to message a room which does not exist
|
|
5.2.2 Nickname collision (a new users attempts to choose the same nickname as an already active user)
|
|
5.2.3 Client does not get a message for 30 seconds
|
|
5.2.4 Out-of-order registration
|
|
5.2.5 Joining the same room twice
|
|
5.2.6 Leaving a room not yet joined
|
|
5.2.7 Leaving a that does not exist
|
|
6. Conclusion
|
|
6.1. Limitations/Omissions
|
|
6.2. Security Considerations + Privacy
|
|
6.3. Future
|
|
6.4. References
|
|
|
|
1. Introduction, Scope
|
|
Internet Relay Chat uses a client-server architecture to allow users (identified by nicknames) running a client application to establish a connection to a server application. Once connected, clients will be able to create, join, and leave multiple rooms, as well as send messages to other clients who are also members of those rooms. These are the core functionalities. Clients are also able to perform functions such as list all of the available rooms to join on the server, as well as listing all members of any particular room. Individual messages that clients send may be to one room, or all of the rooms joined so far.
|
|
|
|
2. Protocol Overview
|
|
This IRC protocol is implement as a payload over TCP. TCP is a natural base layer protocol choice over IP for its ability to ensure data arrives uncorrupted and in-order.
|
|
|
|
2.1. Basic Features
|
|
The protocol specifies “messages” sent from client to server, or server to client. Each message shall be composed of command, and optional command parameter if relevant. Commands are one of an 8 bit operation code (hexadecimal 01 to 0F), followed immediately by the opcode parameter
|
|
|
|
2.2. Opcodes
|
|
Each opcode listed below will be elaborated on in the relevant section. If the opcode is expected to be followed by a parameter, it is shown in {}.
|
|
|
|
TBD = 0x00
|
|
JOIN_ROOM = 0x01
|
|
JOIN_SERVER = 0x02
|
|
LEAVE_ROOM = 0x03
|
|
LIST_ROOMS = 0x04
|
|
MESSAGE = 0x05
|
|
REGISTER_NICK = 0x06
|
|
LIST_USERS = 0x07
|
|
LIST_USERS_IN_ROOM = 0x08
|
|
MESSAGE_ROOM = 0x09
|
|
QUIT = 0x0B
|
|
KEEP_ALIVE = 0x0C
|
|
RESPONSE = 0x0D
|
|
RESPONSE_OK = 0x0E
|
|
ERROR = 0x0F;
|
|
|
|
2.3. Communication Flow
|
|
Both the client and server may send instructions by writing TCP streams, which are the above Opcodes followed by their optional parameters. Both applications should expect a RESPONSE to each instruction, again which may have an optional parameter. Which codes may be sent from client or server, and maybe interpreted by each depend on the specific code.
|
|
|
|
3. Server
|
|
It is critical the server application run with stability and accuracy to ensure client messages are correctly received, processed, and acted upon. Upon stopping the server, a QUIT signal and 0 byte stream will be written to each client to facillitate graceful stopping.
|
|
|
|
3.1. Server Initialization
|
|
On start-up the server will listen for TCP connections on port 6667. If successful, the server application will start in a new state.
|
|
|
|
3.2. Handling Clients
|
|
From this point, the server is responsible for keeping track of how many channels exist, the names of each channel, and the users associated with (joined on) each channel. Also, a list of the currently connected users by their nicknames and tcp stream references will be kept track.
|
|
|
|
3.3. User Management
|
|
User management is handled simplistically. There is no authentication among nicknames, and the honor system will be relied on to prevent impersonation.
|
|
|
|
3.4. Room Management
|
|
Rooms are to be created implicitly, as soon as the first user joins a room by a unique name, and rooms will be implicitly destroyed when the last user leaves. Rooms will be identified by an alphanumeric name, and are case sensitive. Messages sent to a room will be automatically forwarded by the server to all users in the room aside from the sender. Users who are part of a room and then disconnect from the server, will be automatically removed from the room.
|
|
|
|
3.5 Commands
|
|
The server may run some basic diagnostic commands
|
|
|
|
3.5.1 0 - Quit
|
|
Send QUIT to each client, close each TCP connection and stop the server application
|
|
|
|
3.5.2 1 - List connected users
|
|
Print out all connected users, and information from their TCP connection
|
|
|
|
3.5.3 2 - List rooms
|
|
Print out all rooms and their associated users
|
|
|
|
3.5.3 3 - Broadcast message
|
|
Enter a message as a parameter to SEND_MESSAGE to each user.
|
|
|
|
4. Client
|
|
Clients are the users, running the client application on their local machines.
|
|
|
|
4.1. Client Initialization
|
|
Clients will first be prompted to choose a nickname. After this the client will then be prompted to enter the host-name of the server they wish to connect to. Client will ask to REGISTER_NICK on the host, and await a RESPONSE_OK or ERROR before the main client loop begins.
|
|
|
|
4.2. User Interaction
|
|
After a RESPONSE OK from attempting to register their nickname, the client is now a user of the server. The client application will present them with the standard input and output to show the information, server messages, and prompt for keyboard input
|
|
|
|
4.3. Commands
|
|
The following commands are available on the standard input to users who have successfully connected to a host. The /help command will also list these
|
|
|
|
4.3.1 {message}
|
|
Any standard input not starting with / is assumed to be a message for the current active room. It is transmitted as a SEND_MESSAGE {message} operation
|
|
|
|
4.3.2 /msg [room] {message}
|
|
MESSAGE_ROOM command, one room name must be included, followed by a space and then the message. There are a number of potential errors with this command which will be explored in the error handling section
|
|
|
|
4.3.3 /list [room]
|
|
A simple command which shall send LIST_ROOMS operation to the server with the room name and show the user the RESPONSE {data} , which is expected to contain a list of users in the given room, if it exists.
|
|
|
|
4.3.4. /join {room name}
|
|
Send a JOIN_ROOM operation with the room name and await a RESPONSE OK from the server. This is not expected to encounter any specific errors, as rooms which do not already exist are created.
|
|
|
|
4.3.5. /leave {room name}
|
|
Send a LEAVE_ROOM operation with the room name and await a response. This may have errors
|
|
|
|
4.3.6. /quit
|
|
Send a QUIT operation to the server and stop the client application.
|
|
|
|
5. Error Handling
|
|
Errors may occur in various ways, the most likely being an illegal instruction sent from the client. Network or connection errors may also occur and must be handled gracefully.
|
|
|
|
5.1 Codes
|
|
Error codes shall be 8 bit values both understood by the client and server
|
|
INVALID_ROOM = 0x10
|
|
NICKNAME_COLLISION = 0x11
|
|
SERVER_FULL = 0x12 # Not used
|
|
ALREADY_REGISTERED = 0x13
|
|
NOT_YET_REGISTERED = 0x14
|
|
MALFORMED = 0x15
|
|
ALREADY_IN_ROOM = 0x16
|
|
NOT_IN_ROOM = 0x17
|
|
EMPTY_ROOM = 0x18
|
|
|
|
5.2. Errors
|
|
These are the various anticipated possible errors between client/server flows
|
|
|
|
5.2.1 Client attempts to message a room which does not exist
|
|
The server will respond INVALID_ROOM
|
|
|
|
5.2.2 Nickname collision (a new users attempts to choose the same nickname as an already active user)
|
|
The server will respond NICKNAME_COLLISION
|
|
|
|
5.2.3 Client does not get a message for 30 seconds
|
|
The client will send a KEEP_ALIVE message every 10 seconds, and expected a RESPONSE_OK. If the client does not read any TCP stream for 30 seconds, the server is assumed unresponsive and the client will self terminate.
|
|
|
|
5.2.4 Out-of-order registration
|
|
It should not be possible, but if the client attempts to register a nickname a 2nd time, the server will respond ALREADY_REGISTERED. If the client attempts to send commands before registering a nickname, the server will respond NOT_YET_REGISTERED
|
|
|
|
5.2.5 Joining the same room twice
|
|
The server will respond ALREADY_IN_ROOM
|
|
|
|
5.2.6 Leaving a room not yet joined
|
|
The server will respond NOT_IN_ROOM
|
|
|
|
5.2.7 Leaving a that does not exist
|
|
The server will respond INVALID_ROOM
|
|
|
|
6. Conclusion
|
|
|
|
6.1. Limitations/Omissions
|
|
This IRC implementation knowingly omits useful features that mainstream IRC implements, for the sake of simplicity. These include (but are not limited to) the following:
|
|
Private messages between users
|
|
Server admins and channel operators
|
|
Server to Server distributed architecture
|
|
File transfers
|
|
Metadata like channel topics
|
|
Away messages
|
|
Password based authentication
|
|
Real name/nickname associations
|
|
Rich text interpretation
|
|
Encryption
|
|
Version validation
|
|
Non-english client application support
|
|
Server whitelist/blacklist
|
|
|
|
6.2. Security Considerations + Privacy
|
|
Since the body of TCP packets are visible to the network and could be snooped on by a potentially interested party, modern web applications generally run on an encryption layer like SSL or TLS. However, due to the extra complexity of including such a layer in this application, transmission will be both sent and received unencrypted. Therefor, the application will remind the user before each session not to send sensitive or private information with this application.
|
|
|
|
6.3. Future
|
|
This IRC implementation attempts to faithfully provide reliable internet chat for a group of users who trust one another, and to give them the ability to organize by channel. Of the noted omissions, the must urgent future update will include version validation, followed by an SSL encryption layer. Secondary future feature needs will focus on authentication, private messaging, seperate room muxing/switching. Ideally, all remaining omissions would be included in the later future.
|
|
|
|
6.4. References
|
|
References listed have helped inspire this RFC
|
|
|
|
IRC 1459
|
|
https://datatracker.ietf.org/doc/html/rfc1459
|
|
|
|
CS594 Sample RFC
|
|
https://canvas.pdx.edu/courses/74411/files/8984668/download?download_frd=1
|
|
|
|
IRC Grading Criteria
|
|
https://canvas.pdx.edu/courses/74411/files/8984635/download?download_frd=1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|