ZeroConf(Zero Configuration Networking)

Zeroconf 란?

Zero Configuration Networking으로 DNS 서버 설정이나 IP를 이용하지 않은 Networking 즉 DHCP 환경이 없는 네트워크에서 Peer to Peer 연결이나 Wireless 환경에서 수동 설정없이 자동으로 네트워킹 할 수 있는 환경을 만들어주는, 일종의 기법이다.

Zeroconf는 다음 3가지의 기술을 기반으로 하고 있다.

• 네트워크 장치로의 네트워크 주소 할당
• 컴퓨터 Hostname의 자동 해석과 자동 배포
• 프린터와 같은 네트워크 장치의 위치를 자동 감지

OS Platform에 따른 Zeroconf Service는 다음과 같다.

1. Apple(Bonjour)
   Apple에서 만든 Zero Configuration Networking 프로토콜로써 IP 네트워크 상에서 컴퓨터, 주변기기 및 서비스를 자동으로 검색하는 서비스로 Bonjour가 있다. Bonjour는 DLNA based Service Discovery(DNS-SD) 프로토콜을 사용한다.
   
   
2. Windows(UPNP)
   Windows에선 upnp가 존재한다. 윈도우7의 윈도우 미디어가 DLNA를 적용하였으며, DLNA는 upnp 프로토콜의 SSDP(Simple Service Discovery Protocol)를 사용한다.
   
   
3. Linux(Avahi) - LGPL(GNU Lesser General Public License) 기반
   Avahi는 bonjour와 같은 DNS-SD이며, 단지 리눅스용으로 만들어졌다. 따라서 Bonjour Service를 이용하여 Avahi를 검색할 수 있다.

mDNS(Multicast DNS)/DNS-SD

Bonjour의 또 다른 구현체인 Avahi는 mDNS/DNS-SD 구현체이다. mDNS를 이용하면 로컬 네트워크에 참여한 호스트를 자동으로 찾을 수 있다. 하지만 어떤 종류의 서비스 인지는 확인할 수 없다. 예를들어 로컬 네트워크에서 프린트 서버를 찾거나 오디오 서버,멀티미디어 기기(TV와 같은) 등을 찾으려고 한다면 호스트 이름만 가지고는 찾는데 어려움이 있다. DNS-SD를 이용하면 서비스 타입(Service Type)을 설정하는 것으로 서비스 검색이 가능하다.

DNS-SD는 DNS의 PTR(Pointer record)를 이용해서 Service Type을 설정한다. 원래 DNS에서 PTR Reverse DNS Lookup을 위해서 사용하는 레코드인데, SD(Service Discovery)를 위해서 필드를 전용하여 사용한다.

형식은 <Service>.<Domain> 이다. 예를들어 googlecast의 경우 _googlecast._tcp. 형태를 가지고 있다.

Architectural Overview

Bonjour나 Avahi의 핵심 목적은 "기기를 쉽게 사용할 수 있게" 하는데 있다.

이를 위한 메커니즘으로 Publishing, Discovering, Using IP-Based Service 를 제공한다. 제공하는 메커니즘은 zero-configuration을 목표로 한다.

• Publication(Advertising a service) : 네트워크에 특정 서비스를 제공하는 노드가 참여하면, 이 노드는 자동으로 자신의 서비스를 네트워크에 참여하는 모든 노드에 광고를 한다. 예를 들어 오디오 Playback 서비스를 제공하는 스피커가 네트워크에 참여하는 경우, 이 스피커는 연결된 네트워크 상의 모든 PC 또는 모바일 기기에 오디오 플레이 서비스가 준비되었음을 알린다.
• Discovery : 주변에 사용할 수 있는 서비스가 있는지 확인한다.
• Resolution : 서비스를 제공하는 노드의 이름과 IP 주소, 포트 번호를 확인할 수 있다.

mDSN/DNS-SD Architecture

• mDNS Resolver : 애플리케이션의 요청을 받아서 DNS resolve를 한다. 즉 호스트나 서비스를 찾아서 그 정보를 애플리케이션에 돌려주는 일을 한다.
• mDNS Responder : DNS resolve 요청이 왔을 때, 응답을 한다.
• mDNS DB : 노드의 IP, 호스트 이름, 서비스 타입, 포트 정보 등을 저장한다. 또한 resolve된 다른 노드들의 정보들을 저장한다.

Publication

노드가 서비스를 퍼블리쉬(Publish)하기 위해서는 멀티캐스트 채널에 join한 노드들의 mDNS DB에 등록이 돼야 한다. mDNS는 DNS를 그대로 사용한다. 이는 등록정보들을 DNS Record로 관리한다는 이야기다. 사용하는 레코드들은 서비스(SRV) 레코드, pointer(PTR)레코드, 그리고 text(TXT)레코드이다.

• Service Records

SRV 레코드는 서비스를 사용하는 클라이언트에게 상세한 서비스 정보를 알려주기 위해서 사용한다. 인스턴스 이름, 서비스 타입, 포트 번호 등의 정보를 클라이언트에게 알려준다. SRV 레코드의 중요한 특징은 "서비스 이름"을 키로 사용할 수 있는데 있다. 예를들어 IP주소나 호스트 이름이 변경되더라도 서비스 이름은 그대로 남기 때문에, 서비스 이름을 이용하여 노드를 찾을 수 있다.

SRV에 저장되는 정보의 형식은 다음과 같다. 각 필드는 공백문자로 구분할 수 있다.

PrintsAlot._printer._tcp.local. 120 IN SRV 0 0 515 blackhawk.local.

첫번째 필드에는 서비스 이름이 저장된다. <Instance Name>.<Service Type>.<Domain> 형식으로 저장된다. 위의 정보를 이용하여, 로컬 네트워크에서 프린트 서비스를 제공하는 노드이며, 서비스의 이용 포트번호는 515 임을 알 수 있다. 120은 time-to-live로 캐쉬 기간 설정에 사용한다. 두 개의 0은 weight와 priority이다. mDNS에서는 사용하지 않는다.

• Pointer Records

PTR 레코드는 Discovery를 위해서 사용한다. 서비스 타입을 이용하여 서비스를 제공하는 노드를 찾을 수 있다. 서비스 타입이기 때문에, 동일한 타입의 여러 기기들을 찾을 수 있다. 집안에 오디오 서비스가 가능한 스피커와 TV 두개의 노드가 있다면 함께 검색된다.

• Text Records

서비스 노드에 대한 추가적인 정보를 제공한다. 로컬 네트워크를 기반으로 하는 멀티 플레이어 게임에서 맵의 이름을 공유하기 위해서 혹은 채팅 프로그램에서 유저의 상태를 알리기 위한 용도 등으로 사용할 수 있다.

Discovery(탐색)

서비스 Discovery는 PTR 레코드에 대하서 검색하는 걸로 시작한다. 주변에 이미지를 출력할 수 있는 기기를 찾기를 원한다면 _image._tcp와 같이 서비스 이름으로 검색하면 된다. 검색을 시작하면 멀티캐스트 채널로 DNS 요청을 보내고, 각 노드는 자신의 서비스 타입을 반환한다.

Resolution(해결)

서비스를 한번 찾은 후에는 서비스 노드가 네트워크를 이탈하기 전까지는 언제든지 사용할 수 있어야 한다. 예를들어 네트워크 오디오를 찾았다면, 오디오의 IP가 변경되거나 호스트명이 변경되더라도 같은 멀티캐스트 채널에 붙어있다면, 오디오의 서비스를 이용할 수 있어야 한다. IP 또는 호스트명이 변경된 상황이 발생할지라도 서비스를 다시 찾는 일은 없어야 할 것이다.

이를 위해서는 서비스를 resolution 하기 위한 키(Key)가 필요하다. 확실한 건 IP나 호스트 네임이 키가 될 수 없다는 것이다. 대신 서비스 이름을 키로 사용한다. 멀티캐스트 채널에 join한 노드의 IP와 호스트 정보를 획득했다면, 서비스 이름을 요청할 수 있다. 이 서비스 이름은 변하지 않기 때문에, IP 정보등이 변경되더라도 서비스 이름을 이용해서 노드를 찾을 수 있다.