KR20150121713A

KR20150121713A - 네트워크 노드 기능을 제공하기 위한 네트워크 노드들 사이의 할당 리소스

Info

Publication number: KR20150121713A
Application number: KR1020157026170A
Authority: KR
Inventors: 루돌프 스트리즈커; 피터 잔 뭐렌호프
Original assignee: 코닌클리즈케 케이피엔 엔.브이.; 네덜란제 오르가니자티에 포오르 토에게파스트-나투우르베텐샤펠리즈크 온데르조에크 테엔오
Priority date: 2013-03-18
Filing date: 2014-03-17
Publication date: 2015-10-29
Also published as: CN105359490A; EP2782318A1; WO2014147000A1; EP2976870A1; US20160285780A1

Abstract

본 발명은 제 2 네트워크 노드가 제1 네트워크 노드로 네트워크 노드 기능을 투명하게 오프로드하는데 사용할 수 있는 이용 가능한 리소스를 제 1 네트워크 노드가 광고하는 방법을 제공한다. 제1 네트워크 노드의 예는 클라이언트 장치(예를 들면, PC, 노트북, 태블릿, 스마트폰), 서버(예를 들면, 애플리케이션 서버, 프록시 서버, 클라우드 위치, 라우터)이다. 이용 가능한 리소스는 제1 네트워크 노드 또는 제1 네트워크에 대해 원격으로 존재하는 다른 네트워크 노드일 수 있다.

Description

네트워크 노드 기능을 제공하기 위한 네트워크 노드들 사이의 할당 리소스 {Allocating resources between network nodes for providing a network node function}

본 발명은 서버 기능과 같은 네트워크 노드 기능을 제공하기 위한 네트워크 노드 리소스의 할당에 관한 것이다. 보다 구체적으로 본 발명은 네트워크 노드 기능을 제공하기 위한 네트워크 노드들 및 네트워크 노드 기능에 액세스하기 위한 제 2 네트워크 노드에 통신 접속 가능한 제 1 네트워크 노드에 리소스(resources)를 할당하는 방법에 관한 것이다.

클라이언트-서버 애플리케이션에서 서버는 예를 들어, 웹 서버에서 웹 페이지를 검색하는, 클라이언트로부터의 서비스 요청을 처리한다. 일반적으로, 클라이언트와 서버 통신은 로컬 영역 네트워크, 인터넷 또는 전화망과 같은 매체(medium)에 의하여 처리된다. 클라이언트-서버 세션은 단일 요청과 응답으로 제한될 수 있으나, 또한 다수의 연속적인 요청과 응답을 포함할 수도 있다. 네트워크 오버 헤드는, 특히 단일 클라이언트 요청이 데이터베이스, 애플리케이션 서버 또는 클라이언트 자체에 대한 다수의 호출을 요구할 때, 클라이언트-서버 애플리케이션의 엔드-투-엔드(end-to-end) 성능에 영향을 미칠 수 있다고 알려져 있다. 네트워크 오버헤드는 네트워크의 동작 파라미터, 중계 네트워크, 및 서버와 클라이언트 장치 사이의 네트워크 요소들(예를 들면, 지연(latency), 대역폭, 홉(hops), 친화성, 데이터 처리 용량, 저장, 지리적 거리) 또는 클라이언트 장치에 서비스하는 운영자의 네트워크 의해 발생된다.

클라이언트-서버 통신이 다수의 연속적인 클라이언트-서버 상호작용으로 구성될 때, 대기 시간(waiting time)은 높은 네트워크 오버 헤드로 상당히 증가할 수 있다. 더구나, 클라이언트와 서버 사이의 임의의 중간 장치는, 예를 들어 전파 지연, 버퍼링, 큐잉, 에러율(error rate) 및/또는 혼잡으로 인해 통신 지연을 추가한다. 클라이언트 및 서버 장치의 처리 용량은 경험 지각 품질(perceived quality of experience) 에 영향을 미치는 또 다른 요인 일 수 있다. 예를 들어, 많은 양의 동시 요청은 서버의 능력에 과부하를 일으켜 늦거나 또는 응답 없는 요청을 초래할 수 있다.

서버에서의 네트워크 오버 헤드 및 처리 용량의 영향을 감소시키면 클라이언트의 경험 지각 품질(perceived quality of experience )을 최적화할 수 있다. 솔루션의 세 가지 범주는 서버에서의 통신 지연과 처리 용량에 대한 영향을 줄이는 것으로 알려져 있다.

먼저, 네트워크에 서비스 요청을 처리할 수 있는 다수의 서버를 배치함에 의하여, 클라이언트 요청은 예를 들어, DNS 해결사(resolver) 또는 HTTP리디렉션(redirection)과 같은 서버 선택 기능을 사용하여, 지리적 위치(즉, 클라이언트와 서버 사이의 거리를 최소화함) 또는 프로세스 부하(즉, 서버 상의 프로세스 부하를 최소화함)에 기초하여 최상의 서버로 리디렉트(redirected)될 수 있다.

US 2010/250668 에는, 앞서 기술한 솔루션의 제1범주에 속하는, 네트워크에서 클라이언트 및 서버 위치에 기초하여 클라이언트 요청을 처리할 서버를 투명하게 선택하기 위한 시스템을 개시한다. US 2010/250668 에서 서버 위치는 미리 알려져 있다. 즉, 서버의 선택 기능은 서버의 리스트로부터 최상의 서버를 선택한다. 클라이언트가 서비스 요청을 전송하면, 서버 선택 기능(즉, 요청이 서버의 호스트 네임에 기초 할 때는 DNS 해결사로 구현된)은 요청을 처리할 가장 가까운 서버의 위치를 제공할 수 있다.

대안적으로, 요청은 새로운 서버를 선택할 수 있는 서버 선택 기능을 동작시킬 수 있는 차선의 서버로 전송될 수 있다. 그리고 나서, 서버는 보다 나은 서버와 연결하기 위해 리디렉션 요청(redirection request)을 클라이언트에게 전송한다.

US 2010/250668 의 불리한 점은 일부 서버는 인접 클라이언트가 요청을 전송하는 경우 그들이 온라인으로 유지되는 동안 결코 선택될 수 없기 때문에 서버 리소스가 낭비될 수 있다는 것이다. 더욱이, 서버 기능의 일부 또는 모두를, 예를 들어, 특정 클라이언트를 위해 또는 특정 서비스 요청에 응하여, 클라이언트의 장치에 가까운 위치로 또는 클라이언트의 장치 상에 오프로드(offload) 할 메커니즘이 없다.

둘째, 프록시 서버(proxy servers)는 클라이언트와 서버 사이에, 예를 들어, 로드 밸런싱, 캐싱 및/또는 트랜스코딩을 위한 서버의 기능을 오프로드하기 위하여 배치될 수 있다. 프록시 서버는 클라이언트와 서버 사이의 중개자로서 역할을 하고, 목표 서버를 대신하여 클라이언트 요청 및 서버 응답에 대한 동작을 수행 할 수 있다. 프록시 서버(즉, 스퀴드(Squid))는, 서버들 전체에 부하를 분산하고(리디렉션에 의해), 원격 네트워크(프록시는 클라이언트 네트워크와 원격 네트워크 둘 다에 연결됨)에 액세스를 제공하며, 네트워크 부하를 감소시키고(예를 들어, 캐싱(caching), 프로토콜 변환, 및/또는 콘텐츠 압축에 의해), 서비스 요청에 대해 캐싱 기능을 수행하고, 및 서버 기능성(예를 들어, 악성 소프트웨어, 로깅, 적용 방법, 데이터 암호화, 특정 디스플레이를 위해 이미지 프리-랜더링(pre-rendering) 및/또는 웹사이트 프리-렌더링을 위한 요청을 스캔함)을 오프로드(offload)하기 위한 잘 알려진 솔루션이다.

캐싱 프록시 서버는 오로지 다수의 유사한 요청들이 고정적(즉, 시간이 지나는 동안 변화하지 않거나 천천히 변화는) 콘텐츠에 대해 이루어질 때만 성능을 개선하지만, 그러나 서버 부하를 감소시키고 네트워크 처리량을 최적화할 수 있다. 고유한 또는 캐싱에 부적합한(un-cacheable) 요청은 서버로 포워드(forwarded)되므로, 따라서 기능적으로 서버 선택 기능과 동일하게 된다. 그것이 클라이언트에게 투명(transparent)하면 클라이언트는 프록시 서버를 인식하지 못할 수 있다(즉, 클라이언트의 관점에서, 프록시는 오리지널 서버처럼 동작함). 다른 경우에, 클라이언트는 프록시 서버를 인식하고 요청을 서버 대신에 프록시 서버(즉, 인터넷에 액세스를 제공하는 프록시 서버)로 전송한다.

세째로, 서버는 서버 애플리케이션의 일부분들이 클라이언트 상에서 국부적으로(locally) 수행되는 그러한 방법으로, 예를 들어, 웹 브라우저에서 스크립트 또는 클라이언트의 장치 상에서 프로그램을 실행할 수 있다. 서버에 의하여 제공되는 기능의 일부 또는 모두는, 예를 들어, 웹 브라우저에서 폼 타당성을 위한 클라이언트 측 스크립트, 서버로부터 다운로드된 자바 웹 스타트 애플리케이션 또는 원격 서버 또는 애플리케이션 장터로부터 다운로드된 네이티브 애플리케이션으로서 클라이언트에 오프로드될 수 있다. 클라이언트 측 스크립팅(즉, 자바스크립트, 플래쉬, 실버라이트)은 웹 브라우저에 공통이고 제한이 따른다. 예를 들어, 클라이언트 측 프로그램은 오로지 브라우저가 이용 가능하고 동작할 때만 또는 사용자가 웹사이트를 방문함으로써 실행을 시작하게 할 때 실행될 수 있다. 웹 브라우저에 로드된 코드로 인해 장시간 지속되는 세션을, 예를 들어, 브라우저 외부에 생성할 수 없다. 예를 들어, 서버가 사용하기를 원하거나 혹은 최적화하기를 원하는 특정 능력(예를 들어, 클라이언트에 카메라 같은 주변 장치를 사용하거나 또는 클라이언트 장치의 그래픽 프로세서를 사용하여 GUI 속도를 높이기 위한 프로그램)을 클라이언트 장치가 가질 때, 클라이언트 또는 서버는 서버 기능의 다운로딩을 시작할 수 있다. 클라이언트는 전형적으로 리소스 소비의 양에 대해 제어를 할 수 없다(즉, 클라이언트는 특정 서버의 자바 애플릿 또는 플래시 코드가 얼마나 많은 처리능력 또는 메모리를 사용하는지 제한 할 수 없다). 또한, 클라이언트 스크립트 실행의 위치는 클라이언트 컴퓨터와 관련된다(tied). 두 단점은 프로세서와 메모리에 낮은 인식 성능을 초래하는(즉, 증가한 응답 시간 및, 사용자 인터페이스의 정지) 클라이언트 컴퓨터의 과부하를 초래할 수 있다.

근접한 네트워크 노드(예를 들면, 클라이언트에게 오프로드 되는 제1 범주의 선택된 서버, 제2 범주의 프록시 서버 또는 서버 애플리케이션의 일부)가 서비스 요청 또는 서비스 요청의 일부를 처리하기 때문에 알려진 솔루션들은 통신 지연을 감소하거나 또는 클라이언트-서버 간 인터액션(interaction)의 횟수를 줄일 수 있다. 또한, 클라이언트와 서버는 커뮤니케이션 양을 감소시키고, 커뮤니케이션 인터액션의 횟수를 감소시키며 및/또는 서버 애플리케이션의 일부를 클라이언트에게 재할당시킴에 의하여 그들의 리소스 사용 효율(예를 들어, 무선 액세스 포인트에 대한 통신을 감소시킴에 의해 클라이언트 장치의 배터리 수명을 증가시킴)을 증가시킬 수 있다.

전술한 솔루션의 일반적인 단점은 리소스가 서비스 프로바이더(provider)의 통제 및 책임 하에 있다는 점이다. 예를 들어, 서비스 프로바이더는 지리적으로 분산된 클라이언트에게 동일한 인식 성능을 제공하기 위해 다수의 중간 서버를 제공할 필요가 있을 것이다. 또한 서버 프로바이더는 리소스 소유권과 서비스 요청을 처리하기 위한 관련된 비용을 취할 수 있다. 클라이언트 프로세싱의 문제점은 클라이언트 리소스가 제한될 수 있고, 소프트웨어 종속성(dependency)을 도입할 수 있다는 것이다. 결과는 클라이언트가 소프트웨어 종속성(즉, 웹 브라우저, 플러그-인, 플랫폼) 및 그것과 관련된 이슈(즉, 보안, 버전닝(versioning))를 관리할 필요가 있다는 것이다. 또한, 클라이언트 프로세싱은 클라이언트 장치를 느리게 하거나 배터리를 소모하거나 서비스를 제공하기에 불충분 할 수 있다.

본 발명이 해결하려는 과제는 네트워크 노드 기능을 실행하기 위한 제1 네트워크 노드에 이용 가능한 네트워크 노드 리소스를 보다 효율적으로 사용할 수 있게 하는 솔루션을 제공하는 것이 본 발명의 목적이다.

본 발명 과제의 해결 수단은 네트워크 노드 기능을 제공하기 위한 네트워크 노드 사이에 리소스를 할당하는 방법에 있어서, 방법은 제1 네트워크 노드(1)로부터 제2 네트워크 노드(2)로 리소스 가용성 데이터를 전송하는 단계, 여기서 리소스 가용성 데이터는 제1 네트워크 노드(1)에 이용할 수 있는 하나 이상 네트워크 노드 리소스(3)에 관한 정보를 포함하되, 상기 네트워크 노드 리소스(3)는 제2 네트워크 노드(2)에 대해 원격으로 존재하며; 네트워크 노드 리소스(3)가 결정 결과를 얻기 위하여 네트워크 노드 기능을 제공할 수 있는지를 결정하는 리소스 가용성 데이터를 분석하는 단계; 결정 결과에 의존하여, 네트워크 노드 기능을 제공하는 하나 이상의 네트워크 노드 리소스(3)를 할당하는(103, 104) 단계; 제1 네트워크 노드(1)로부터 제2 네트워크 노드(2)로 요청 데이터를 전송하는(101b) 단계, 여기서 요청 데이터는 네트워크 노드 기능을 사용하기 위한 요청을 포함하고; 요청 데이터를 인터셉팅(intercepting)하는(105) 단계; 및 제1 네트워크 노드(1)에 네트워크 노드 기능을 제공하기 위해 할당된 네트워크 노드 리소스(3)로 요청 데이터를 리디렉팅하는(106) 단계를 포함하는 네트워크 노드 기능을 제공하기 위한 네트워크 노드 사이에 리소스를 할당하는 방법을 제공하는데 있다.

본 발명의 또 다른 과제의 해결 수단은 네트워크 노드 기능에 액세스하기 위한 제2 네트워크 노드(2)에 통신적으로 연결될 수 있는 제1 네트워크 노드(1)에 있어서, 상기 제1 네트워크 노드(1)는: 제2 네트워크 노드(2)에 리소스 가용성 데이터를 전송하며(101a), 여기서 리소스 가용성 데이터는 제1 네트워크 노드(1)에 이용 가능한 하나 이상의 네트워크 노드 리소스(3)에 관한 정보를 포함하고; 제1 네트워크 노드(1)에서 네트워크 노드 리소스(3)을 할당하기 위하여 제2 네트워크 노드(2)로부터 하나 이상의 리소스 할당 지시를 수신하며; 제2 네트워크 노드(2)에 요청 데이터를 전송하며(101b), 여기서 요청 데이터는 네트워크 노드 기능을 사용하기 위한 요청을 포함하고; 상기 요청 데이터를 인터셉터하며(105); 및 네트워크 노드 기능을 제공하기 위한 할당된 네트워크 노드 리소스(3)로 요청 데이터를 리디랙트 하도록 구성된 제1 네트워크 노드를 제공하는데 있다.

본 발명은 네트워크 노드 기능을 실행하기 위한 제1 네트워크 노드에 이용 가능한 네트워크 노드 리소스를 보다 효율적으로 사용할 수 있게 하는 솔루션을 제공할 수 있는 유리한 효과가 있다.

도 1은 본 발명의 바람직한 실시 예의 흐름도이다;
도 2과 도 3 은 본 발명의 바람직한 실시 예의 시스템 아키텍처이다;
도 4 는 본 발명의 바람직한 실시 예의 타임-시퀀스 다이애그램이다.

네트워크 노드 기능을 실행하기 위한 제1 네트워크 노드에 이용 가능한 네트워크 노드 리소스를 보다 효율적으로 사용할 수 있게 하는 솔루션을 제공하는 것이 본 발명의 목적이다.

발명의 일측 면에 따르면 네트워크 노드 기능을 제공하기 위해 네트워크 노드 사이에 리소스를 할당하는 방법이 제안되어 있다. 상기 방법은 제1 네트워크 노드에서 제2 네트워크 노드로 리소스 가용성 데이터(resource availability data)를 전송하는 단계를 포함한다. 리소스 가용성 데이터는 제1 네트워크 노드에서 이용 가능한 하나 이상의 네트워크 노드 리소스에 관한 정보를 포함할 수 있다. 네트워크 노드 리소스는 제2 네트워크 노드에 대해 원격으로 존재할 수 있다. 방법은 네트워크 노드 리소스가 결정 결과를 얻기 위하여 네트워크 노드 기능을 제공할 수 있는지 여부를 결정하기 위한 리소스 가용성 데이터를 분석하는 단계를 더 포함한다. 상기 방법은 결정 결과에 의존하는 단계와, 네트워크 노드 기능을 제공하기 위한 하나 이상의 네트워크 노드 리소스를 할당하는 단계를 더 포함한다. 방법은 제1 네트워크 노드에서 제2 네트워크 노드로 요청 데이터를 전송하는 단계를 더 포함할 수 있다. 요청 데이터는 네트워크 노드 기능을 사용하기 위한 요청을 포함할 수 있다. 상기 방법은 요청 데이터를 인터셉터(intercept)하는 단계를 더 포함할 수 있다. 상기 방법은 네트워크 노드 기능을 제1 네트워크 노드로 제공하기 위하여 할당된 네트워크 노드 리소스로 요청 데이터를 리디렉트하는 단계를 더 포함할 수 있다.

제1 및 제2 네트워크 노드의 예는 클라이언트 장치(예를 들어, PC, 노트북, 테블릿, 스마트 폰 또는 임의의 다른 클라이언트 장치), 서버(예를 들어, 애플리케이션 서버), 프록시 서버, 클라우드 위치 또는 라우터이다. 네트워크 노드 기능의 예는 애플리케이션(의 일부) 또는 네트워크이다. 애플리케이션 서비스는, 예를 들어, 웹 서버, HTTP 프록시, 데이터베이스, 웹 서비스(즉, 레스트(REST), ?(SOAP), 데이터 저장, 또는 콘텐츠 캐쉬(즉, CDN 서비스)이다. 네트워크 서비스의 예는 인터넷 게이트웨이, DHCP 서버, 방화벽, 네트워크 요소 기능(즉, HSS, MME, PDN-GW), 네트워크 제어/시그널 기능(즉, IMS 제어 기능, 패킷 포워딩, 경로 연산), 및 프로토콜 구현(OSPF, BGP, IPv4, IPv6)이다.

제1 네트워크 노드는 제 2 네트워크 노드가 네트워크 노드 기능을 오프로드하기 위하여 사용할 수 있도록 제1 네트워크 노드에 이용 가능한 리소스를 광고할 수 있다. 이것은 제1 네트워크 노드에 대해 투명하게(transparently) 행할 수 있다. 이용 가능한 리소스는 제1 네트워크 노드에 위치할 수 있거나 제1 네트워크 노드에 대해 원격인 다른 네트워크 노드에 위치할 수 있다.

이용 가능한 네트워크 노드 리소스는: 이용 가능한 CPU 로드; 이용 가능한 메모리; 이용 가능한 디스크 공간; 이용 가능한 네트워크 대역폭; 가상 기계를 로드하고 실행하는 능력(capability); 특정 OS, CPU 지시 세트 또는 스크립트 엔진을 위해 설계된 애플리케이션을 실행하는 능력; 리소스 프로바이더 기능에 대한 참조; 및/또는 임의의 다른 리소스와 관련된 정보의 관점에서 정의될 수 있다.

예를 들어, 서버는 이용 가능한 리소스의 클라이언트 장치로부터의 표시에 기초하여 클라이언트 장치에 대한 서비스(즉, 네드워크 노드 기능)의 일부를 오프로드할 수 있거나 이용 가능한 클라이언트 리소스에 대해 집중적인 특정 클라이언트에 한정된(client-specific) 프로세싱을 오프로드 할 수 있다.

따라서 본 발명은 예를 들어, 서비스 프로바이더로 하여금 서버 기능을 클라이언트 리소스에 대해 오프로드할 수 있는지 결정할 수 있게 하고, 클라이언트 장치(device)의 중재 없이 클라이언트 장치에 이용 가능한 리소스 상에 서버 기능을 할당하고 로드(load) 할 수 있다. 본 발명은 통신 지연과 프로세싱 지연(즉, 클라이언트 장치에 또는 클라이언트 장치의 로컬 영역 네트워크에 위치할 수 있는, 클라이언트 장치에 이용 가능한 리소스를 사용함에 의하여)의 감소를 허용한다. 또한 본 발명은 예를 들어, 서비스 프로바이더로 하여금 특정 클라이언트에 한정된(client-specific) 업무량과 과제를 처리하도록 클라이언트(제3자에 의하여 제공될 수 있는)에게 이용 가능한 리소스를 사용하게 할 수 있다.

따라서, 네트워크 노드 기능을 실행하기 위한 보다 효과적인 네트워크 노드 리소스의 사용을 가능하게 하는 솔루션이 제공된다.

실시 예에서, 요청 데이터는 리소스 가용성 데이터를 포함할 수 있다.

리소스 가용성 데이터와 요청 데이터는 단일 메시지로 제1 네트워크 노드에서 제2 네트워크 노드로 전송될 수 있다.

실시 예에서 리소스 가용성 데이터의 전송 단계는 제1 네트워크 노드로부터 리소스 가용성 데이터를 방송하는(broadcasting) 단계를 포함할 수 있다.

이것은 리소스 가용성 데이터를 서버로 전송하는 것에 대한 대안으로서 클라이언트 장치가 그들의 이용 가능한 네트워크 노드 리소스를 방송하는 것을 가능하게 한다. 이것은 방송 채널에 네트워크 트래픽을 오프로딩함으로써 네트워크 부하를 줄일 수 있다.

실시 예에서 제1 네트워크 노드는 네트워크 노드 리소스를 포함할 수 있다. 이것은 네트워크 노드 리소스가 네트워크 노드 기능을 할당하기 위해 사용되는 제1 네트워크 노드에 로컬(local)을 가능하게 한다.

실시 예에서 리소스 가용성 데이터는 제1 네트워크 노드에 위치한 리소스 프로바이더(provider) 기능의 표시를 포함할 수 있다. 네트워크 노드 리소스를 할당하는 단계는 제1 네트워크 노드에서 네트워크 노드 리소스를 할당하기 위한 리소스 프로바이더 기능에 하나 이상의 리소스 할당 지시를 전송하는 단계를 포함할 수 있다.

이것은 네트워크 노드 기능을 실행하기 위한 네트워크 노드 리소스를 할당하기 위한 제1 네트워크 노드에서 특정화된 기능(즉, 리소스 프로바이더 기능)의 이용을 가능하게 한다.

실시 예에서 제3 네트워크 노드는 네트워크 노드 리소스를 포함할 수 있다. 제3 네트워크 노드는 제1 네트워크 노드와 통신적으로 연결될 수 있다.

이것은 네트워크 노드 기능을 할당하기 위해 사용되는 제1 네트워크 노드에 원격으로 네트워크 노드 리소스를 작동할 수 있다. 원격 네트워크 노드 리소스는 사용을 위해 제1 네트워크 노드를 이용할 수 있다.

실시 예에서 리소스 가용성 데이터는 제3 네트워크 노드에 위치한 리소스 프로바이더 기능의 표시를 포함할 수 있다. 네트워크 노드 리소스를 할당하는 단계는 제3 네트워크 노드에서 네트워크 노드 리소스를 할당하기 위하여 리소스 프로바이더 기능에 하나 이상 리소스 할당 지시를 전송하는 단계를 포함할 수 있다.

이것은 네트워크 노드 기능에 네트워크 노드 리소스를 할당하기 위한 제3 네트워크 노드에서 특정화된 기능(즉, 리소스 프로바이더 기능)의 이용을 가능하게 한다.

실시 예에서 하나 이상의 리소스 할당 지시는 할당된 네트워크 노드 리소스에서 네트워크 노드 기능을 다운로드하기 위한 지시를 포함할 수 있다.

이것은 네트워크 노드 기능이 네트워크 노드 리소스에서 이용할 수 없을 경우에 네트워크 노드 기능의 데이터 이미지가 네트워크 노드 리소스에서 로드되게 한다.

실시 예에서 요청 데이터는 제1 네트워크 노드 또는 제1 네트워크 노드와 제2 네트워크 노드 사이의 제4 네트워크 노드 중재 중의 하나에서 인터셉터(intercepted)될 수 있다.

이것은 네트워크 노드 기능에 액세스하기 위한 제2 네트워크 노드로 전송되는 요청 데이터를 인터셉터하는 다른 구현을 가능하게 한다. 인터셉터한 요청 데이터는 이어서 리디렉트될 수 있다.

실시 예에서 리소스 가용성 데이터는 둘 이상의 다른 네트워크 노드에서 이용 가능한 네트워크 노드 리소스에 관한 정보를 포함할 수 있다. 방법은 하나 또는 둘 이상의 또는 더 많은 다른 네트워크 노드에서 네트워크 노드 리소스를 할당하기 위한 하나 또는 둘 이상의 또는 더 많은 다른 네트워크 노드를 선택하는 단계를 더 포함할 수 있다.

이것은 다른 위치에서 하나 또는 그 이상의 네트워크 노드 리소스의 선택을 가능하게 한다.

실시 예에서 방법은 제1 네트워크 노드에 이용 가능한 네트워크 노드 리소스에서의 변화를 반영하기 위하여 리소스 가용성 데이터를 업데이트 하는 단계와 제1 네트워크 노드로부터 제2 네트워크 노드로 업데이트된 리소스 가용성 데이터를 전송하는(transmitting) 단계를 더 포함할 수 있다.

이것은 필요하다면 다른 네트워크 노드 리소스로 네트워크 노드 기능의 재배치를 가능하게 한다.

본 발명의 일 측면에 따르면, 제1 네트워크 노드는 네트워크 노드 기능에 액세스 하기 위하여 제2 네트워크 노드와 통신적으로 연결할 수 있도록 제공된다. 제1 네트워크 노드는 제2 네트워크 노드로 리소스 가용성 데이터를 전송하도록 구성될 수 있다. 리소스 가용성 데이터는 제1 네트워크 노드에 이용 가능한 하나 이상의 네트워크 노드 리소스에 관한 정보를 포함할 수 있다. 제1 네트워크 노드는 제1 네트워크 노드에서 네트워크 노드 리소스를 할당하기 위한 제2 네트워크 노드로부터 하나 이상 리소스 할당 지시를 수신하도록 더 구성될 수 있다. 제1 네트워크 노드는 제2 네트워크 노드에 요청 데이터를 전송하도록 더 구성될 수 있다. 요청 데이터는 네트워크 노드 기능을 사용하기 위한 요청을 포함할 수 있다. 제1 네트워크 노드는 요청 데이터를 인터셉터하도록 더 구성할 수 있다. 제1 네트워크 노드는 네트워크 노드 기능을 제공하기 위한 할당된 네트워크 노드 리소스에 요청 데이터를 재 전송하도록 더 구성될 수 있다.

실시 예에서 하나 이상의 리소스 할당 지시(instructions)는 할당된 네트워크 노드 리소스에서 네트워크 노드 기능을 다운로드하기 위한 지시를 포함할 수 있다. 제1 네트워크 노드는 할당된 네트워크 노드 리소스에서 네트워크 노드 기능을 다운로드 하도록 더 구성될 수 있다.

실시 예에서 제1 네트워크 노드는 클라이언트 장치이다.

실시 예에서 제1 네트워크 노드는 이동(mobile) 통신 장치이다.

이 후, 발명의 실시 예는 더 구체적으로 기술될 것이다. 그러나, 이러한 실시 예들은 본 발명의 보호 범위를 제한하는 것으로 해석되지는 않는 것으로 이해해야 한다.

본 발명의 측면들은 도면에 도시된 바람직한 실시 예를 참조하여 보다 자세하게 기술될 것이다.

충분한 리소스 용량(capacity)이 클라이언트에게 이용 가능하다 할지라도, 알려진 서버는 일반적으로 서버에 의하여 제공되는 리소스 또는 서버 애플리케이션의 일부분들에 의하여 사용되는 클라이언트 장치 상의 리소스를 제외하고는 이용 가능한 리소스를 클라이언트 장치에 사용할 수 없다. 사용 가능하지만 사용되지 않을 리소스 용량의 예는 예를 들면, 클라우드 서비스(즉, 구글 AppEngine, Amazon EC2)에 대한 가입 형태의 리소스와 네트워크 오퍼레이터가 클라이언트 장치 및/또는 클라이언트 장치에 가까운 장치(즉, 광대역 라우터, 셋톱 박스, 미디어 센터 또는 임의의 다른 컴퓨터)에 사용할 수 있는 리소스들이다. 클라이언트의 컴퓨팅 리소스가, 예를 들어 불충분할 때, 알려진 서버는 예를 들어, 클라이언트 장치에 리소스를 공급할 수 있는 제3자에게 도움을 청할 수 없다.

대조적으로, 본 발명은 제1 네트워크 노드, 예를 들어, 클라이언트 장치(즉, PC, 노트북, 테블릿, 스마트 폰 또는 임의의 다른 클라이언트 장치), 서버(즉, 애플리케이션 서버), 프록시 서버, 클라우드 위치 또는 라우터는 애플리케이션 서버, 클라우드 위치 또는 다른 라우터와 같은 제2네트워크 노드가 네트워크 노드 기능을 오프로드 하기 위해 사용할 수 있는 이용 가능한 리소스를 투명하게(transparently) 제1 네트워크 노드로 광고할 수 있는 방법을 제공한다.

네트워크 노드 기능의 예는 애플리케이션(의 일부분들) 또는 네트워크 서비스이다.

애플리케이션 서비스는, 예를 들면, 웹서버, HTTP 프록시, 데이터베이스, 웹 서비스(즉, 레스트(REST), ?(SOAP)), 데이터 저장, 콘텐츠 캐쉬(즉, CDN 서비스)이다. 네트워크 서비스의 예는 인터넷 게이트웨이, DHCP 서버, 방화벽, 네트워크 요소 기능(즉, HSS, MME, PDN-GW), 네트워크 제어/시그널 기능(즉, IMS 제어 기능, 패킷 포워딩, 경로 연산), 및 프로토콜 구현(OSPF, BGP, IPv4, IPv6) 이다.

이용 가능한 리소스는 이용 가능한 CPU 로드, 이용 가능한 메모리, 이용 가능한 디스크 공간, 이용 가능한 네트워크 대역폭, 가상 머신(virtual machine)을 로드하고 실행하기 위한 용량, 특정 OS로 설계된 애플리케이션을 실행하기 위한 용량, 특정 CPU 지시 세트로 설계된 애플리케이션을 실행하기 위한 용량, 리소스 프로바이더 기능에 대한 참조(reference), 및/또는 임의의 다른 리소스 관련 정보로 정의될 수 있다.

예를 들어, 서버는 이용 가능한 리소스의 클라이언트 장치로부터의 표시에 기초하여 클라이언트 장치에 대해 서비스의 일부(즉, 네트워크 노드 기능의 예)를 오프로드할 수 있거나 또는 이용 가능한 클라이언트 리소스에 대해 집중적인 특정 클라이언트에 한정된 프로세싱을 오프로드할 수 있다. 따라서 본 발명은 서비스 프로바이더로 하여금 서버 기능이 클라이언트 리소스에 대해 오프로드 될 수 있는지를 결정할 수 있게 하고 클라이언트 장치의 중재 없이 서버 기능을 할당 및 로드하게 할 수 있다. 본 발명은 (예를 들면, 클라이언트 장치 또는 클라이언트 장치의 로컬 영역 네트워크에 위치될 수 있는 클라이언트 장치에 이용 가능한 리소스를 사용함에 의해) 통신 지연의 감소를 허용한다. 또한 본 발명은 서비스 프로바이더가 특정 클라이언트에 한정된(client-specific) 워크로드 및 업무를 처리하기 위해 이용 가능한 클라이언트 리소스를 사용하게 한다.

도 1은 본 발명의 바람직한 실시 예의 흐름도를 나타낸다. 제 1 네트워크 노드로부터 제2 네트워크 노드로 전송되는 리소스 가용성 데이터에 광고된 대로, 제2 네트워크 노드, 즉 서버가 제1 네트워크 노드, 즉 클라이언트 장치에 이용 가능한 네트워크 노드 리소스에 투명하게(transparently) 액세스할 수 있게 하는 방법을 제공한다. 리소스 가용성 데이터는 제2 네트워크 노드에서 네트워크 노드 기능을 액세스하도록 제1 네트워크 노드로부터의 요청을 포함할 수 있다. 요청은 서버에서 서비스를 액세스하기 위한 서비스 요청이다. 다른 방법은 예를 들면, 아마도 정기적인 시간 간격으로 리소스 가용성 데이터를 방송하는, 제2 네트워크 노드에 리소스 가용성 데이터를 전송하는데 이용될 수 있다. 제2 네트워크 노드는 알려진 네트워크 위치로부터 이용 가능한 데이터를 검색 또는 수신하도록 구성될 수 있다.

도1을 참고하면, 다음의 비-제한적인 예에서 제1 네트워크 노드는 클라이언트 장치이고 제2 네트워크 노드는 서버이다. 클라이언트 장치는 그것이 공유할 수 있는 리소스에 대한 정보를 광고(101a) 할 수 있다. 클라이언트 장치는 리소스 가용성 데이터를 서버로 전송할(101a) 수 있다. 서버는 표시된 리소스를 사용할 수 있는지를 결정하기 위하여 리소스 가용성 데이터를 분석할(102) 수 있다. 서버가 표시된 리소스를 사용할 수 없다면, 정보는 폐기되고(107) 표시된 리소스는 서버에 의하여 사용되지 않을 것이다. 서버가 표시된 리소스를 사용할 수 있다면, 서버는 네트워크 노드 리소스에 서버 기능을 오프로드 하도록 네트워크 노드 리소스의 할당을 요청하기 위해(103) 그 정보를 사용할 수 있다. 서버는, 아마 후술될 리소스 프로바이더 기능의 중재(intermediary)를 통해, 관련 데이터 구조(예를 들어, DNS 구조를 업데이트 함에 의하여)를 업데이트하는 리디렉션 기능을 요청할(104) 수 있을 것이다. 결과적으로, 서버 기능에 액세스하기 위해 서버로 전송된(101b) 후속 클라이언트 요청 데이터는 인터셉트될(105) 수 있고 오프로드된 서버 기능으로 리디렉트(106)될 수 있다. 유리하게는 서버는 서비스 전달을 최적화하기 위해 클라이언트에 이용 가능한 리소스를 투명하게(즉, 클라이언트의 개입 없이) 사용할 수 있으며, 결과로, 예를 들어, 통신 지연을 감소시키고 클라이언트 장치의 배터리 수명을 증가시키며 및/또는 애플리케이션 프로세싱을 위한 성능 증가를 초래한다. 리소스는 클라이언트 장치의 일부이거나 또는 대안으로 리소스는 클라이언트 장치에 이용 가능한 리소스를 가진 제3자 리소스 프로바이더에 의해 공급될 수 있다. 제3자에서 리소스를 사용할 때, 리소스 사용은 제3자에 의해 클라이언트 장치의 사용자에게 요금이 부가 및/또는 청구될 수 있다.

도1 의 기능성을 제공하는 시스템은 제1 네트워크 노드, 제2 네트워크 노드 및 네트워크 노드 리소스 외에도 다음의 기능성 구성요소(components)를 포함할 수 있다. 리소스 공급 기능(RPF)은 클라이언트 장치(또는 더 일반적으로 제1 네트워크 노드에)에 이용 가능한 네트워크 노드 리소스를 할당하고 네트워크 노드 리소스 상에 하나 이상의 오프로드된 서버 기능(또는 더 일반적으로 오프로드된 제2 네트워크 노드 기능)을 로드하기 위한 인터페이스를 제공할 수 있다. 리소스 공급 기능(RPF)은 클라이언트 장치의 일부 또는 이용 가능한 리소스가 제3 네트워크 노드에 위치될 경우에 제3자의 제3 네트워크 노드의 일부일 수 있다. 리디렉션(redirection) 기능은 그렇지 않으면 요청을 처리할 서버(또는 더 일반적으로 제2 네트워크 노드) 대신에 오프로드된 서버 기능으로 특정 클라이언트 요청들(또는 더 일반적으로 제1 네트워크 노드로부터의 요청)을 인터셉트하고 리디렉트 할 수 있다. 오프로드된 서버 기능(OSF)은 서버의 기능성(의 일부)을 제공할 수 있고 할당된 네트워크 노드 리소스 상에 로드될 수 있다. OSF 결정 기능은 클라이언트 리소스가 서버 기능을 오프로드 하는데 사용될 수 있는지를 결정하기 위하여 선택적으로 사용될 수 있다. 서버가 이러한 결정을 하는 경우 OSF 결정 기능은 서버의 일부일 수 있다. 다수의 클라이언트 리소스의 선택(예를 들어, 리소스 프로바이더의 리스트 또는 리소스 구성(configurations)에서의 선택)에 선택(choice)이 있는 경우, 리소스 선택 기능(RSF)은 사용할 최상의 리소스를 선택하도록 사용될 수 있다. RSF는 제2 네트워크 노드의 일부 일 수 있다.

기능성 구성요소(components)는 컴퓨터 프로그램 제품으로 구현될 수 있다.

도 2와 도 3은 도 1과 함께 기술된 기능성을 구현할 수 있는 시스템의 바람직한 실시 예를 보여준다. 시스템의 요소(Elements)는 박스로 표시된다. 화살표는 시스템의 요소들 사이의 정보 및 데이터 교환 또는 요소에서 또는 요소들 사이 에서 정보/데이터의 프로세싱을 표시한다. 도 2의 예에서 RPF(4)는 클라이언트 장치(1)(즉, 클라이언트 장치 상에서))에 대해 로컬이다. 도 3의 예에서 클라이언트 장치(1)는 하나 이상의 제3자 리소스 프로바이더(5)(즉,클라우드 컴퓨팅 프로바이더, ISP의 컴퓨팅 시설, 세톱 박스 또는 네트워크 액세스 라우터)에게 광고한다. 도 2와 도 3의 예는 제1 네트워크 노드(1)로서의 클라이언트 장치와 제2 노드(2)로서의 서버를 나타내지만, 그러나 앞서 기술한 바와 같이 임의의 제1 네트워크 노드(1)와 제2 네트워크 노드(2)에 적용 가능한 것으로 이해되어야 한다.

도 2의 예에서 클라이언트 장치(1)에서 클라이언트 애플리케이션(9) (예를 들어, 웹 브라우저 또는 다른 임의의 애플리케이션)은, 아마도 요청을 단순히 서버(2)로 포워드(forward)할 수 있는 리디렉션 기능(6)의 중재를 통해, 서버(2)의 서버 애플리케이션으로 요청을 전송한다(101a). 요청은 전형적으로 리소스 가용성 데이터 및 선택적으로 URL, 동작 파라미터, 설정, 크래덴셜, 토큰 및 클라이언트 장치(1)에서의 하나 이상의 RPFs(4)의 암호화 키 같은 정보의 광고(advertisement)를 포함한다. 정보 광고(advertisement)는 선택적으로 서버(2) 외부의 OSF 결정 기능(8)을 통해 및/또는 리소스 가용성 데이터로부터 분리되는 것과 같은 다른 경로를 통해 서버(2)로 선택적으로 전송될 수 있다. 서버(2) 외부의 OSF 결정 기능, 서버(2)의 OSF 결정 기능 또는 서버(2)가 OSF에 대해 네트워크 노드 리소스(3)을 할당하기(104a) 위한 결정(102)을 하고, OSF는 네트워크 노드 리소스(3)에서 이용할 수 있으면, 리디렉션(redirection) 기능(6)은 서비스 요청 데이터(101b)를 인터셉트하고(105) OSF(3)로 리디렉트 하도록(106) 구성될 수 있다(104b). 그렇지 않으면, 서비스 요청 데이터는 서버(2)의 서버 애플리케이션에 도착한다. 클라이언트 장치(1)에 의한 하나의 RPF(4)의 광고의 가능한 구현은 서버 애플리케이션으로 전송된 HTTP 요청에 광고를 내장함에 의한다.

서버(2)에서 서버 애플리케이션은 광고에서 정보를 사용할 수 있고 서버(2)의 외부나 또는 내부의 OSF 결정 기능에 정보를 제출할 수 있다. 선택적으로, 다수의 네트워크 노드 리소스로부터 선택이 이루어지는 경우, 정보는 OSF를 생성할지를 결정하고, OSF를 위한 최적의 위치를 선택하고, 어느 RP(4)를 선택할지를 결정하는 RSF(7) 로 전송될(107) 수 있다. OSF 결정 기능(8)과 RSF(7) 둘 다 리소스 가용성 데이터와 선택적으로 OSF의 리소스 요구 사항에 대해 광고에서 보내는 정보를 비교할 수 있다. 예를 들어, RP 선택 기능(7)은 RPF(4)에 의하여 할당될(104A) 네트워크 노드 리소스(3)가 사용할 수 있는 충분한 처리 능력을 가지는 경우에 생성된 OSF를 가지도록 결정할 수 있다. 분석 (102)의 결과가 이용 가능한 네트워크 노드 리소스(3)에서 OSF를 생성할 결정을 하는 경우, 서버(2)는 선택된 RPF(4)에 생성 OSF 요청 데이터를 전송한다(103). 요청 데이터는 HTTP 요청 또는 임의의 다른 방식으로 내장된 RP(4)로 서버(2)에 의해 전송될(103) 수 있다. 요청 데이터에서의 정보는 요청된 동작(예를 들면, OSF를 생성하는)과 선택적으로 네트워크 노드 리소스(3)로 다운로드되는 OSF의 이미지(참조) 같은 동작 파라미터를 포함할 수 있다.

RPF(4)는 서버(2)로부터 수신된(103) 생성 OSF 요청 데이터를 처리할 수 있고 OSF 의 생성을 위한 네트워크 노드 리소스를 할당할(104a) 수 있다. RPF(4)는 전형적으로 또한 리디렉션 기능(6)을 공급한다. 리디렉션 기능(6)은 클라이언트 장치(1)로부터 네트워크 노드 리소스(3)에서 실행하는 OSF로 요청(101b)을 리디렉트(105) 하는 수단이다.

리디렉션 기능(6)의 공급 단계(104b)는 할당된 네트워크 노드 리소스(3)에서 OSF 에 대한 서비스 요청(101b) 을 인터셉트하고(105) 리디렉트(106) 하기 위하여 클라이언트 장치(1)를 구성하는 단계(예를 들어, 로컬DNS 정보를 업데이트하고, 프록시 서비스 구성하며, 라우팅 테이블을 변경하고, 방화벽을 구성하고, 웹 브라우저 플러그인의 구성을 변경하며, 클라이언트 애플리케이션(9)의 구성을 변경함에 의하여)를 포함할 수 있다. 서비스 요청(101b)이 리소스 가용성 데이터(101a)에 포함되어 있으면, 서버(2)는 OSF로 서비스 요청의 제1 리디렉션을 수행할 수 있다(예를 들어, HTTP로 리디렉터).

도 3의 예에서, 도 2와 함께 설명한 바와 같은 비슷한 요소들, 정보/데이터의 교환 및 정보/데이터의 처리는 제3자(5)의 사용에 약간의 수정과 함께 도시된다. 서버(2)에서 클라이언트 장치 (1)로부터 서버 애플리케이션으로 전송된 요청(101a)은 제3자(5)에서 클라이언트 장치(1)에 이용할 수 있는 네트워크 노드 리소스(3)의 리소스 가용성 데이터를 포함하고 제3자에서 하나 이상의 RPFs(4)에 대한 정보를 가진 광고를 포함 할 수 있다. 제3자(5)의 예는 클라우드 리소스 프로바이더, 애저(Azure), 아마존, 또는 인터넷 서비스 프로바이더(ISP)이다. 광고는 리소스 가용성 데이터와 별도로 전송될 수 있고 및/또는 다른 경로를 통해(즉, 서버(2)의 외부 OSF 결정 기능(8)을 통해서) 서버(2)로 전송될 수 있다. 광고는 로컬 및/또는 제3자 RPFs(4)에 관한 데이터 목록 (예를 들어, URL, 동작 파라메터, 설정, 크래덴셜, 토큰, 암호화 키)을 포함할 수 있다. OSF가 네트워크 노드 리소스에 할당될(104a) 수 있거나 OSF가 사용 가능하고 OSF 결정 기능 (서버(2)의 내부에서든 또는 서버(2)의 외부에서든) 또는 서버(2)가 OSF를 사용할 결정을 하는 경우, 리디렉션 기능(6)은 서비스 요청(105)을 인터셉트하고 클라이언트 애플리케이션에서 OSF로 서비스 요청을 리디렉트 하도록(106) 구성될(104b) 수 있다.

서버(2)는 OSF 결정 기능(외부(8) 또는 내부의) 및 RSF(7)을 사용하여 OSF에 리소스를 할당하는 것이 더 최적인지를 결정하고 OSF를 관리(host)하기 위해 어느 리소스(3)를 사용할지(예를 들어, 어느 RPF(4)를 선택할지 선택함으로써)를 결정한다.

OSF 결정 기능과 RSF(7)에 대한 입력은 전형적으로 다음을 포함한다: 클라이언트(1)에 의해 제공되는 OSF, RPF(4)정보(URL, 액세스 크래덴셜(credential), 현재 상태, 인터페이스 프로토콜)의 리소스의 예상되는 리소스 소비 및/또는 제3자 RPFs(3)에 의해 제공되는 리소스 사용 데이터. RSF(7)은 최신의 리소스 사용 데이터(예를 들면, 연산 부하, 메모리 소비 및/또는 네트워크 지연)에 대한 공지의 RP(4)를 질의 할 수 있다. 최적의 하드웨어 리소스 위치를 선택한 후, RPF(4)는 OSF를 생성하기 위해 네트워크 노드 리소스(3)를 할당하도록 서버(2)에 의해 요청될(103) 수 있다(예를 들어, HTTP 웹 서비스 콜을 통해). OSF는 RPF(4)에 의하여 생성될 수 있다. RPF(4)는 또한 일반적으로 클라이언트 애플리케이션에서 OSF로 서비스 요청(101)을 리디렉트하기 위해 리디렉션 기능(6)을 요청한다.

도 2 및 도 3의 예에서 리디렉션 기능(6)의 위치는 변할 수 있다: 클라이언트 장치(1)에서(즉, 웹 프록시로 구현되고, 라우터에서, DNS 구성으로서 또는 웹 브라우저의 플러그인으로), 서버(2)의 위치에서(즉, HTTP 리디렉트 또는 웹 서버의 플러그인을 사용하여), 또는 클라이언트(1)와 서버(2), 예를 들어, 프록시 서버, 라우터, 딥 패킷 검사 장치 또는 DNS 서버 사이의 경로 상의 다른 네트워크 노드에서. 리디렉션 기능(6)은 다양한 프로토콜 스택(stack) 레벨에서 동작할 수 있고 네트워크 주소 변환, 네트워크 트래픽 라우팅(라우팅 테이블 구성), 네임 서비스 룩업(즉 DNS 룩업), 또는 애플리케이션-스페시픽 프록시(즉, 웹 프록시 서버)에 의해 구현될 수 있다. 리디랙션 기능(6)이 없거나 공급될 수 없는 경우에, 서비스 요청 데이터는 OSF 대신에 서버(2)에 도달한다. 리디랙션 기능(6), OSF, 및 클라이언트 장치(1)가 동일한 조직의 제어 하에 컴퓨터 네트워크에 위치할 때, 리디렉션 기능(6)은 예를 들어, 라우터의 구성, 프록시 서버, ISP 네트워크에서의 DNS구성 또는 OSF가 세톱 박스와 같은 로컬 장치에 설치된 홈 네트워크에서 홈 라우터의 구성에 의해, 동일한 컴퓨터 네트워크의 재구성 형태로, 구현될 수 있고, 그래서 클라이언트(1)로부터의 요청은 OSF로 직접 라우트(routed)될 수 있다.

클라이언트 광고로, 클라이언트 장치(1)에서 클라이언트 애플리케이션(9)은 도 4의 예에 도시된 바와 같이, 로컬 또는 제3자 리소스에 관한 정보를 업데이트 할 수 있다. 예를 들어, 서버(2)에 이용 가능한 리소스(101a)의 제1 광고에 응하여 클라이언트 장치(1)에서 RPF(4a)에 의해 클라이언트 장치(1) 상에 OSF가 처음 생성될 때, 클라이언트 장치(1)에서 RPF(4)가 네트워크 노드 리소스(3)에서 OSF의 할당을 변경할 수 있음(즉, 적은 수의 이용 가능한 CPU 코어들)에 반응하여 도 4의 제2 광고(101a)에 의해 도시된 바와 같이, 클라이언트(1)는 제2 광고(101a)에서 이용 가능한 네트워크 노드 리소스(즉 낮은 이용 가능한 CPU 코어들)에서의 변화를 서버(2)로 보고 할 수 있다. OSF가 RPF(4a)에게 리소스 소비를 변경하도록 요청하는 것은 가능하다.

클라이언트(1)는 클라이언트 광고에 로컬 및 제3자 RPFs의 목록을 제공할 수 있고 시간이 지나면 이 목록을 변경할 수 있다. 클라이언트 장치(1)에서 모든 로컬 리소스(3)가 사용 중에 있거나 RSF가 다른 리소스(3)를 사용하기로 결정할 때, 이것은 제3 광고(101a)에 의해 시작하는 도 4에서, 로컬 RPF(4a)에서 제3자 RPF(4b)로 변환을 이끌 수 있다. 클라이언트 장치(1)에서의 RPF(4a)는 이어서 OSF를 죽이고 및/또는 언로드(unload)하도록(108) 요청 될 수 있으며, RPF(4b)는 제3자에서, 예를 들어, 클라우드 위치에서 OSF를 생성하도록(104a) 요청될(103) 수 있다.

리소스에 관한 현재 상태 정보는 서버(2)가 적응하도록 허용하는 클라이언트 장치로부터 전송된(101a) 업데이트된 리소스 가용성 데이터로 서버(2)에 전달될 수 있다. 응답으로 서버(2)는 클라이언트 디바이스의 CPU가 최대 용량에 도달하고 있기 때문에 제3자 리소스에서 OSF 를 생성하도록 선택할 수 있다. 클라이언트(1)는 다른 메커니즘을 통하여 예를 들어, 방송(즉, mDNS를 사용하여) 또는 알려진 위치(즉, http://client-address/myresource)에 액세스할 수 있는 리스트를 통해서 클라이언트 리소스를 광고할(101a) 수 있다. 프록시 또는 RPF(4)는 클라이언트 장치(1)를 대신하여 리소스를 광고할(101a) 수 있다.

클라이언트 장치(1)에 이용 가능한 네트워크 노드 리소스(3)에서 완전한 서버로서 OSF를 배치할 수 있다. 이것은 서비스 프로바이더가 서버 기능성을 관리(host)하기 위해 리소스를 더 이상 제공할 필요가 없는 환경을 생성할 수 있다. 서버 기능성을 위한 모든 리소스는, 클라이언트 장치 자체의 리소스에 의해 또는 클라이언트를 대신하여 동작하는 제3자 리소스 프로바이더에 의하여, 클라이언트 장치에 의해 전달될 수 있다.

다음 예는 HTTP와 자바 웹 스타트(Java Web Start)를 사용하는 구현이다. 여기서, 클라이언트 애플리케이션(9)는 웹 브라우저 애플리케이션이다. OSF는 새로운 프로세스(네이티브 코드의)를 생성함에 의하여, 스크립트 엔진에서 스크립트를 실행함에 의하여, 하이퍼 바이저에서 새로운 가상 기계를 기동함에 의하여 구현될 수 있다. 자바 웹 스타트 애플리케이션은 클라이언트 컴퓨터(1)에서 실행하는데 사용된다. 클라이언트(1)에 의하여 서버(2)로 보내진(101a) HTTP 요청은 아래 정보를 포함할 수 있다:

GET /webapplication HTTP/1.1

Host: www.server.com

Resource-Provider: http://www.client.com

/ResourceProvider

상기 HTTP 요청은 서버 www.server.com 에서 서버 애플리케이션 '/webapplication'을 위한 요청을 포함한다. 로컬 리소스에 관한 정보는 RPF(4)는 'http://www.client.com/ResourceProvider'(즉, 클라이언트 어드레스)에서 이용할 수 있는 것으로 알려주는 HTTP 헤더 속성(attribute) '리소스 프로바이더(Resource-Provider)' 를 통해서 제공된다. 리소스 프로바이더 HTTP 헤더 속성은 HTTP 요청, 예를 들어, 속성을 요청에 삽입하는 클라이언트와 서버 사이의 경로 상에 브라우저 플러그인 또는 프록시 서버를 생성함에 의해서 부가 될 수 있다.

리디렉션 기능(6)은, 예를 들어 웹 브라우저(즉, 요청 콘텐츠를 수정하도록 허용하는 파이어폭스 확장) 또는 클라이언트 컴퓨터에 설치된 HTTP 프록시 서버 (예를 들어, 요청을 재기록하는 아파치 HTTP서버를 사용하여, 인커밍 요청을 다른 시스템으로 리디랙트 하고, 및 / 또는 포워드된 요청에 헤더를 부가함) 같은 다양한 형태로 구현될 수 있다.

RFP(4)는 웹브라우저의 동일한 플러그인 또는 리디렉션 기능을 구현하는 HTTP 프록시에서 구현될 수 있다. RFP(4)는 서버(2)에 의하여 액세스 할 수 있는 웹 서비스를 실행할 수 있다. 새로운 OSF를 생성하기 위한 RPF(4)에 대한 요청(103)은 RPF(4)에 자바 웹스타트 프로그램의 위치(즉, 일부 위치로부터 다운로드될 데이터 파일)를 제공할 수 있다. 여기에서 요청(103)은 URL 및 데이터 파일을 얻기 위한 호스트를 즉, 다음과 같이 포함할 수 있다:

/ResourceProvider?operation=create&

location=http://www.server.com/server.jnlp

HTTP/1.1

Host: www.client.com

(OSF를 생성하는) 동작 및 자바 웹스타트 프로그램의 위치 모두 RPF(4)로의 요청에 대한 아규먼트(arguments)로 통할 수 있다. 상기 RPF(4)는 상기 요청 아규먼트를 분석하고 특정 위치로부터 자바 웹 스타트 프로그램을 다운로드할 수 있으며, 그런 후 그것은 네트워크 노드 리소스(3) 상에서 시작될 수 있다. OSF에 의해 구현된 서버 기능성에 대한 요청(101b)을 새로운 OSF(즉, URL에 기초한 리디렉션 규칙(rule))로 리디렉트하기 위하여 RPF(4)는 전형적으로 리디렉션 기능(6)의 구성 (예를 들어, 웹브라우저에 플러그인 또는 클라이언드(1) 상에 HTTP 프록시)을 변경한다. 이 프로세스를 완성 한 후, RPF(4)는 OSF의 위치에 대해 서버(2)에 알리기 위해 즉, 다음 정보를 전송함에 의하여 승인(acknowledgement)을 보낼 수 있다:

HTTP/1.1 200 OK

Date: Wed, 22 Nov 2012 1 1 :31 :00 GMT

Content-Type: text/html

OSF=http://www.client.com/OSFid

이 정보로 해당 요청이 서버(2)에서 웹 애플리케이션에 액세스하기 위한 요청 데이터를 이미 포함하는 경우에, 서버(2)는 클라이언트(1)의 본래의(original) 요청에 대해 리디렉션 응답을 발생할 수 있다. 상기 리디렉션 응답은 다음 정보를 포함할 수 있다:

HTTP/1.1 301 Moved Permanently

Location: http://www.client.com/OSFid

서버(2)에서 클라이언트(1)로부터 웹 애플리케이션으로의 새로운 요청은 웹 브라우저 플러그인 또는 프록시 서버에 의해 구현된 리디렉션 기능(6)에 의하여 인터셉트(intercepted) 되고(105) 할당된 네트워크 노드 리소스(3) 상에서 실행하는 로컬 자바 웹 스타트 애플리케이션으로 리디렉트 될 수 있다. 자바 웹 스타트 애플리케이션은 웹 서버를 구현하는 자바 프로그램 일 수 있다.

다음은 클라우드 프로바이더(5)에 의해 관리(hosted) 되는 OSF의 예이다. 제3자 예를 들어, 클라우드 프로바이더(5)는 클라우드 위치(5)에서 RPF(4, 4b)에 의해 할당할 수 있는 OSF를 관리하는 클라이언트 장치(1)에 대하여 이용할 수 있는 리소스(3)를 가질 수 있다. 클라우드 프로바이더의 예는 아마존 EC2, 마이크로소프트 애저(Microsoft Azure), 구글 앱 엔진(서비스 또는 PaaS로 플랫폼을 제공하는)이다. 아마존 EC2 서비스의 경우에, 클라이언트 장치(1)의 사용자는 전형적으로 서버(2)에 아마존 서비스의 크래덴셜 액세스를 광고해야 할 필요가 있다. 아마존 EC2의 경우에, 크래덴셜은 AWS 액세스 키로 구성되고 및 EC2 인터페이스를 조회하는 데 사용된다. 이것은 서버(2) 및 필요하다면 RSF(7)에 대해 아마존 EC2 인터페이스에 액세스를 제공한다. 이 예에서 RPF(4)의 역할은 아마존 EC2 서비스에 의해 재생될 수 있다. 이러한 서비스의 인터페이스는 EC2 웹서비스에 의해 제공된다.

OSF 배치 기능(8)과 RSF(7)는 웹서버 확장으로 구현될 수 있다. 인터넷 정보 서버와 아파치 HTTP 서버와 같은 대부분의 웹 서버 구현은 인커밍 요청에 대해 부가적인 프로세싱 기능성을 부가하기 위한 확장을 허용한다. OSF 결정 기능(8)의 구현 샘플은 아래 의사 코드(pseudo code)에서 볼 수 있다.

OSF OSFDecisionFunction(

OSF osf_array[], // array of OSFs already running for client

Requirements requirements // resource requirements of the OSF

) {

// iterator over all available OSFs

foreach ( OSF osf in osf_array ) {

// if the OSF has enough free resources

if ( osf.getAvailableResources > requirements ) {

// return the reference to this OSF

return osf;

}

// no OSF was found with enough resources

// or no OSF was available at all.

return NULL;

}

상기 OSF 결정 기능(8)에 대한 입력은 이 서버(2)와 클라이언트(1)의 알려진 OSFs의 어레이 및 OSF 의 요구된 리소스를 기술하는 데이터-구조이다. 알려진 OSF는 서버 기능을 오프로드하는 서버(2)에 이용할 수 있는 네트워크 노드 리소스 상에 로드된 OSFs이다. OSFs의 목록을 되풀이하여 반복함으로써, 요구사항은 OSF 상에 이용 가능한 리소스(3)와 비교된다. 충분한 리소스를 가진 제1 OSF는 반송(returned)되고 리디렉션 기능(6)을 구성하는데(104b) 사용된다. OSF가 발견되지 않으면, NULL이 새로운 OSF를 생성하기 위한 신호로 사용될 수 있도록 리턴된다.

RSF(7)의 구현 샘플은 아래 의사 코드(pseudo code)에서 볼 수 있다.

RP RPSelectionFunction(

RP rp_array[], // array of resource providers

Requirements requirements // resource requirements of an OSF

) {

// iterator over all available RPs

foreach ( RP rp in rp_array ) {

// get accurate data on available resources at each RP

rp.updateAvailableResources();

// if the RP has enough resources

if ( rp.getAvailableResources > requirements ) {

// return the reference to this RP

return rp;

}

// no RP was found with enough resources

// or no RP was available at all.

return NULL;

}

앞서 RSF 기능(7)에 대한 입력은 알려진 RPFs(4)의 어레이 및 OSF에 대해 요구되는 리소스를 기술하는 데이터 구조이다. RPFs 의 목록을 되풀이하여 반복함으로써, 요구사항은 RPF(4)에 의해 할당할 수 있는 이용 가능한 리소스(3)와 비교된다. 이러한 예에서, 각 RPF(4)는 이용 가능한 리소스(3) 상에서 최신 데이터를 얻도록 조회된다. RPF(4)가 RPF 기능에 의하여 반송(returned)되면, 이 RPF(4)는 새로운 OSF를 생성하기 위하여 사용된다. NULL이 반송(return)되면, RPF(4)는 발견되지 않으며, 서버는 디폴트 경로에 의존하고 응답 자체를 생성하거나 또는 서버 오류 (예를 들어, HTTP503 서비스 이용 불가 상태 코드)를 생성 할 수 있다.

본 발명의 일 실시 예는 컴퓨터 시스템과 함께 사용하기 위한 프로그램 제품으로 구현될 수 있다. 프로그램 제품의 프로그램(들)은 실시 예의 기능을 정의하고(여기에 기술된 방법을 포함하여) 비-일시적 컴퓨터 판독 가능 저장 매체의 다양성에 포함될 수 있다. 예시적인 컴퓨터 판독 가능한 저장 매체는 제한 없이 (i) 정보가 영구적으로 저장되는 쓸 수 없는 저장 매체(즉, CD-ROM드라이브에 의하여 읽을 수 있는 CD-ROM 디스크와 같은 컴퓨터 내의 읽기 전용 메모리 장치, ROM 칩 또는 임의의 형태의 고체 상태의 비-휘발성 반도체 메모리); 및 (ii) 변경 가능한 정보가 저장되는 쓸 수 있는 저장 매체(즉, 플래쉬 메모리, 디스켓 드라이브 내의 플로피 디스크 또는 하드-디스크 드라이브 또는 임의의 형태의 고체 상태의 랜덤-액세스 반도체 메모리)를 포함하나, 그에 국한되지는 않는다.

Claims

네트워크 노드 기능을 제공하기 위한 네트워크 노드 사이에 리소스를 할당하는 방법에 있어서, 방법은
제1 네트워크 노드(1)로부터 제2 네트워크 노드(2)로 리소스 가용성 데이터를 전송하는 단계, 여기서 리소스 가용성 데이터는 제1 네트워크 노드(1)에 이용할 수 있는 하나 이상 네트워크 노드 리소스(3)에 관한 정보를 포함하되, 상기 네트워크 노드 리소스(3)는 제2 네트워크 노드(2)에 대해 원격으로 존재하며;
네트워크 노드 리소스(3)가 결정 결과를 얻기 위하여 네트워크 노드 기능을 제공할 수 있는지를 결정하는 리소스 가용성 데이터를 분석하는 단계;
결정 결과에 의존하여, 네트워크 노드 기능을 제공하는 하나 이상의 네트워크 노드 리소스(3)를 할당하는(103, 104) 단계;
제1 네트워크 노드(1)로부터 제2 네트워크 노드(2)로 요청 데이터를 전송하는(101b) 단계, 여기서 요청 데이터는 네트워크 노드 기능을 사용하기 위한 요청을 포함하고;
요청 데이터를 인터셉팅(intercepting)하는(105) 단계; 및
제1 네트워크 노드(1)에 네트워크 노드 기능을 제공하기 위해 할당된 네트워크 노드 리소스(3)로 요청 데이터를 리디렉팅하는(106) 단계를 포함하는 네트워크 노드 기능을 제공하기 위한 네트워크 노드 사이에 리소스를 할당하는 방법.
청구항 1에 있어서,
요청 데이터는 리소스 가용성 데이터를 포함하는 네트워크 노드 기능을 제공하기 위한 네트워크 노드 사이에 리소스를 할당하는 방법.
청구항 1에 있어서,
리소스 가용성 데이터를 전송하는(101a) 단계는 제1 네트워크 노드(1)로부터 리소스 가용성 데이터를 방송하는 단계를 포함하는 네트워크 노드 기능을 제공하기 위한 네트워크 노드 사이에 리소스를 할당하는 방법.
청구항 1 내지 청구항 3 중 어느 한 항에 있어서,
제1 네트워크 노드(1)는 네트워크 노드 리소스(3)를 포함하는 네트워크 노드 기능을 제공하기 위한 네트워크 노드 사이에 리소스를 할당하는 방법.
청구항 4에 있어서,
리소스 가용성 데이터는 제1 네트워크 노드(1)에 위치한 리소스 프로바이더 기능(4)의 표시를 포함하며, 여기서 네트워크 노드 리소스(3)를 할당하는(103, 104) 단계는 제1 네트워크 노드(1)에서 네트워크 노드 리소스(3)를 할당하기 위해 리소스 프로바이더 기능(4)에 하나 이상 리소스 할당 지시를 전송하는(103) 단계를 포함하는 네트워크 노드 기능을 제공하기 위한 네트워크 노드 사이에 리소스를 할당하는 방법.
청구항 1 내지 청구항 3 중 어느 한 항에 있어서,
제3 네트워크 노드(5)는 네트워크 노드 리소스(3)를 포함하며, 여기서 제3 네트워크 노드(5)는 제1 네트워크 노드와 통신으로 연결된 네트워크 노드 기능을 제공하기 위한 네트워크 노드 사이에 리소스를 할당하는 방법.
청구항 6에 있어서,
리소스 가용성 데이터는 제3 네트워크 노드에 위치한 리소스 프로바이더 기능(4)의 표시를 포함하며, 여기서 네트워크 노드 리소스(3)를 할당하는(103, 104) 단계는 제3 네트워크 노드(1)에서 네트워크 노드 리소스(3)를 할당하기 위해 리소스 프로바이더 기능(4)에 하나 이상 리소스 할당 지시를 전송하는(103) 단계를 포함하는 네트워크 노드 기능을 제공하기 위한 네트워크 노드 사이에 리소스를 할당하는 방법.
청구항 5 또는 청구항 7에 있어서,
상기 하나 이상 리소스 할당 지시는 할당된 네트워크 노드 리소스(3)에서 네트워크 노드 기능을 다운로드하기 위한 지시를 포함하는 네트워크 노드 기능을 제공하기 위한 네트워크 노드 사이에 리소스를 할당하는 방법.
청구항 1 내지 청구항 8 중 어느 한 항에 있어서,
요청 데이터는 제1 네트워크 노드(1) 또는 제1 네트워크 노드(1)와 제2 네트워크 노드(2) 사이의 중간 제4 네트워크 노드(6) 중 하나에서 인터셉트되는 네트워크 노드 기능을 제공하기 위한 네트워크 노드 사이에 리소스를 할당하는 방법.
청구항 1 내지 청구항 9 중 어느 한 항에 있어서,
상기 리소스 가용성 데이터는 둘 이상의 다른 네트워크 노드에서 이용 가능한 네트워크 노드 리소스(3)에 관한 정보를 포함하며, 여기서 방법은 하나 또는 둘 이상 또는 더 많은 다른 네트워크 노드에서 네트워크 노드 리소스를 할당하기 위한 하나 또는 둘 이상 또는 더 많은 다른 네트워크 노드를 선택하는(107) 단계를 더 포함하는 네트워크 노드 기능을 제공하기 위한 네트워크 노드 사이에 리소스를 할당하는 방법.
청구항 1 내지 청구항 10 중 어느 한 항에 있어서,
이용 가능한 네트워크 노드 리소스에서의 변화를 제1 네트워크 노드(1)에 반영하는 리소스 가용성 데이터를 업데이트하는 단계와 업데이트된 리소스 가용성 데이터를 제1 네트워크 노드(1)로부터 제2 네트워크 노드(2)로 전송하는 단계를 더 포함하는 네트워크 노드 기능을 제공하기 위한 네트워크 노드 사이에 리소스를 할당하는 방법.
네트워크 노드 기능에 액세스하기 위한 제2 네트워크 노드(2)에 통신적으로 연결될 수 있는 제1 네트워크 노드(1)에 있어서, 상기 제1 네트워크 노드(1)는:
제2 네트워크 노드(2)에 리소스 가용성 데이터를 전송하며(101a), 여기서 리소스 가용성 데이터는 제1 네트워크 노드(1)에 이용 가능한 하나 이상의 네트워크 노드 리소스(3)에 관한 정보를 포함하고;
제1 네트워크 노드(1)에서 네트워크 노드 리소스(3)을 할당하기 위하여 제2 네트워크 노드(2)로부터 하나 이상의 리소스 할당 지시를 수신하며;
제2 네트워크 노드(2)에 요청 데이터를 전송하며(101b), 여기서 요청 데이터는 네트워크 노드 기능을 사용하기 위한 요청을 포함하고;
상기 요청 데이터를 인터셉터하며(105); 및
네트워크 노드 기능을 제공하기 위한 할당된 네트워크 노드 리소스(3)로 요청 데이터를 리디랙트 하도록 구성된 제1 네트워크 노드.
청구항 12에 있어서,
하나 이상의 리소스 할당 지시는 할당된 네트워크 노드 리소스(3)에서 네트워크 노드 기능을 다운로드 하기 위한 지시를 포함하며, 제1 네트워크 노드(1)는 할당된 네트워크 노드 리소스(1)에서 네트워크 노드 기능을 다운로드 하도록 더 구성된 제1 네트워크 노드.
청구항 12 또는 청구항 13에 있어서,
제1 네트워크 노드(1)는 클라이언트 장치인 제1 네트워크 노드.
청구항 14에 있어서,
제1 네트워크 노드(1)는 모바일 통신 장치인 제1 네트워크 노드.