Internet delayed conversation: Architecture (RFC-2812: Internet Relay Chat: Architecture)

Internet delayed conversation: Architecture
(Internet Relay Chat: Architecture)

The status of the memo.
This Memorandum provides information to internet groups. It does not set any Internet standards and can be released without restrictions.
Copyright (c) the Internet Society (2000). All rights reserved.

Abstract:
The IRC protocol is used for text conversations. It was first implemented in 1989 and used for conversations between BBS users.
In May 1993, RFC 1459 (IRC) formally established it in the form of literature, and it will continue to develop in the future.
This document describes the current structure of the IRC protocol and the roles of its components in the entire protocol.
Other documents detail the protocols defined here between various components

Directory
1. Introduction 2
2. Component 2
2.1 Server 3
2.2 client 3
2.2.1 user client 3
2.2.2 service client 3
3. Structure 3
4. IRC protocol service 3
4.1 client positioning 4
4.2 message delay 4
4.3 channel Collection and Management 4
5. IRC concept 4
5.1 one-to-one communication 4
5.2 + 4
5.2.1 and Channel 5
5.2.2 mask the network to a host/Server 5
5.2.3 to a series of goals 5
5.3 To all 5
5.3.1 client to Client 5
5.3.2 client to Server 6
5.3.3 server to Server 6
6. Current issue 6
6.1 available range 6
6.2 reliability 6
6.3 network congestion 6
6.4 confidentiality 6
7. Confidentiality 7
8. Current support and access channels 7
9. Thanks 7
10. References 7
11. Author address 7
12. Complete copyright 8
Thank you 8

1. Introduction
The IRC protocol for text conversations has been designed for many years. This document describes
Its current architecture.
The IRC protocol is based on the customer server model and can run on many machines in a distributed manner. A typical
The setting involves a process (server), which acts as the central point to receive connections from the customer (or other servers) and implements
Required message transmission/multi-technology and other functions.
This distribution model requires each server to have global status information, which limits the performance of a network.
Therefore, this Protocol is the most intolerable issue. The existing network can be incredibly fast
We must thank hardware manufacturers for providing us with more powerful systems than ever before.
2. Components
The following sections define the basic components of the IRC protocol.
2.1 servers
The server is the backbone of IRC because it is the only component in the protocol that can connect all other components:
Provides clients with connected nodes to communicate with each other [IRC-CLIENT] and to other servers
Connected node [IRC-SERVER]. The server is also responsible for providing basic services defined by the IRC protocol.
2.2 Client
Any machine that is not a server and connected to a server can be called a client. There are two types of clients that use
For different purposes.
2.2.1 user Client
A user client generally provides a text interface-based program for communication through IRC. This feature
Special types of clients are often called "User Machines ".
2.2.2 service client
Unlike User Machines, service clients are not designed to work manually or for conversation. They talk about protocols
You can use more confidential data from the server at will.
A service machine is a typical automatic machine used to provide various services to the User Machine (not related to IRC itself. I
An example is a service that collects statistics from the sources of user machines connected to the IRC network.
3. Structure
A group of interconnected servers define an IRC network. A server forms the simplest IRC network.
For an IRC server, the only allowed network structure is a spanning tree. Each server is visible to it.
The central node of the network.
1 --/
A D---4
2 --///
B----C
//
3 E
Server: A, B, C, D, E client: 1, 2, 3, 4
[Figure 1 small IRC network example]
4. IRC protocol service
This section describes the services provided by the IRC protocol. The combination of these services enables real-time meetings.
4.1 client Positioning
To exchange messages, the two clients must be able to locate each other.
When the server is connected, the client registers a sign, which is subsequently used by other servers and clients to locate the customer.
User Machine. The server is responsible for tracking all the logos used.
4.2 message delay
The IRC Protocol cannot provide direct connection between two clients, and communication between all clients is delayed by the server.
4.3 Channel collection and management
A channel is a naming group composed of one or more clients. All members in this group receive and send messages
The message of this channel. A channel is marked by its name and current members. It also has a series of members that can be identified by it.
Attributes used.
The channel provides a method to send messages to multiple clients. The server collects channels and provides the required multi-channel message technology. Server
The server is also responsible for channel management by tracking channel members. The exact role of the server is in "Internet Relay Chat:
Defined in channel management "[IRC-CHAN.
5. IRC Concept
This section describes the real concepts behind the IRC protocol organization and how messages of different types are transmitted.
5.1 one-to-one communication
One-to-one communication is often implemented by the client, because most of the blocking is performed by the server.
To provide a way for each client to communicate with each other, all servers are required to be able to reach any customer along the build tree.
The server sends messages in one way. Therefore, the message sending path is the shortest path between any two points in the generation tree.
The example below involves figure 1 above.
Example 1: messages between 1 and 2 are only seen by server a at the same time, and server a directly sends messages to server 2.
Example 2: messages between 1 and 3 are viewed by both server a, server B, and client 3. No other client or server
The server allows you to see this message.
Example 3: messages between 2 and 4 are only viewed by the server A, B, C, D, and client 4.
5.2 and more
The objective of IRC is to provide simple and effective conference forums. IRC provides many methods for implementation, each of which
For their respective purposes.
5.2.1 and one channel
In IRC, channels and multicast group roles are the same. They all survive dynamically and the actual conversations must be sent
The server that is supporting the client on a given channel. Also, the message will be sent only once to each local link, because
Each server is responsible for distributing the original message to ensure that it can reach all recipients.
The following examples all involve figure 2.
Example 4: Any channel including client 1. Any message sent to this channel arrives at the server and does not
To any other place.
Example 5: two clients are in one channel. All messages pass through the path to make them look like channels, external
Private messages between two clients.
Example 6: The Client 1, 2, and 3 are in a channel. All messages sent to this node are sent to all clients and
The server that must pass the secret message sent to a single client. If client 1 sends a message, it returns
To client 2 and then to client 3 through server B.
5.2.2 mask a host/Server
In order to provide a mechanism for sending messages to a large number of related clients, you must be able to send the message to the host/Server mask.
. These messages are sent to the host and server that match the mask information. The message is only sent to the client.
Is similar to the channel method.
5.2.3 to a series of goals
The most efficient one-to-many conversation mode is that the client can talk to a series of targets (clients, channels, and masks ).
The implementation of this method is self-evident: the client provides a list of message destinations, and the server splits it
Each destination sends a copy of the message.
This method has no channel efficiency, because the list may be broken and it cannot be guaranteed to go down each path.
Send a copy of each message.
5.3 To all
It is best to describe a pair of all types of messages using broadcast messages, which are sent to all clients or services.
Or both. In a large network that includes clients and servers, a message can cause a large number
Blocking because it will try to be sent to all desired destinations.
For some types of messages, there is no other choice. Only by broadcasting to all servers can each
Consistency between the status information saved by the server.
5.3.1 client-to-client
No message can cause messages from a single client to be sent to all other clients.
5.3.2 client to server
Most commands that cause status changes (such as the number of channel members, channel status, and client status)
It must be sent to all servers by default, and such distribution should not be changed by the client.
5.3.3 server-to-Server
Although most messages between servers are distributed to all other servers, only when messages affect the client,
Channel or server. Because there are some basic entries in IRC, almost all
Messages on the server are broadcast to other connected servers.
6. Current Problem
This agreement has some accepted issues. This part only describes issues related to the Protocol system.
6.1 available range
This protocol is not very well used for a wide range of applications, which has been widely recognized. The main reason is that all servers
All other servers, clients, and channels must be known and their information must be updated in a timely manner.
6.2 Reliability
Because the only allowed network structure of the IRC server is the Spanning Tree, the connection between the two servers is obvious.
And it is easy to disconnect. This problem is more detailed in the "Internet delayed conversation: Server Protocol" [IRC-SERVER]
Detailed description.
6.3 network congestion
Besides the availability range and reliability, the problem caused by tree structure generation also makes IRC easy to export.
Network congestion. This problem is a regional issue that can only be solved by the next generation: If congestion and high traffic cause two problems
Connection failure between servers not only causes network congestion, but also causes reconnection between servers.
Add serious network congestion.
To minimize the impact of this problem, it is best not to automatically try to reconnect to the server too quickly to avoid
Make the situation worse.
6.4 confidentiality
In addition to failing to be well applied to a wide range, and the server must know all information about other entities, the priority issue
It is also a striking problem. Especially for channels,

7. Confidentiality
Except for the confidentiality issues mentioned in Section 6.4, security is not related to this document.
8. Current support and access channels
IRC discussion email list:
General discussion: irce-user@irc.org
Protocol development: ircd-dev@irc.org
Software: ftp://ftp.irc.org/irc/server
Ftp://ftp.funet.fi/pub/unix/irc
Ftp://coombs.anu.edu.au/pub/irc
Newsgroup: Alt. IRC
9. Thanks
This document is partly copied from the first officially released IRC protocol RFC 1459 [IRC]. It also benefited from many comments.
And discussion. In particular, the following have made important contributions to this document:
Matthew green, Michael norayer, Volker Paulsen, Kurt roeckx, VESA
Ruokonen, Magnus tjernstrom, Stefan zehl.
10. References
[Keywords] bradner, S., "key words for use in rfcs to indicate
Requirement Levels ", BCP 14, RFC 2119, March 1997.
[IRC] oikarinen, J. and D. Reed, "Internet Relay Chat
Protocol ", RFC 1459, May 1993.
[IRC-CLIENT] kalt, C., "Internet Relay Chat: client protocol", RFC
2812, 10000l 2000.
[IRC-SERVER] kalt, C., "Internet Relay Chat: Server Protocol", RFC
2813, 10000l 2000.
[IRC-CHAN] kalt, C., "Internet Relay Chat: Channel Management", RFC
2811, 10000l 2000.
11. Author's address
Christophe kalt
99 Teaneck Rd, Apt #117
Ridgefield Park, NJ 07660
USA
Email: kalt@stealth.net
12. Complete copyright notice
Copyright (c) the Internet Society (2000). All rights reserved.
This document and the information contained herein is provided on
"As is" basis and the Internet Society and the Internet Engineering
Task Force disclaims all warranties, express or implied, including
But not limited to any warranty that the use of the information
Herein will not infringe any rights or any implied warranties
Merchantability or fitness for a particle purpose.

Thank you

Funding for the RFC editor function is currently provided by
Internet Society.


Rfc2811 -- Internet Relay Chat: Channel Management
Internet delayed conversation: system and structure