Internet Relay Chat(IRC) Guide(3): Example IRC Communications

11 min readMar 5, 2022

※ 이전 포스트에 이어 작성되었습니다.

Example IRC Communications - The UChicago χ-Projects

In this section, we will describe three example IRC communications. Before diving into the IRC RFCs, we suggest you…

chi.cs.uchicago.edu

In this section, we will describe three example IRC communications. Before diving into the IRC RFCs, we suggest you read through these examples to get a better sense for what a typical conversation between an IRC client and server looks like. These examples will also serve to clarify the format of messages, prefixes, and replies.

이 섹션에서, 우리는 세 가지 예시의 IRC 통신을 보여줄 것입니다. IRC RFC를 살펴보기 전에, IRC 클라이언트와 서버 사이의 일반적인 대화가 어떤지 더 잘 알기 위해 이 예시들을 읽는 것을 권장합니다. 또한, 이 예시들은 메시지, 접두사, 그리고 응답의 형식을 명확하게 제공할 것입니다.

Logging into an IRC server

When an IRC client connects to an IRC server, it must first register its connection. This is done by sending two messages: NICK and USER (messages 1 and 2 in the figure above). NICK specifies the user’s nick (amy in this case), and USER provides additional information about the user. More specifically, USER specifies the user’s username (amy) and the user’s full name (Amy Pond) (we will not be implementing the second and third parameters of USER). The username is typically obtained automatically by the IRC client based on the user’s identity. For example, if you’re logged into a UNIX machine as user jrandom, then most IRC clients will, by default, use that as your username. However, there is no requirement that your nick must match your username.

IRC 클라이언트가 IRC 서버로 연결할 때, 먼저 연결을 등록해야 합니다. 두 개의 메시지(NICK과 USER(상단 그림의 메시지 1과 2))를 전송하면 됩니다. NICK은 사용자의 닉네임(이 경우에는 amy)을 지정하고, USER는 사용자의 부가적인 정보를 제공합니다. 보다 구체적으로, USER는 사용자 명(amy)과 사용자 전체 이름(Amy Pond)을 지정합니다(USER의 두 번째와 세 번째 매개 변수는 구현하지 않을 것입니다.). 사용자 명은 일반적으로 사용자의 ID에 기반을 둬 IRC 클라이언트가 자동으로 포함됩니다. 예를 들어, 만약 사용자 jrandom으로 UNIX 머신에 로그인한다면, 대부분의 IRC 클라이언트는, 기본적으로, 그 사용자 명을 사용할 것입니다. 그러나 닉네임은 반드시 사용자 명과 일치할 필요는 없습니다.

Assuming you’ve chosen a nick that is not already taken, the IRC server will send back a RPL_WELCOME reply (which is assigned code 001). This reply has the following components:

아직 사용되지 않은 닉네임을 선택했다고 가정했을 때, IRC 서버는 (코드 001로 할당된) RPL_WELCOME 응답을 돌려보낼 것입니다. 이 응답은 다음 요소를 가집니다:

:bar.example.com: The prefix. Remember that prefixes are used to indicate the origin of a message. Since this reply originates in server bar.example.com, the prefix simply includes that hostname. This may seem redundant, given that the client presumably already knows it is connected to that server; however, in IRC networks, a reply could originate in a server other than the one the client is connected to.

:bar.example.com : 접두사. 접두사는 메시지의 출처를 나타내는데 사용된다는 것을 기억하세요. 이 응답은 bar.example.com 서버에서 발송되기 때문에, 접두사는 단순히 해당 호스트 명을 포함합니다. 클라이언트는 이미 해당 서버에 연결되어 있음을 알고 있을 것이기 때문에, 불필요해 보일 수 있습니다; 하지만, IRC 네트워크에서, 응답은 클라이언트가 연결된 서버가 아닌 다른 서버에서 올 수 있습니다.

001: The numeric code for RPL_WELCOME.

001: RPL_WELCOME의 숫자 코드.

amy: The first parameter which, in reply messages, must always be the nick of the user this reply is intended for.

amy: 응답 메시지에서 첫 번째 매개변수는 항상 이 응답을 받을 사용자의 닉네임이어야만 합니다.

:Welcome to the Internet Relay Network borja!borja@polaris.cs.uchicago.edu: The second parameter. The content of this parameter is specified in [RFC2812 §5]:

001    RPL_WELCOME
       "Welcome to the Internet Relay Network
        <nick>!<user>@<host>"

:Welcome to the Internet Relay Network borja!borja@polaris.cs.uchicago.edu : 두 번째 매개변수. 이 매개변수의 내용은 [RFC2812 5]에 나와 있습니다.

Notice how the specification of replies omits the first parameter, which is always the recipient of the reply. So, the specification lists the second and subsequent (if any) parameters.

응답의 사양이 첫번째 매개변수(항상 응답을 받는 사람)를 어떻게 생략하는지 주목해봅시다. 사양은 두번째와 그다음 매개변수(존재한다면) 목록을 만듭니다.

One of the things sent back in the RPL_WELCOME reply is the full client identifier (<nick>!<user>@<host>), which is also used in other types of messages. It is composed of the nick as specified in the NICK command, the username as specified in the USER, and the client’s hostname (if the server cannot resolve the client’s hostname, the IP address is used).

RPL_WELCOME 응답에서 되돌아오는 것 중 하나는 (메시지의 다른 타입으로도 사용되는) 전체 클라이언트 ID(<nick>!<user>@<host>)입니다. NICK 명령어로 지정된 닉네임, USER로 지정된 사용자명, 그리고 클라이언트의 호스트 명(만약 서버가 클라이언트의 호스트 명을 지원하지 않는 경우 IP 주소가 사용된)으로 구성됩니다.

The following figure shows a variant of the communication described above:

다음 그림은 상단에 설명된 통신을 예시로 보여줍니다:

If a user tries to register with a nick that is already taken, the server will send back a ERR_NICKNAMEINUSE reply (code 433). Notice how the parameters in this reply are slightly different:

만약 사용자가 이미 사용된 닉네임을 등록하려고 한다면, 서버는 ERR_NICKNAMEINUSE(코드 433) 응답을 돌려 보낼 것입니다. 이 응답에서 매개변수가 어떻게 다른지 주목해봅시다.

*: The first parameter should be the nick of the user this reply is intended for. However, since the user does not yet have a nick, the asterisk character is used instead.

*: 첫 번째 매개변수는 이 응답을 의도한 사용자의 닉네임이여야 합니다. 그러나 사용자가 아직 닉네임을 가지고 있지 않기 때문에, 별 문자(*)를 대신 사용합니다.

amy: In the ERR_NICKNAMEINUSE reply, the second parameter is the “offending nick” (i.e., the nick that could not be chosen, because it is already taken).

amy: ERR_NICKNAMEINUSE 응답에서, 두 번째 매개변수는 “문제가 있는 닉네임”(이미 사용 중이어서 선택되지 않은 닉네임) 입니다.

:Nickname is already in use: The third parameter simply includes a human readable description of the error. IRC clients will typically print these out verbatim.

:Nickname is already in use : 세 번째 매개변수는 사람이 읽을 수 있도록 오류 내용을 간단하게 포함하고 있습니다. IRC 클라이언트는 일반적으로 이러한 내용을 그대로 출력할 것입니다.

So, notice how there is no uniform set of parameters sent back in all replies (other than the first parameter, which is always the recipient nick). When implementing a reply, you must consult [RFC2812 §5] to determine exactly what you should be sending back in the reply.

모든 응답에는 매개변수의 균일한 형식이 없는 것을 주목하세요(첫 번째 매개변수는 항상 응답을 받는 닉네임이라는 것을 제외하고). 응답을 구현할 때, 여러분은 응답에 무엇을 보낼지 확실하게 정하기 위해 [RFC2812 5]를 참고하세요.

Messaging between users

Once several users are connected, it is possible for them to send messages to each other, even in the absence of channels. In fact, most of the second assignment focuses on implementing messaging between users, whereas the third assignment will focus on adding support for channels.

일단 여러 사용자가 연결되면, 채널이 없어도 서로에게 메시지를 보낼 수 있습니다. 사실, 두 번째 과제 대부분은 사용자들 사이의 메시징 구현에 초점이 맞춰 있고, 세 번째 과제는 채널의 추가 지원에 중점 되어 있습니다.

To send a message to a specific nick, a user must send a PRIVMSG to the server. The figure above shows two users, with nicks amy and rory, exchanging three messages. In message 1, user amy sends a message to rory. The parameters for PRIVMSG are very simple: the first parameter is the nick of the user the message is intended for, and the second parameter is the message itself.

특정한 닉네임에 메시지를 보내기 위해, 사용자는 반드시 서버에 PRIVMSG를 전송해야 합니다. 위 그림은 닉네임이 amy와 rory인 두 사용자가 세 개의 메시지를 주고받는 것을 보여줍니다. 메시지 1에서, 사용자 amy는 rory에게 메시지를 보냅니다. PRIVMSG의 매개 변수는 굉장히 간단합니다: 첫 번째 매개변수는 메시지를 받을 사용자의 이름이고, 두 번째 매개변수는 메시지 내용입니다.

When the server receives that message, and assuming there is a rory user, it will forward the message to the IRC client that is registered with that nick. This is done in message 2, and notice how it is simply a verbatim copy of message 1, but prefixed with amy’s full client identifier (otherwise, the recipient IRC client would have no idea who the message was from). Messages 3 and 4 show a similar exchange, except going from rory to amy, and messages 5 and 6 show another message going from amy to rory.

서버가 메시지를 받으면, 사용자 rory가 있다는 가정하에, 그 닉네임이 등록된 IRC 클라이언트로 메시지를 전달할 것입니다. 이것은 메시지 2에서 수행되었습니다, 앞에 amy의 전체 클라이언트 ID가 붙은 메시지 1이 그대로 보내졌습니다(그렇지 않으면, 받는 IRC 클라이언트는 메시지를 누가 보냈는지 알 수 없습니다). 메시지 3과 4는 rory에서 amy로 가는 것을 제외하고 비슷하게 교환되고 있음을 보여줍니다, 메시지 5와 6은 amy에서 rory로 가는 또 다른 메시지를 보여줍니다.

Notice how all messages are relayed through the IRC server (hence the name of the protocol: Internet Relay Chat). Non-relayed messaging is not supported in the IRC specification, and we will not be implementing such a functionality in this project. However, there are two extensions to IRC (CTCP, the Client-to-Client Protocol, and DCC, Direct Client-to-Client) that are the de facto standard for non-relayed chat on IRC. Most IRC servers and clients support these extensions, even though they have never been formally specified as an RFC (the closest thing to a specification is this document: http://www.irchelp.org/irchelp/rfc/ctcpspec.html).

모든 메시지가 IRC 서버를 통해 어떻게 전달되는지 주목해봅시다(따라서 프로토콜의 이름: 인터넷 릴레이 채팅). Non-relayed messaging은 IRC 사양에서 지원하지 않고, 이 프로젝트에서 이러한 기능을 구현하지 않을 것입니다. 그러나 IRC에서 Non-relayed messaging을 위한 사실상의 표준인 IRC의 두 가지 확장자(CTCP, 클라이언트-클라이언트 프로토콜,과 DDC, 다이렉트 클라이언트-클라이언트)이 있습니다. 대부분의 IRC 서버와 클라이언트는 RFC에 공식으로 지정된 적은 없지만, 그 확장자를 지원합니다.(사양이 궁금하다면 이 문서를 읽어보세요: http://www.irchelp.org/irchelp/rfc/ctcpspec.html)

Joining, talking in, and leaving a channel

Users connected to an IRC server can join existing channels by using the JOIN message. The format of the message itself is pretty simple (its only parameter is the name of the channel the user wants to join), but it results in several replies being sent not just to the user joining the channel, but also to all the users currently in the channel. The figure above shows what happens when user amy joins channel #tardis, where two users (doctor and river) are already present.

IRC 서버에 연결된 사용자는 JOIN 메시지를 사용해 기존 채널에 들어갈 수 있습니다. 그 메시지 자체의 형식은 굉장히 간단하지만(매개변수는 사용자가 들어가기 원하는 채널명입니다.), 채널에 들어간 사용자뿐만 아니라 현재 채널에 있는 모든 사용자에게도 여러 개의 응답이 가는 결과가 생깁니다. 위 그림은 amy가 두 사용자(doctor와 river)가 이미 존재하는 #tardis 채널에 들어갈 때 무슨 일이 일어나는지 보여줍니다.

Message 1 is amy’s JOIN message to the server. When this message is received, the server relays it to the users who are already in the channel (doctor and river) to make them aware that there is a new user in the channel (messages 2a and 2b). Notice how the relayed JOIN is prefixed with amy’s full client identifier. The JOIN is also relayed back to amy, as confirmation that she successfully joined the channel.

메시지 1은 서버로 가는 amy의 JOIN 메시지입니다. 이 메시지를 받을 때, 서버는 채널에 이미 존재하는 사용자(doctor와 river)에게 채널에 새 사용자가 있다는 것을 알려주기 위해 메시지를 보내줍니다(메시지 2a와 2b). 전달된 JOIN 앞에 amy의 전체 클라이언트 ID가 어떻게 붙는지 주목하세요. 그녀가 성공적으로 채널에 들어갔다는 것에 관한 확인으로 JOIN은 amy에게 다시 전달됩니다.

The following messages (3, 4a, and 4b) provide amy with information about the channel. Message 3 is a RPL_TOPIC reply, providing the channel’s topic (this is a description of the channel which can be set by certain users; we’ll discuss this in detail later). Messages 4a and 4b are RPL_NAMREPLY and RPL_ENDOFNAMES replies, respectively, which tell amy what users are currently present in the channel. Notice how the doctor user has an at-sign before his nick; this indicates that doctor is a channel operator for channel #tardis. As we’ll see in the third assignment, users can have modes that give them special privileges in the server or on individual channels. For example, a channel operator is typically the only type of user that can change the channel’s topic.

다음 메시지들(3, 4a 그리고 4b) 은 amy에게 채널에 대한 정보를 제공합니다. 메시지 3은 RPL_TOPIC 응답으로, 채널의 주제를 제공합니다.(특정 사용자에 의해 정해질 수 있는 채널 설명입니다; 자세한 내용은 후에 논의해봅시다.) 메시지 4a와 4b는 각각 RPL_NAMREPLY와 RPL_ENDOFNAMES 응답으로, 사용자가 현재 채널에 존재하는지 amy에게 알려줍니다. 사용자 doctor 닉네임 앞에 @가 있는 것을 주목하세요; 이것은 doctor가 #tardis 채널의 관리자임을 알려줍니다. 세 번째 과제에서 보겠지만, 사용자는 서버나 개인 채널에서 특정한 권한을 받을 수 있는 모드를 가질 수 있습니다. 예를 들어, 채널 관리자는 일반적으로 채널의 주제를 바꿀 수 있는 유일한 사용자 유형입니다.

Once a user has joined a channel, sending a message to the channel is essentially the same as sending a message to an individual user. The difference is that the server will relay the message to all the users in the channel, instead of just a single user. The figure above shows two messages being sent to channel #tardis. First, user doctor sends a PRIVMSG message, specifying the channel as the target (and not a nick, as we saw in “Messaging between users”). The server then relays this message to river and amy, prefixing the message with doctor’s full client identifier (messages 1, 2a, and 2b). Similarly, amy sends a message to the channel, which is relayed to doctor and river, prefixed with amy’s full client identifier (messages 3, 4a, and 4b)

사용자가 채널에 들어가면, 채널에 메시지를 보내는 것은 개인 사용자에게 메시지를 보내는 것과 본질적으로 같습니다. 차이점은 서버가 개인 사용자 대신에 채널의 모든 사용자에게 메시지를 전달합니다. 위 그림은 채널 #tardis 에 보내진 두 개의 메시지를 보여줍니다. 먼저, 사용자 doctor는 대상을 채널로 지정해 PRIVMSG 메시지를 보냅니다.(“사용자들 간 메시지 전송”을 보는 것처럼 닉네임이 아닌) 그러면 서버는 앞에 doctor의 전체 클라이언트 ID가 붙은 메시지(메시지 1, 2a, 그리고 2b)를 river와 amy에게 전달합니다. 유사하게, amy가 채널에 doctor와 river에게 전달되는 앞에 amy의 전체 클라이언트 ID가 붙은 메시지(메시지 3, 4a 그리고 4b)를 보냅니다.

Leaving a channel is accomplished with the PART message, which follows a similar pattern to joining and talking in the channel: the user wishing to leave sends a PART message, and this message is relayed to everyone in the channel so they are aware that the user has left. The server also internally removes that client from the channel, which means he will no longer receive any messages directed to that channel. The figure above shows an example of what this would look like. Notice how the PART message includes two parameters: the channel the users wants to leave, and a “parting message” (which is relayed as part of the PART message to all users in the channel).

채널 나가기는 채널에 들어가고 채널에서 말하는 것과 비슷한 패턴을 따르는 PART 메시지로 형성되어 있습니다: 나가기 원하는 사용자는 PART 메시지를 보내고, 이 메시지는 채널에 있는 모든 사람에게 전송되어 그 사용자가 나간 것을 알고 있습니다. 또한, 서버는 (나간 사용자가) 해당 채널에서 오는 어떠한 메시지도 받을 수 없도록 채널에서 해당 클라이언트를 내부적으로 삭제합니다. 위 그림은 어떻게 보일지 예시를 나타냅니다. 사용자가 나가기를 원하는 채널과 (채널의 모든 사용자에게 PART 메시지의 일부가 전송되는)”parting message”, 두 가지 매개변수를 포함한 PART 메시지를 주목해주세요.

[reference]