KR20100108053A

KR20100108053A - Ｕｒｌ을 이용한 분산 컨트롤 방법 및 장치

Info

Publication number: KR20100108053A
Application number: KR1020090026505A
Authority: KR
Inventors: 최혁승
Original assignee: 삼성전자주식회사
Priority date: 2009-03-27
Filing date: 2009-03-27
Publication date: 2010-10-06
Also published as: US20100251350A1; KR101560185B1; US9182971B2; JP5805934B2; JP2010231781A

Abstract

클라이언트에 대한 적어도 하나 이상의 특성 정보를 제1 서버에 등록하는 단계와 클라이언트의 등록된 특성 정보에 기초하여 URL(Uniform Resource Locator) 포맷의 주소를 생성하는 단계와 제1 서버로부터 복제된(mirrored) 데이터를 저장하는 적어도 하나 이상의 제2 서버로부터, URL 주소를 이용하여 데이터를 획득하는 단계를 포함하는 분산 컨트롤 방법이 개시되어 있다.

Description

ＵＲＬ을 이용한 분산 컨트롤 방법 및 장치{Method for controlling device using URL in distributed network environment and apparatus thereof}

본 발명은 분산 네트워크 환경에서 URL을 이용한 분산 컨트롤 방법 및 장치에 관한 것이다.

최근 인터넷 기술의 성장과 더불어 CE 기기(Consumer Electronics Device) 또한 급속히 발전해가는 인터넷 기술과 융합되어, 서버-클라이언트로 이루어지는 네트워크는 시간이 흐를수록 다수의 디바이스들 간의 복잡한 네트워크로서 그 모습을 형성해가고 있다.

한편, 이러한 CE 기기들의 수가 계속적으로 증가하여 동종의 서비스를 제공하는 CE 기기들이 다수가 되는 경우에, 네트워크에서 이들 기기들을 담당하는 중앙 서버(centralized server)에는 로드(load)가 집중되어 서버의 유지 및 관리 비용이 증가하게 된다.

아울러, 인터넷 기반 CE 기기들은 펌웨어 업그레이드나, 각종 어플리케이션 업그레이드 등 각각의 제품 특성에 대응하는 서비스의 이용이 증가하고 있는 추세이다.

이때, 중앙 서버 및 다수의 클라이언트로 이루어지는 네트워크 환경에서는 중앙 서버가 다수의 클라이언트를 모두 집중하여 관장하게 되고, 각각의 클라이언트들은 특정한 인터페이스를 통하여 자신들의 제품 특성 정보를 중앙 서버에 전달하고, 서버는 이를 로직(logic) 처리하여 각 특성에 맞는 컨트롤 정보를 리턴해준다. 예를 들어, 디바이스가 자신의 제품 특성 정보인 ID, 모델명, 펌웨어 버전 정보, 각종 토큰 등을 중앙 서버로 전송하면, 서버는 이를 분석하여 디바이스에 적용가능한 컨트롤 데이터를 자신의 DB에서 검색하고 이를 디바이스에게 돌려준다. 디바이스는 서버로부터 컨트롤 데이터를 다운로드하여 실행시키고, 자신의 상태(state)를 변경시키게 된다. (예: 펌웨어 버전 업그레이드)

즉, 디바이스가 주기적으로 서버를 향해 쿼리(query)를 보내면, 서버의 로직에서는 버전 체크, 사전 스케줄링, 정책(policy) 제어 등을 통해 컨트롤 명령 메시지를 디바이스로 보낸다. 아울러, 디바이스가 각종 컨텐츠에 대한 다운로드 요청 메시지를 서버에게 보내면 서버는 트래픽 제어(throttle control)를 통하여 디바이스 요청에 대응하는 데이터의 바이너리 이미지(binary image)를 암호화된 상태로 전송해준다.

본 발명의 목적은 다수의 클라이언트에게 공유 가능한 정적 데이터(static data)에 있어서 URL 주소를 이용한 분산 컨트롤 방법과 그 장치를 제공하는 것이다.

상기 목적을 달성하기 위하여 본 발명의 일 실시예에 따르면, 제1 서버와 네 트워크로 연결된 클라이언트의 분산 컨트롤 방법은 상기 클라이언트에 대한 적어도 하나 이상의 특성 정보를 제1 서버에 등록하는 단계와; 상기 클라이언트의 등록된 특성 정보에 기초하여 URL(Uniform Resource Locator) 포맷의 주소를 생성하는 단계와; 상기 제1 서버로부터 복제된(mirrored) 데이터를 저장하는 적어도 하나 이상의 제2 서버로부터, 상기 생성된 URL 주소를 이용하여 상기 데이터를 획득하는 단계를 포함한다.

상기 제2 서버에 저장된 상기 데이터는 정적 데이터(static data)로서 상기 제1 서버로부터 분산되어(distributed) 캐쉬(cached)된 데이터인 것이 바람직하다.

상기 등록하는 단계는, 상기 클라이언트의 특성 정보를 상기 제1 서버로 전송하는 단계와; 상기 전송된 특성 정보에 해당하는 적어도 하나 이상의 프롬프트(prompt) 정보를 상기 제1 서버로부터 수신하는 단계를 더 포함하며, 상기 URL 포맷의 주소를 생성하는 단계는, 상기 수신된 적어도 하나 이상의 프롬프트 정보에 기초하여 상기 주소를 생성하는 것이 바람직하다.

상기 클라이언트의 특성 정보는 모델 번호, S/W코드, DUID(Device Unique ID) 및 IP 주소 중 적어도 하나 이상을 포함하며, 상기 프롬프트 정보는 등록 번호, 지역명, 그룹 태그(grouping tag), 프롬프트 베이스 URL(prompt base URL) 및 프롬프트 폴링 간격(prompt polling period) 중 적어도 하나 이상을 포함하는 것이 바람직하다.

상기 데이터를 획득하는 단계는, 상기 제2 서버로부터 통지 메시지(notification message)를 청취하는 단계와; 상기 청취된 통지 메시지를 해석하 여, 상기 클라이언트에 해당되는 내용이 포함되어 있는지를 판단하는 단계와; 상기 판단 결과, 상기 클라이언트에 해당되는 내용이 포함되어 있지 않은 경우에 다음 통지 메시지를 대기하는 프롬프트 스케줄링(prompt scheduling) 작업을 수행하는 단계와; 상기 판단 결과, 상기 클라이언트에 해당되는 내용이 포함되어 있는 경우에 상기 데이터를 획득하기 위하여 카운트 스케줄링(count scheduling) 작업을 수행하는 단계를 더 포함하는 것이 바람직하다.

상기 프롬프트 스케줄링 작업을 수행하는 단계는, 상기 통지 메시지의 변경여부를 나타내는 헤더 정보(ETag: Entity Tag)를 확인하는 단계와; 상기 확인된 헤더 정보가 상기 클라이언트에 기저장된 헤더 정보와 다른 경우에 상기 통지 메시지의 본문(body)를 획득하는 단계와; 상기 통지 메시지의 본문을 해석하여, 상기 클라이언트에 해당되는 내용이 포함되어 있는 경우에 상기 카운트 스케줄링 작업을 수행하는 단계를 더 포함하는 것이 바람직하다.

상기 카운트 스케줄링 작업을 수행하는 단계는, 상기 제1 서버로부터 상기 클라이언트에 배정된 카운트 값을 획득하는 단계를 더 포함하며, 상기 카운트 값은 제1 서버에서 컨트롤 요청을 수신할 때마다 순차적으로 증가하는 값인 것이 바람직하다.

상기 데이터를 획득하는 단계는, 상기 제1 서버와 동기화하여 제2 서버로 복제된 조절 정보(adjust information)를 상기 제2 서버로부터 수신하는 단계와; 상기 수신된 조절 정보와 상기 클라이언트에 배정된 카운트 값을 비교하여 상기 데이터를 수신하는 단계를 더 포함하는 것이 바람직하다.

상기 데이터를 수신하는 단계는, 상기 생성된 URL 포맷의 주소를 이용하여 상기 제2 서버에 캐쉬된 상기 데이터를 수신하며, 상기 데이터에 대한 디지털 인증서(digital signature)를 상기 제2 서버로부터 수신하는 단계를 더 포함하는 것이 바람직하다.

상기 수신된 디지털 인증서를 이용하여 유효성 검증을 수행하는 단계와; 상기 유효성 검증이 성공한 경우에, 상기 수신된 데이터를 이용하여 상기 클라이언트의 소프트웨어를 업그레이드하는 단계를 더 포함하는 것이 바람직하다.

한편, 상기 목적을 달성하기 위하여 본 발명의 다른 실시예에 따르면, 제1 서버와 네트워크로 연결된 클라이언트의 분산 컨트롤 장치는 상기 클라이언트에 대한 적어도 하나 이상의 특성 정보를 제1 서버에 등록하는 특성 정보 등록부와; 상기 클라이언트의 등록된 특성 정보에 기초하여 URL(Uniform Resource Locator) 포맷의 주소를 생성하는 주소 생성부와; 상기 제1 서버로부터 복제된(mirrored) 데이터를 저장하는 적어도 하나 이상의 제2 서버로부터, 상기 생성된 URL 주소를 이용하여 상기 데이터를 획득하는 데이터 수신부를 포함한다.

상기 특성 정보 등록부는, 상기 클라이언트의 특성 정보를 상기 제1 서버로 전송하고, 상기 전송된 특성 정보에 해당하는 적어도 하나 이상의 프롬프트(prompt) 정보를 상기 제1 서버로부터 수신하며, 상기 주소 생성부는, 상기 수신된 적어도 하나 이상의 프롬프트 정보에 기초하여 상기 주소를 생성하는 것이 바람 직하다.

상기 데이터 수신부는, 상기 제2 서버로부터 통지 메시지(notification message)를 청취하는 메시지 리스너와; 상기 청취된 통지 메시지를 해석하여, 상기 클라이언트에 해당되는 내용이 포함되어 있지 않은 경우에 다음 통지 메시지를 대기하는 프롬프트 스케줄러(prompt scheduler)와; 상기 클라이언트에 해당되는 내용이 포함되어 있는 경우에 상기 데이터를 획득하기 위하여 카운트 스케줄링을 수행하는 카운트 스케줄러(count scheduler)를 더 포함하는 것이 바람직하다.

상기 프롬프트 스케줄러는, 상기 통지 메시지의 변경여부를 나타내는 헤더 정보(ETag: Entity Tag)를 확인하고, 상기 확인된 헤더 정보가 클라이언트에 기저장된 헤더 정보와 다른 경우에 상기 통지 메시지의 본문(body)를 획득하여, 상기 클라이언트에 해당되는 내용이 포함되어 있는 경우에 상기 카운트 스케줄러가 스케줄링 작업을 수행하도록 하는 것이 바람직하다.

상기 카운트 스케줄러는, 상기 클라이언트에 배정된 카운트 값으로서, 상기 제1 서버에서 컨트롤 요청을 수신할 때마다 순차적으로 증가하는 값인 카운트 값을 상기 제1 서버로부터 획득하는 것이 바람직하다.

상기 데이터 수신부는, 상기 제1 서버와 동기화하여 제2 서버로 복제된 조절 정보(adjust information)를 상기 제2 서버로부터 수신하는 조절 정보 수신부를 더 포함하며, 상기 수신된 조절 정보와 상기 클라이언트에 배정된 카운트 값을 비교하여 상기 데이터를 제2 서버로부터 수신하는 것이 바람직하다.

상기 데이터 수신부는, 상기 생성된 URL 포맷의 주소를 이용하여 상기 제2 서버에 캐쉬된 상기 데이터를 수신하며, 상기 데이터에 대한 디지털 인증서(digital signature)를 상기 제2 서버로부터 수신하는 것이 바람직하다.

상기 분산 컨트롤 장치는 상기 수신된 디지털 인증서를 이용하여 유효성 검증을 수행하는 유효성 검증부와; 상기 유효성 검증이 성공한 경우에, 상기 수신된 데이터를 이용하여 상기 클라이언트의 소프트웨어를 업그레이드하는 업그레이드부를 더 포함하는 것이 바람직하다.

한편, 상기 목적을 달성하기 위하여 본 발명의 또 다른 실시예에 따른 분산 컨트롤 시스템은 클라이언트에 대한 적어도 하나 이상의 특성 정보를 등록하고 상기 클라이언트를 컨트롤하는 제1 서버와; 상기 제1 서버로부터 분산되어(distributed) 캐쉬(cached)된 정적 데이터(static data)를 저장하는 적어도 하나 이상의 제2 서버와; 상기 특성 정보에 기초한 URL(Uniform Resource Locator) 포맷의 주소를 이용하여 제2 서버로부터 상기 정적 데이터를 획득하는 클라이언트를 포함한다.

나아가, 본 발명은 상기 분산 컨트롤 방법을 구현하기 위한 프로그램이 기록된 컴퓨터로 읽을 수 있는 기록 매체를 포함한다.

본 발명과 본 발명의 동작상의 이점 및 본 발명의 실시에 의하여 달성되는 목적을 충분히 이해하기 위해서는 본 발명의 바람직한 실시예를 예시하는 첨부 도면 및 도면에 기재된 내용을 참조하여야 한다.

이하, 첨부된 도면을 참조하여 본 발명의 바람직한 실시예에 대해 상세히 설 명한다.

도 1은 본 발명의 일 실시예에 따라, 포괄적인 영역(global range)의 데이터가 URL을 이용하여 서버-클라이언트 사이에서 전달되는 관계를 나타내는 개념도이다.

일반적인 컨트롤 서버-클라이언트(control server/client) 방식에서는 각 클라이언트별 상태 관리가 서버의 논리 연산 수행에 의해 관리된다. 따라서, 모든 컨트롤 요청 메시지(control request message)에 관하여 부하(load)가 중앙 서버로 집중되게 된다. 더욱이, 서버 설계시 용량을 결정하는 것은 피크 타임 요청(peak time request)에 따라야 하는 문제도 발생한다. 무엇보다 가장 큰 문제는 공유 가능한 정보를 전달하는 경우 이를 활용하기가 어렵다는 것이다.

도 1을 참조하면, 본 발명의 일 실시예에서는 서버(110)가 제공하는 데이터(111)를 동적(dynamic)/정적(static)으로 구분하고, 또한 포괄적(global)/개별적(specific)으로 구분하였다.

여기서 포괄적 영역(global range)의 데이터, 즉 그룹으로 적용 가능하여 공유할 수 있는 성격의 데이터인 경우에는 URL(Uniform Resource Locator) 주소 형식으로 구성하여, 이를 분산 캐쉬(distributed cache, 130)에 배포(publish)하고, 클라이언트인 디바이스(120)는 URL을 이용하여 접근할 수 있도록 한다. 나머지 데이터의 경우에는 캐쉬되지 않은 상태로 서버에서 클라이언트로 전송될 수 있다.

여기서 분산 캐쉬된 데이터는 CDN(Content Delivery Networks) 또는 캐쉬 서버(cache server)를 이용하여 클라이언트에 제공될 수 있다. 따라서, 클라이언트 는 알려진 특성 데이터를 기반으로 요청 URL을 조합하고, 이를 이용하여 데이터를 검색할 수 있다.

펌웨어를 업그레이드하는 경우로 예를 들면, 동작을 크게 3단계로 나눌 수 있는데, 1단계는 디바이스를 등록하고 URL을 조합하고, 태깅하는 등의 사전-프로세스(pre-processing) 단계이며, 2단계는 펌웨어 버전을 체크하고, 통지(notification) 메시지를 획득하는 등의 통지 대기(standby for notification) 단계이다. 마지막으로 3단계는 전송 트래픽을 제한하면서 데이터를 다운로드하고 펌웨어를 업그레이드하는 단계이다. 이때, 2단계에서는 캐쉬된 데이터를 이용하고, 3단계에서는 가능하면 캐쉬된 데이터를 이용하는 것이 바람직하다. 이로써, 모든 정보를 전달함에 있어서 최대한 공유할 수 있는 형태로서 서버-클라이언트 구조를 설계할 수 있다.

도 2는 본 발명의 다른 실시예에 따라, 네트워크로 연결된 클라이언트의 분산 컨트롤 방법을 설명하기 위한 플로우 차트이다.

도 2를 참조하면, 제1 서버와 네트워크로 연결된 클라이언트의 분산 컨트롤 방법은 클라이언트에 대한 적어도 하나 이상의 특성 정보를 제1 서버(중앙 서버)에 등록하는 단계(210)와 클라이언트의 등록된 특성 정보에 기초하여 URL(Uniform Resource Locator) 포맷의 주소를 생성하는 단계(220)와 제1 서버로부터 복제된(mirrored) 데이터를 저장하는 적어도 하나 이상의 제2 서버(캐쉬 서버)로부터, URL 주소를 이용하여 목표 데이터를 획득하는 단계(230)를 포함한다.

이때, 제2 서버에 저장된 상기 데이터는 다수의 디바이스들이 공유 가능한 정적 데이터(static data)로서 제1 서버로부터 분산 캐쉬된 데이터이다.

분산 캐쉬된 데이터에 접근하기 위한 URL 구조는 디바이스 제품별로 해당 특성 정보를 이용하여 조합가능하며, 다중 CDN 어드레싱(Multi-CDN addressing)에 친화적이다. 예를 들면, 특정 모델의 최신 펌웨어 버전을 확인하고자 하는 경우에는 "http://{지역}.otn-m.sec.com/tv/{모델명}/current/ver"으로 URL 조합이 가능하다. 한편, 특정 모델의 특정 펌웨어 버전에 대한 통지(notification)을 청취(listen)하기 위해서는 "http://{지역}.otn-m.sec.com/tv/{모델명}/{디바이스 F/W 코드}/notice"가 될 수 있고, 특정 모델의 특정 펌웨어 이미지(image)를 획득하기 위해서는 "http://{지역}.otn-m.sec.com/tv/{모델명}/{목표 F/W 코드}/image"가 될 수 있다. 또한, 특정 모델의 특정 펌웨어 버전의 이미지에 대한 펌웨어용 디지털 인증서를 획득하기 위해서는 "http://{지역}.otn-m.sec.com/tv/{모델명}/{목표 F/W 코드}/ds/{디바이스 F/W 코드}"가 될 수 있다.

디바이스별로 변경가능한 {지역}, {모델명}, {목표 F/W 코드}, {디바이스 F/W 코드} 등에 대해 실제 몇 개의 예를 들어 살펴보면, 한국지역의 OTN-S 서버에서 LN46A750R1F 모델의 T-RBYAUSC1009.1 버전의 DTV를 위한 통지 정보는 "http://ko.otn-s.sec.com/tv/LN46A750R1F/T-RBYAUSC1009.1/notice"가 될 수 있다. 한가지 더 예를 들면, 미국지역의 OTN-S 서버에서, LN46A750R1F 모델 T-RBYAUSC1009.1 버전의 DTV를 위한 T-RBYAUSC1012.1 버전의 디지털 인증서(digital signature)는 "http://us.otn-s.sec.com/tv/LN46A750R1F/T-RBYAUSC1012.1/ds/T-RBYAUSC1009.1"이 될 수 있다.

본 발명의 일 실시예에 따른 분산 컨트롤 방법은 펌웨어 또는 어플리케이션 업그레이드 등에 적용가능한 바, 이하 펌웨어를 업그레이드하는 경우를 예를 들어 각각의 단계를 구체적으로 살펴보기로 한다.

도 3은 본 발명의 일 실시예에 따라, 펌웨어 업그레이드 과정에서 최초 등록(registration) 및 최초 통지(notice)의 청취 과정을 나타내는 순서도이다.

도 3을 참조하면, 클라이언트를 컨트롤하고, 모니터링(monitoring)하는 제1 서버(dynamic server)와 CDN 적용가능한 제2 서버(static server)와 클라이언트인 디바이스에서의 작업 순서를 나타내는 3개의 수평 라인이 표시되어 있다.

먼저, 클라이언트인 디바이스는 자신의 특성 정보를 등록 정보로서 제1 서버에게 전달한다(310). 이때, 특성 정보는 모델번호, 펌웨어 코드, DUID(Device Unique ID), IP 주소 등이 될 수 있다.

제1 서버는 클라이언트의 특성 정보를 등록한 후, 프롬프트 정보(prompt information)를 리턴한다(320). 이때, 프롬프트 정보는 등록 번호, 지역명, 그룹 태그(grouping tag), 프롬프트 베이스 URL(prompt base URL) 및 프롬프트 폴링 간격(prompt polling period) 등이 될 수 있다.

클라이언트는 수신한 프롬프트 정보 중 프롬프트 베이스 URL(prompt base URL) 형식에 따라 지역명, 태그, 모델 번호, 펌웨어 코드 등을 이용하여 프롬프트 URL(prompt URL)을 조합한다(330). 예를 들면, "http://{지역명}.otn-m.sec.com/tv/{모델번호}/{펌웨어 코드}/notice"가 될 수 있다. 여기까지가 최초 등록 과정이다.

다음으로 통지(notice) 청취과정을 살펴보면, 프롬프트 URL을 이용하여 제2 서버로부터 해당 펌웨어 코드용 통지를 수신하여(350), 해당 통지의 ETag(Entity Tag) 및 본문을 획득하고 ETag를 저장한다(340). ETag는 HTTP 1.1 호환 웹서버가 반환하는 응답 헤더로서, 리소스가 변경됐는지를 확인하는데 필요한 정보를 제공한다. 캐쉬 기능이 있는 애플리케이션(예: 브라우저)에서 유용하게 사용되는데, ETag 태그를 참조하여 이전에 수신했던 리소스의 ETag와 동일한 ETag라면 중복된 리소스를 불필요하게 다운로드하는 경우를 줄일 수 있다. ETag의 값은 파일 크기와 파일을 수정한 날짜를 기반으로 만들거나 체크섬(checksum)을 이용하여 생성할 수 있다.

다음으로 청취한 통지 메시지의 내용을 정해진 인터프리터 법칙에 따라 해석한다(360). 해석 결과, 디바이스에 해당되는 통지 내용이 포함되어 있다면 통지 메시지를 수행하고, 포함되어 있지 않다면 프롬프트 스케줄링 작업을 수행한다(370). 프롬프트 스케줄링 작업은 상기 수신된 프롬프트 폴링 간격(prompt polling period)을 이용한다. 여기까지가 통지 메시지의 최초 청취과정이다.

참고로, 통지(notice) 메시지의 XML기반 구현 예시 코드(PDL: program design language)를 살펴보면 다음과 같다.

<?xml version="1.0"?>

</edit>

<string>T-RBYAWWC1012.1<string>

</edit>

<region>_Seoul</region>

…

</test>

<method type="http_throttle"

image_url="http://{otn_baseurl}/{targetfirmcode}/image“

… />

</edit>

<seq>

<method>http_throttle</method>

</seq>

</match>

도 4는 본 발명의 일 실시예에 따라, 펌웨어 업그레이드 과정에서 프롬프트 스케줄링 과정을 나타내는 순서도이다.

도 4를 참조하면, 제1 서버는 업그레이드 진행 대상 디바이스, 그룹 및 정책(policy)를 결정하고, 이를 제2 서버로 내보낸다(export)(410).

제2 서버는 해당 펌웨어 코드용 통지 메시지를 저장하고 있으며(420), 클라이언트는 먼저 프롬프트 URL을 이용하여 해당 통지의 ETag를 획득하고(430), 기저장된 ETag와 같은지 판단하고(440), 다른 경우에 프롬프트 URL을 이용하여 해당 통지의 본문(body)를 획득한다(450). 여기서, 펌웨어 버전에 대한 업그레이드가 없는 경우에는 통지의 본문을 수신하는 과정은 생략된다(version check polling).

청취한 통지 메시지의 내용을 정해진 인터프리터 법칙에 따라 해석하고(460), 디바이스에 해당되는 통지 내용이 포함되어 있다면 통지 메시지를 수행하고, 포함되어 있지 않다면 프롬프트 스케줄링 작업을 수행한다(470). 여기까지가 디바이스 그룹의 정책을 접수하는 과정이다.

도 5는 본 발명의 일 실시예에 따라, 펌웨어 업그레이드 과정에서 사전 스케줄링(pre-scheduling) 과정을 나타내는 순서도이다.

도 5를 참조하면, 통지 메시지가 수행되는 경우에, 먼저 통지 내용을 분석한다(510). 다음으로 통지 내용에 정의된 시퀀스대로 메소드(method)를 수행한다(520). 여기까지가 앞서 살펴본 예시 코드 PDL의 프로세싱 과정이다.

그런 다음, 캐쉬된 데이터를 다운로드하기 위하여 사전 스케줄링을 수행하는데(530), 통지 메시지의 내용 중 메소드에 정의된 변수들을 이용하여 해당 디바이스의 카운트 스케줄링(count scheduling) 작업을 수행한다.

도 6은 본 발명의 일 실시예에 따라, 펌웨어 업그레이드 과정에서 카운트 스 케줄링 및 트래픽 조절(adjust) 과정을 나타내는 순서도이다.

도 6을 참조하면, 먼저 제1 서버에서 카운트 데몬(count daemon)이 수행되어(610) throttle 컨트롤 요청시마다 카운트 값이 순차적으로 증가(increment)되고, 클라이언트에서는 카운트 URL에 접근하여 상기 카운트 값을 획득한다(620).

한편, 제1 서버에서는 조절 데몬(adjust daemon)이 수행되어(630) 모니터링 정보 및 다운로드 상태에 기초한 클라이언트별 트래픽 예상 정보를 내보내고(export), 목표 펌웨어 코드용 조절 정보(adjust information)이 생성된다(640). 아울러, 동시에 제2 서버에서도 복제된(mirrored) 동일한 조절 정보가 저장된다(650). 조절 정보는 예를 들어 서비스 범위(service range), 평균 서비스 기간(average unit service period), 참조 타임스탬프(ref. timestamp) 등이다.

클라이언트는 조절 URL에 접근하여 이러한 조절 정보를 획득한다(660). 카운트 값이 드롭(drop) 범위 내에 있는 경우, 카운트 스케줄링이 다시 수행된다(670).

다음으로 조절 정보를 참조하여, 클라이언트가 데이터를 다운로드할 수 있는 해당 범위 내에 속한다면 데이터 회수(retrieve) 과정이 수행되고(680), 아닌 경우에는 조절 스케줄링 작업이 수행된다(690).

도 7은 본 발명의 일 실시예에 따라, 펌웨어 업그레이드 과정에서 데이터 회수(retrieve) 과정을 나타내는 순서도이다.

도 7를 참조하면, 목표 펌웨어 버전의 바이너리 이미지(binary image)가 제2 서버에 복제되어(mirrored)있고(710), 클라이언트는 펌웨어 이미지를 획득한 다(720). 아울러, 획득한 펌웨어 이미지를 실행하기 위해 필요한 디지털 인증서(digital signature)를 가져야 하는데(740), 이는 제2 서버로부터 획득할 수 있다(730). 디지털 인증서의 획득이 성공하면(750), 목표 펌웨어 버전의 바이너리 이미지를 실행(perform)할 수 있다.

도 8은 본 발명의 일 실시예에 따라, 펌웨어 업그레이드 과정에서 유효성 검사 및 업그레이드 과정을 나타내는 순서도이다.

도 8을 참조하면, 획득한 목표 펌웨어 버전의 바이너리 이미지를 실행(perform)하기 위해 유효성 검사 및 업그레이드 과정이 나타있는데, 먼저 펌웨어 이미지를 해쉬(hash)하여(810), 상기 디지털 인증서의 해쉬값과 비교하고, 내장된 공개키(public key)를 이용하여 인증서를 확인한다(820). 매치여부를 판단한 결과(830), 유효성이 검사가 성공하면 펌웨어 업그레이드를 수행한다(840). 이때, 필요하다면 백업(back-up)을 함께 수행할 수 있다.

만약 업그레이드가 실패하면 복구 프로세스가 동작하고, 업그레이드가 성공하면 상기 일련의 작업은 최초 등록 과정부터 다시 반복된다(850).

도 9는 본 발명의 다른 실시예에 따라, 네트워크로 연결된 클라이언트의 분산 컨트롤 장치를 설명하기 위한 플로우 차트이다.

도 9를 참조하면, 본 발명에 따른 분산 컨트롤 장치(900)의 일 실시예는 클라이언트에 대한 적어도 하나 이상의 특성 정보를 제1 서버(960)에 등록하는 특성 정보 등록부(910)와 클라이언트의 등록된 특성 정보에 기초하여 URL(Uniform Resource Locator) 포맷의 주소를 생성하는 주소 생성부(920)와 복제된(mirrored) 데이터를 저장하는 적어도 하나 이상의 제2 서버(970)로부터, URL 주소를 이용하여 데이터를 획득하는 데이터 수신부(930)를 포함한다.

한편 데이터 수신부(930)는 제2 서버(970)로부터 통지 메시지(notification message)를 청취하는 메시지 리스너(931)와 통지 메시지를 해석하여, 클라이언트에 해당되는 내용이 포함되어 있지 않은 경우에 다음 통지 메시지를 대기하는 프롬프트 스케줄러(prompt scheduler, 932)와 클라이언트에 해당되는 내용이 포함되어 있는 경우에 상기 데이터를 획득하기 위하여 카운트 스케줄링을 수행하는 카운트 스케줄러(count scheduler, 933)를 더 포함할 수 있다. 아울러, 제1 서버로부터 제2 서버로 복제된 조절 정보(adjust information)를 수신하는 조절 정보 수신부(934)를 더 포함할 수도 있다.

본 발명에 따른 분산 컨트롤 장치(900)의 일 실시예는 디지털 인증서를 이용하여 유효성 검증을 수행하는 유효성 검증부(940)와 유효성 검증이 성공한 경우에, 수신된 데이터를 이용하여 소프트웨어 업그레이드를 수행하는 업그레이드부(950)를 더 포함할 수 있다.

상기 실시예의 분산 컨트롤 방법에 따르면, 요청 빈도가 낮은 그룹형태의 컨트롤에 대한 서버 부하를 제거할 수 있고, 피크타임 때 서버에 부하가 집중되는 현상을 완화시킬 수 있으며, 이로써 서버 유지 비용이 감소할 수 있다. 아울러 Multi-CDN 에 적용가능하여 웹 서비스 연동 DTV, 모바일 폰 및 기타 CE 제품에서 사용할 수 있다.

한편, 상술한 본 발명의 분산 컨트롤 방법은 컴퓨터에서 실행될 수 있는 프 로그램으로 작성가능하고, 컴퓨터로 읽을 수 있는 기록매체를 이용하여 상기 프로그램을 동작시키는 범용 디지털 컴퓨터에서 구현될 수 있다.

또한, 상술한바와 같이 본 발명에서 사용된 데이터의 구조는 컴퓨터로 읽을 수 있는 기록매체에 여러 수단을 통하여 기록될 수 있다.

상기 컴퓨터로 읽을 수 있는 기록매체는 마그네틱 저장매체(예를 들면, 롬, 플로피 디스크, 하드디스크 등), 광학적 판독 매체(예를 들면, 시디롬, 디브이디 등)와 같은 저장매체를 포함한다.

이제까지 본 발명에 대하여 그 바람직한 실시예들을 중심으로 살펴보았다. 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자는 본 발명이 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 변형된 형태로 구현될 수 있음을 이해할 수 있을 것이다. 그러므로 개시된 실시예들은 한정적인 관점이 아니라 설명적인 관점에서 고려되어야 한다. 본 발명의 범위는 전술한 설명이 아니라 특허청구범위에 나타나 있으며, 그와 동등한 범위 내에 있는 모든 차이점은 본 발명에 포함된 것으로 해석되어야 할 것이다.

도 3은 본 발명의 일 실시예에 따라, 펌웨어 업그레이드 과정에서 최초 등록 및 최초 통지(notice)의 청취 과정을 나타내는 순서도이다.

도 6은 본 발명의 일 실시예에 따라, 펌웨어 업그레이드 과정에서 카운트 스케줄링 및 트래픽 조절(adjust) 과정을 나타내는 순서도이다.

상기 몇 개의 도면에 있어서 대응하는 도면 번호는 대응하는 부분을 가리킨다. 도면이 본 발명의 실시예들을 나타내고 있지만, 도면이 축척에 따라 도시된 것은 아니며 본 발명을 보다 잘 나타내고 설명하기 위해 어떤 특징부는 과장되어 있을 수 있다.

Claims

제1 서버와 네트워크로 연결된 클라이언트의 분산 컨트롤 방법에 있어서,

상기 클라이언트에 대한 적어도 하나 이상의 특성 정보를 제1 서버에 등록하는 단계와;

상기 클라이언트의 등록된 특성 정보에 기초하여 URL(Uniform Resource Locator) 포맷의 주소를 생성하는 단계와;

상기 제1 서버로부터 복제된(mirrored) 데이터를 저장하는 적어도 하나 이상의 제2 서버로부터, 상기 생성된 URL 주소를 이용하여 상기 데이터를 획득하는 단계를 포함하는 것을 특징으로 하는 분산 컨트롤 방법.
제1항에 있어서,

상기 제2 서버에 저장된 상기 데이터는 정적 데이터(static data)로서 상기 제1 서버로부터 분산되어(distributed) 캐쉬(cached)된 데이터인 것을 특징으로 하는 분산 컨트롤 방법.
제2항에 있어서,

상기 등록하는 단계는,

상기 클라이언트의 특성 정보를 상기 제1 서버로 전송하는 단계와;

상기 전송된 특성 정보에 해당하는 적어도 하나 이상의 프롬프트(prompt) 정 보를 상기 제1 서버로부터 수신하는 단계를 더 포함하며,

상기 URL 포맷의 주소를 생성하는 단계는,

상기 수신된 적어도 하나 이상의 프롬프트 정보에 기초하여 상기 주소를 생성하는 것을 특징으로 하는 분산 컨트롤 방법.
제3항에 있어서,

상기 클라이언트의 특성 정보는 모델 번호, S/W코드, DUID(Device Unique ID) 및 IP 주소 중 적어도 하나 이상을 포함하며,

상기 프롬프트 정보는 등록 번호, 지역명, 그룹 태그(grouping tag), 프롬프트 베이스 URL(prompt base URL) 및 프롬프트 폴링 간격(prompt polling period) 중 적어도 하나 이상을 포함하는 것을 특징으로 하는 분산 컨트롤 방법.
제3항에 있어서,

상기 데이터를 획득하는 단계는,

상기 제2 서버로부터 통지 메시지(notification message)를 청취하는 단계와;

상기 청취된 통지 메시지를 해석하여, 상기 클라이언트에 해당되는 내용이 포함되어 있는지를 판단하는 단계와;

상기 판단 결과, 상기 클라이언트에 해당되는 내용이 포함되어 있지 않은 경우에 다음 통지 메시지를 대기하는 프롬프트 스케줄링(prompt scheduling) 작업을 수행하는 단계와;

상기 판단 결과, 상기 클라이언트에 해당되는 내용이 포함되어 있는 경우에 상기 데이터를 획득하기 위하여 카운트 스케줄링(count scheduling) 작업을 수행하는 단계를 더 포함하는 것을 특징으로 하는 분산 컨트롤 방법.
제5항에 있어서,

상기 프롬프트 스케줄링 작업을 수행하는 단계는,

상기 통지 메시지의 변경여부를 나타내는 헤더 정보(ETag: Entity Tag)를 확인하는 단계와;

상기 확인된 헤더 정보가 상기 클라이언트에 기저장된 헤더 정보와 다른 경우에 상기 통지 메시지의 본문(body)를 획득하는 단계와;

상기 통지 메시지의 본문을 해석하여, 상기 클라이언트에 해당되는 내용이 포함되어 있는 경우에 상기 카운트 스케줄링 작업을 수행하는 단계를 더 포함하는 것을 특징으로 하는 분산 컨트롤 방법.
제6항에 있어서,

상기 카운트 스케줄링 작업을 수행하는 단계는,

상기 제1 서버로부터 상기 클라이언트에 배정된 카운트 값을 획득하는 단계를 더 포함하며,

상기 카운트 값은 제1 서버에서 컨트롤 요청을 수신할 때마다 순차적으로 증 가하는 값인 것을 특징으로 하는 분산 컨트롤 방법.
제7항에 있어서,

상기 데이터를 획득하는 단계는,

상기 제1 서버와 동기화하여 제2 서버로 복제된 조절 정보(adjust information)를 상기 제2 서버로부터 수신하는 단계와;

상기 수신된 조절 정보와 상기 클라이언트에 배정된 카운트 값을 비교하여 상기 데이터를 수신하는 단계를 더 포함하는 것을 특징으로 하는 분산 컨트롤 방법.
제8항에 있어서,

상기 데이터를 수신하는 단계는,

상기 생성된 URL 포맷의 주소를 이용하여 상기 제2 서버에 캐쉬된 상기 데이터를 수신하며,

상기 데이터에 대한 디지털 인증서(digital signature)를 상기 제2 서버로부터 수신하는 단계를 더 포함하는 것을 특징으로 하는 분산 컨트롤 방법.
제9항에 있어서,

상기 수신된 디지털 인증서를 이용하여 유효성 검증을 수행하는 단계와;

상기 유효성 검증이 성공한 경우에, 상기 수신된 데이터를 이용하여 상기 클 라이언트의 소프트웨어를 업그레이드하는 단계를 더 포함하는 것을 특징으로 하는 분산 컨트롤 방법.
제1 서버와 네트워크로 연결된 클라이언트의 분산 컨트롤 장치에 있어서,

상기 클라이언트에 대한 적어도 하나 이상의 특성 정보를 제1 서버에 등록하는 특성 정보 등록부와;

상기 클라이언트의 등록된 특성 정보에 기초하여 URL(Uniform Resource Locator) 포맷의 주소를 생성하는 주소 생성부와;

상기 제1 서버로부터 복제된(mirrored) 데이터를 저장하는 적어도 하나 이상의 제2 서버로부터, 상기 생성된 URL 주소를 이용하여 상기 데이터를 획득하는 데이터 수신부를 포함하는 것을 특징으로 하는 분산 컨트롤 장치.
제11항에 있어서,

상기 제2 서버에 저장된 상기 데이터는 정적 데이터(static data)로서 상기 제1 서버로부터 분산되어(distributed) 캐쉬(cached)된 데이터인 것을 특징으로 하는 분산 컨트롤 장치.
제12항에 있어서,

상기 특성 정보 등록부는, 상기 클라이언트의 특성 정보를 상기 제1 서버로 전송하고, 상기 전송된 특성 정보에 해당하는 적어도 하나 이상의 프롬프 트(prompt) 정보를 상기 제1 서버로부터 수신하며,

상기 주소 생성부는, 상기 수신된 적어도 하나 이상의 프롬프트 정보에 기초하여 상기 주소를 생성하는 것을 특징으로 하는 분산 컨트롤 장치.
제13항에 있어서,

상기 데이터 수신부는,

상기 제2 서버로부터 통지 메시지(notification message)를 청취하는 메시지 리스너와;

상기 청취된 통지 메시지를 해석하여, 상기 클라이언트에 해당되는 내용이 포함되어 있지 않은 경우에 다음 통지 메시지를 대기하는 프롬프트 스케줄러(prompt scheduler)와;

상기 클라이언트에 해당되는 내용이 포함되어 있는 경우에 상기 데이터를 획득하기 위하여 카운트 스케줄링을 수행하는 카운트 스케줄러(count scheduler)를 더 포함하는 것을 특징으로 하는 분산 컨트롤 장치.
제14항에 있어서,

상기 프롬프트 스케줄러는,

상기 통지 메시지의 변경여부를 나타내는 헤더 정보(ETag: Entity Tag)를 확인하고, 상기 확인된 헤더 정보가 클라이언트에 기저장된 헤더 정보와 다른 경우에 상기 통지 메시지의 본문(body)를 획득하여, 상기 클라이언트에 해당되는 내용이 포함되어 있는 경우에 상기 카운트 스케줄러가 스케줄링 작업을 수행하도록 하는 것을 특징으로 하는 분산 컨트롤 장치.
제15항에 있어서,

상기 카운트 스케줄러는,

상기 클라이언트에 배정된 카운트 값으로서, 상기 제1 서버에서 컨트롤 요청을 수신할 때마다 순차적으로 증가하는 값인 카운트 값을 상기 제1 서버로부터 획득하는 것을 특징으로 하는 분산 컨트롤 장치.
제16항에 있어서,

상기 데이터 수신부는,

상기 제1 서버와 동기화하여 제2 서버로 복제된 조절 정보(adjust information)를 상기 제2 서버로부터 수신하는 조절 정보 수신부를 더 포함하며,

상기 수신된 조절 정보와 상기 클라이언트에 배정된 카운트 값을 비교하여 상기 데이터를 제2 서버로부터 수신하는 것을 특징으로 하는 분산 컨트롤 장치.
제17항에 있어서,

상기 데이터 수신부는,

상기 생성된 URL 포맷의 주소를 이용하여 상기 제2 서버에 캐쉬된 상기 데이터를 수신하며, 상기 데이터에 대한 디지털 인증서(digital signature)를 상기 제2 서버로부터 수신하는 것을 특징으로 하는 분산 컨트롤 장치.
제18항에 있어서,

상기 분산 컨트롤 장치는 상기 수신된 디지털 인증서를 이용하여 유효성 검증을 수행하는 유효성 검증부와;

상기 유효성 검증이 성공한 경우에, 상기 수신된 데이터를 이용하여 상기 클라이언트의 소프트웨어를 업그레이드하는 업그레이드부를 더 포함하는 것을 특징으로 하는 분산 컨트롤 장치.
분산 컨트롤 시스템에 있어서,

클라이언트에 대한 적어도 하나 이상의 특성 정보를 등록하고 상기 클라이언트를 컨트롤하는 제1 서버와;

상기 제1 서버로부터 분산되어(distributed) 캐쉬(cached)된 정적 데이터(static data)를 저장하는 적어도 하나 이상의 제2 서버와;

상기 특성 정보에 기초한 URL(Uniform Resource Locator) 포맷의 주소를 이용하여 제2 서버로부터 상기 정적 데이터를 획득하는 클라이언트를 포함하는 것을 특징으로 하는 분산 컨트롤 시스템.