1.2 Clients
📌 서버에 연결하고자 하는 다른 서버가 아닌 것
📌 닉네임을 통해 각 클라이언트를 구분(최대 9글자)
→ 기본 문법 규칙에서 사용가능한 문자 확인하기
📌 클라이언트가 실행 중인 호스트의 실제 이름, 그 호스트에서 실행 중인 클라이언트의 사용자 이름, 클라이언트가 연결된 서버에 대한 정보도 포함해야 함
1.3. Channels
📌 채널은 하나 이상의 클라이언트로 구성된 명명된 그룹으로, 해당 채절에서 전달되는 모든 메시지를 수신한다.
📌 첫 번째 클라이언트가 참여하는 경우 명시적으로 생성되며, 마지막 클라이언트가 나가는 경우 끝난다.
📌 채널이 존재하는 경우 모든 클라이언트는 채널 이름으로 채널을 참조 가능하다.
📌 채널 이름은 '&' 혹은 '#'로 시작하는 최대 길이 200의 문자열
→ 공백(' '), Ctrl+G(^G: ASCII 7번), 쉼표(',') 포함 불가
- 두 가지의 채널 종류를 지원
1. 네트워크에 연결된 모든 서버가 알고있는 광역 채널
: 채널 이름이 '&'로 시작
2. 두 가지 말고도 다른 개별적인 채널 특성을 설정할 수 있는 다양한 채널 모드 존재(MODE 명령어 참고)
📌 새로운 채널을 생성하거나 기존 채널에 참여하고 싶은 경우 사용자는 채널에 JOIN해야 한다.
→ 채널이 존재하지 않는 경우 채널이 생성되고 채널에 JOIN하는 첫 사용자가 채널 운영자가 된다.
→ 존재하는 경우 사용자의 JOIN 요청은 그 채널의 MODE에 따라 결정된다
→ e.g. 채널이 INVITE-only인 경우 초대되었을 경우에만 채널 참여 가능
📌 사용자는 여러 채널에 한 번에 참여 가능하지만, 최대 10개의 채널까지만 참여하는 것이 권장된다.
→ 로컬 사용자는 최대 10개, 로컬이 아닌 사용자는 제한 없음. 서버는 채널 멤버십 기준으로 다른 모든 사용자와의 일관성을 유지할 수 있다.
📌 IRC 네트워크가 두 서버의 분할로 분리되는 경우, 각각의 서버는 그 서버에 연결되어 있는 클라이언트로만 구성되며, 다른 서버에서는 존재하지 않을 수도 있다.
📌 분할이 치유(분할되었다 합쳐지면?) 연결된 서버는 각 채널에 존재한다고 생각되는 사용자와 해당 채널의 MODE를 서로에게 알린다.
📌 채널이 양쪽에 모두 존재하는 경우 JOIN 및 MODE는 포괄적인 방식으로 해석되므로 양 쪽의 새로운 연결은 모두 채널에 어떤 클라이언트가 있는지, 채널에 어떤 MODE가 있는지 동의하게 됨
1.3.1 Channel Operations
- KICK
- MODE
- INVITE
- TOPIC
📌 채널 운영자는 채녈과 연결될 때마다 닉네임 옆의 '@' 기호로 식별됨.
2. The IRC Specification
2.2. Character codes
📌 특정 character set이 지정되지 않음.
→ 8bit로 구성된 코드 기반
→ 몇 개의 octat value는 message delimiters와 같은 제어 코드로 사용됨
📌 8bit 프로토콜을 따름에도 불구하고, 구분자와 키보드는 대부분 USASCII 터미널가 텔넷 연결에서 사용될 수 있도록 되어있음.
📌 {}|는 []\의 소문자로 간주된다. 어째서
2.3 Messages
📌 서버와 클라이언트는 답장이 올 수도 오지 않을 수도 있는 메시지를 서로에게 보낸다.
→ 메시지가 유효한 명령을 포함하는 경우, 클라이언트는 특정 응답을 기대하게 되지만 응답을 영원히 기다리는 것은 권장되지 않음
📌 통신은 비동기
📌 각각의 IRC 메시지는 세 개의 주요 부분으로 구성됨
→ prefix(선택), command, command parameters(최대 15개)
→ 각각의 부분들은 ASCII 스페이스 문자(' ')로 구분됨
📌 prefix는 ':'에 뒤따른다. ':'가 메시지의 가장 첫 번째에 위치해야 하며, ':'과 prefix 사이에 공백은 없어야 한다.
📌 prefix는 메시지가 어디에서 발신된 것인지 구분하기 위해 서버에 의해 사용된다.
📌 메시지에 prefix가 없다면 그 메시지가 수신된 곳에서 발신된 것으로 간주한다.
→ 클라이언트는 그들 사이에서 메시지를 발신할 때 prefix를 사용하지 않아야 함
→ 클라이언트와 연결된 등록된 닉네임만이 유일하게 유효하다.
📌 서버 내부 데이터베이스에서 prefix를 찾을 수 없거나 메시지가 도착한 곳과는 다른 곳의 prefix라면 메시지를 조용히 무시한다.
📌 command는 유효한 IRC command이거나 ASCII 문자로 표시 가능한 3자리 숫자여야 한다.
📌 IRC 메시지는 항상 CR-LF로 끝나는 문자열이어야 한다. 그리고 이 메시지는 길이가 512자를 넘어가서는 안되며, 이는 CR-LF를 포함한 길이이다. 따라서 command와 그 parameter는 최대 510자여야 한다.
📌 연속된 메시지 줄에 대한 규정은 없음.
📌 자세한 건 Section 7
2.3.1 Message format in 'pseudo' BNF
📌 프로토콜 메시지는 연속된 옥텟 스트림에서 추출해야 함.
→ 해결책: CR-LF 두 문자를 메시지 구분자로 지정
→ 빈 메시지는 자동으로 무시되므로 메시지 사이에서 CR-LF를 다른 문제 없이 사용 가능
📌 추출된 메시지는 <prefix>, <command>와 <middle>이나 <trailing>의 구성요소와 일치하는 매개변수로 파싱됨.
<message> ::= [':' <prefix> <SPACE> ] <command> <params> <crlf>
<prefix> ::= <servername> | <nick> [ '!' <user> ] [ '@' <host> ]
<command> ::= <letter> { <letter> } | <number> <number> <number>
<SPACE> ::= ' ' { ' ' }
<params> ::= <SPACE> [ ':' <trailing> | <middle> <params> ]
<middle> ::= <Any *non-empty* sequence of octets not including SPACE
or NUL or CR or LF, the first of which may not be ':'>
<trailing> ::= <Any, possibly *empty*, sequence of octets not including
NUL or CR or LF>
<crlf> ::= CR LF- 주의
1.<SPACE>는 오직 ' '로만 구성. TABULATION과 다른 모든 제어문자는 NON-WHITE-SPACE로 간주
2. parameter list를 추출한 후, 모든 parameter는<middle>과 일치하든<trailing>과 일치하든 모드 동등하다.<trailing>은 매개변수 내에서 공백을 허용하기 위한 구문론적 트릭일 뿐
3. CR-LF가 parameter 문자열에 표시되지 않는 것은 메시지를 구성할 때의 인공적 조치일 뿐. 나중에 바뀔 수도 있다고 함
4.NULL문자는 메시지 구성에서 특별한 문자는 아니며, parameter에 포함될 수 있다. 그러나 일반적인 C 문자열로써 다룰 때 복잡성을 증가시킬 수 있으므로 메시지 내에서는 허용되지 않는다.
5. 마지막 parameter는 빈 문자열일 수 있다
6. extended prefix(['!' <user>]['@' <host>]는 클라이언트에게 추가 쿼리 없이도 메시지의 발신자에 대한 더 유용한 정보를 제공하기 위해 server to client 통신에서만 사용된다.
2.4 Numeric replies
📌 서버로 보내지는 대부분의 메시지는 어떤 종류의 응답을 생성한다.
→ 가장 일반적인 응답은 숫자 응답이며, 오류와 정상 응답 모두에 사용된다.
→ 숫자 응답은 맨 처음에 발신자, 이어서 3자리 숫자와 응답 대상으로 구성된 하나의 메시지로 전송되어야 한다.
📌 숫자 응답은 클라이언트에서 발생시킬 수 없다.
→ 서버에서 수신하는 경우 무시됨.
📌 숫자 응답은 일반적인 메시지와 동일하지만, 카워드는 문자열이 아닌 3자리 숫자라는 점이 다르다.
📌 section 6 참고
3. IRC Concepts
📌 IRC 프로토콜의 구성을 뒷받침하는 실재 개념과 어떻게 현재의 구현이 다양한 클래스의 메시지를 전달하는지에 관한 설명
1--\
A D---4
2--/ \ /
B----C
/ \
3 E
Servers: A, B, C, D, E
Clients: 1, 2, 3, 4
[ Fig. 2. Sample small IRC network ]
3.1 One-to-one communication
📌 일대일 기반 통신은 일반적으로 클라이언트에서만 수행된다. 대부분의 서버 간 트래픽은 서버 간에서 대화한 것의 결과가 아니기 때문이다.
📌 클라이언트가 서로 안전하게 대화할 수 있는 방법을 제공하기 위해 모든 서버들은 클라이언트에 도달하기 위해 스패닝 트리를 따라서 정확히 한 방향으로 메시지를 보낼 수 있어야 한다.
→ 메시지가 전달되는 경로는 스패닝 트리 상의 어떤 두 지점 사이 가장 짧은 경로이다.
📌 다음은 그림 2를 참고하는 예시
1. 클라이언트 1이 2에게 보내는 메시지는 오직 A 서버에만 전달되고 A는 이를 바로 2에게 보낸다.
2. 클라이언트 1이 3에게 보내는 메시지는 서버 A와 B에게 전달되어 클라이언트 3에게 보내진다. 다른 클라이언트나 서버는 메시지를 볼 수 없다.
3. 클라이언트 2가 4에게 보내는 메시지는 서버 A, B, C, D를 거쳐 클라이언트 4에게 전달된다. 나머지 클라이언트, 서버는 이 메시지를 볼 수 없다.
3.2 One-to-many
📌 IRC의 주요 목표는 쉽고 효율적인 일대다 대화를 가능하게 하는 장소를 제공하는 것이다.
📌 IRC는 이를 달성하기 위한 여러 가지 방법을 제공하며, 각 방법은 고유한 목적을 가진다.
3.2.1 To a list
📌 일대다 대화의 가장 효율적이지 못 한 방법은 클라이언트가 사용자 목록과 대화하는 것이다.
📌 클라이언트는 메시지가 전달되어야 할 목적지 리스트를 제공하고 서버는 메시지를 분할해 각 대상에게 별도의 메시지 사본을 전달한다.
📌 이는 그룹을 사용하는 것만큼 효율적이지 않다. 목적지 리스트가 분할되고, 중복된 내용이 각 경로로 전송되지 않는지 확인하지 않고 발송되기 때문이다.
3.2.2 To a group (channel)
📌 IRC 채널은 멀티캐스트 그룹과 같은 역할을 한다.
→ 동적이고(사람들이 채널에 참여하고 떠남) 채널에서 발생하는 실제 대화는 해당 채널의 사용자를 지원하는 서버로만 보내진다.
📌 같은 채널 내의 서버에 여러 사용자가 있는 경우, 메시지는 해당 서버에 한 번만 전달되어 채널의 각 사용자에게 보내진다.
→ 이 작업은 원래의 메시지가 확산되어 해당 채널의 구성원에게 모두 도달할 때까지 각각의 클라이언트-서버 조합마다 반복된다.
📌 다음은 그림 2를 참고하는 예시
4. 한 명의 클라이언트만 포함된 채널의 경우, 체널로의 메시지는 서버에 전달되며 그 외의 어떤 곳으로도 전달되지 않는다.
5. 두 명의 클라이언트가 있는 채널의 경우, 모든 메시지는 두 클라이언트 간 개인 메시지처럼 경로를 이동한다.
6. 클라이언트 1, 2, 3이 있는 채널의 경우, 채널에 전달되는 모든 메시지는 모든 클라이언트에게 전달된다. 그리고 메시지가 하나의 클라이언트에 대한 개인 메시지인 경우에 거쳐야 하는 서버에만 전달된다.
→ 만약 클라이언트 1이 메시지를 보낸다면, 이는 클라이언트 2에게 돌아간 후 서버 B를 통해 클라이언트 3으로 이동한다.
