여기에도 관련 내용을 요약해서 함께 올려 두고자 한다.

—

위치자/식별자 분리 프로토콜(LISP; Locator/Identifier Separation Protocol)은 “map-and-encapsulate” 프로토콜로, 현재 Internet Engineering Task Force 의 LISP Working Group 에서 개발되고 있다. ^[1] “분리”뒤에 숨어 있는 기본적인 개념은 인터넷 아키텍처가 한 개의 IP 주소 공간에 두 개의 기능 – Routing Locator(당신이 네트워크에 붙어 있는 장소)와 식별자(당신이 누구인지) – 을 결합하고 있다는 것이다. LISP 는 네트워크 기반의 “map-and-encapsulation(RFC-1955)” 를 따르는 IPv4 와 IPv6 의 분리를 지원한다. LISP 에서는 식별자와 위치 정보가 IP 주소가 될 수도 있고 GPS 좌표라든지 MAC Address 와 같은 임의의 요소일 수도 있다.

이러한 프로토콜에는 아래와 같은 장점이 있다.

• 라우팅 확장성의 개선
• Active-Active 구성에서 BGP 없이 복수 구성 가능(BGP-free multihoming)
• 주소체계의 전환: IPv4 상에서 IPv4, IPv4 상에서 IPv6, IPv6 상에서 IPv6, IPv6 상에서 IPv4
• 인입트래픽 가공(Inbound Traffic Engineering)
• 모빌리티 확보
• 구성 단순화
• 호스트(서버 등과 같은)의 변경이 필요 없음

https://blogs.apache.org/foundation/entry/the_apache_software_foundation_celebrates

클라우드 환경에 적합하도록 많은 기능 향상이 있다고 하는데, 일견 약간 겸손한 표현이 아닌가 한다. 오픈 소스 웹 서버 커뮤니티의 리더로써, 아파치의 향상된 기능이 클라우드 환경을 더 좋게 만들 수 있다고 생각하기 때문이다.

2.3 개발버전대에서 제공하던 기능들이 프로덕션 수준으로 올라온 모습이 눈에 띄는데, release news 에서 기술하고 있는 주요한 기능 향상에는 다음과 같은 것들이 있다.

• 성능 향상 (적은 컴퓨팅 자원을 사용하며 동시에 동시성을 개선함)
• 메모리 사용량 감소
• 비동기 I/O 기능 지원
• 동적 컨텐츠에 대한 리버스 프록시 기능 제공
• 이벤트 기반 웹 서버들보다 더 강력한 성능 제공
• 정교한 타임아웃(ms 단위로 타임아웃 제어) 파라미터 및 limit 구성 가능
• 높은 트래픽을 처리할 수 있는 서버 및 프록시 기능을 위한 정교한 구성 가능

클라우드 환경에 적합하다는 말처럼 대용량 트래픽과 반응속도 부문에서의 향상이 돋보인다.

아무튼 오픈 소스 소프트웨어의 리더로써 다시 한 걸음 도약한 것에 대해 다시한번 축하를.

문서 기반 멀티 윈도우 어플리케이션의 객체 구성

코코아의 Document 기반 어플리케이션에는 크게 새 종류의 클래스들이 구축된다.

• NSDocument
• NSWindowController
• NSDocumentController

NSDocument 는 말 그대로 어플리케이션의 주요 데이터를 담고 있어야 하기 때문에 모든 문서 기반 어플리케이션에서 필수적으로 구축해 주어야 하는 클래스이다.

두 번째로 언급한 NSWindowController 는 Document 창에서의 컨트롤러 역할을 하기 때문에 대부분의 경우 구축해 주어야 하는 클래스이다. NSWindowController 의 상속체는 nib 파일 내에서 Document 윈도우의 delegate 역할을 구현해 주기에도 좋다.

NSDocumentController 는 문서상으로는 대부분의 경우 구현하지 않는 것이 좋다고 하고 있다. 이 클래스는 새 문서를 만들거나 최근에 열었던 문서 관리 등 커스터마이즈 될 일이 별로 없는 일들을 수행하기 때문이다.

왼쪽 그림을 보면 NSDocumentController 를 최 상위로 두고, 그 아래로 NSDocument, Window Controller, 그리고 각 View 별 Controller 가 사용된다는 것을 알 수 있다.

또한, NSWindowController 는 한 개의 Document 가 가질 수 있는 윈도우들의 갯수만큼 구현될 수 있다. ( 많은 경우 하나의 Document 는 하나 이상의 윈도우에 의해서 표현될 수 있다. )

 NSWindowController 의 구현 과정

1. NSWindowController 를 상속받는 빈 클래스를 생성한다.

2. Document 에 관련된 xib 의 file owner 를 상속받은 클래스로 변경해 준다.

3. NSDocument 의 구현체에서 makeWindowController 를 다음과 같이 상속받는다.

- (void) makeWindowControllers

{

memoWindowController = [[MemoWindowController alloc] initWithWindowNibName:[self windowNibName]];

[self addWindowController:memoWindowController];

[memoWindowController release];

}

document 의 xib 파일을 확인해 보면 윈도우 객체에 아래와 같이 delegate 가 설정되어 있는 것을 확인할 수 있다. 만약 delegate 가 설정되지 않은 경우에는 delegate 를 file owner 에 연결해서 상속받아 구현한 NSWindowController 를 document window 의 delegate 로써 활용할 수 있다.

상속받은 window controller 에서 관련 document 를 참조하기 위해서는 이미 구현되어 있는 멤버 함수인 document 를 이용하여 접근이 가능하다.