KR20070009557A

KR20070009557A - 객체를 저장하고 액세스하는 장치 및 방법

Info

Publication number: KR20070009557A
Application number: KR1020067015354A
Authority: KR
Inventors: 프라데프 베르마; 케이트 갈레트
Original assignee: 벤투리 와이어리스, 인코포레이티드
Priority date: 2003-12-29
Filing date: 2004-12-22
Publication date: 2007-01-18
Also published as: WO2005065240A3; EP1706207A4; EP1706207A2; JP2007523400A; AU2004311797A1; IL176550A0; US20050198395A1; WO2005065240A8; WO2005065240A2; CA2551132A1

Abstract

본 발명은 재사용을 위해 압축된 객체를 저장하고 액세스하는 방법 및 장치를 제공한다. 웹으로부터 수신되는 객체와 같은 압축 데이터는 캐시에 다시 기록된다. 이렇게 하면, 압축 설정에 따라서 동일한 객체에 대해 복수의 객체 사이즈로 저장하는 것이 가능하게 된다. 객체가 압축되면, 그것을 다시 압축할 필요는 없다. 본 발명은 또한 예를 들어 만약 클라이언트를 통해 요구가 수신되면 객체에 대한 제 2 요구에 대해 부가적인 압축을 달성하기 위해 객체의 헤더를 압축한다. 클라이언트리스(clientless) 모드에서는, 헤더를 압축할 필요가 없다.

Description

객체를 저장하고 액세스하는 장치 및 방법{REUSABLE COMPRESSED OBJECTS}

본 발명은 압축 객체를 저장하는 기술에 관한 것이다. 보다 구체적으로는, 본 발명은 나중 검색을 위해 압축 객체를 저장하는 기술에 관한 것이다.

예를 들어 웹 페이지 또는 그 일부분을 포함하는 HTML 정보와 같은 전자 형식의 정보를 나타내는 객체는 빈번하게 저장된다. 이것은 웹으로부터 객체를 리로드(reload)할 필요없이 객체를 신속하게 검색할 수 있도록 한다. 이러한 객체는 흔히 브라우저를 구비한 셀 폰과 같은 무선 장치에 제공된 컨텐츠의 상당한 부분을 구성한다. 그러나, 무선 장치가 웹 게이트웨이와 통신할 수 있게 하는 무선 통신 채널과 웹 사이의 대역폭의 차이로 인해, 객체는 무선 통신 채널을 통해 무선 장치로 전송되기 전에 먼저 압축되어야 한다. 현재의 관행으로는 전 객체를 캐시에 저장하고 있다. 객체가 다시 요구되면, 전 객체를 캐시로부터 획득하여 그것을 다시 압축할 필요가 있는데, 이 때문에 상당한 시스템 자원이 사용된다. 도 1은 예비 인출(prefetch) 동작을 이용하지 않는 객체에 대한 요구 흐름을 나타내는 개략적인 블록도로서, 여기서 흐름의 시퀀스는 대응하는 화살표와 관련된 문자숫자 표시 (A1->A6)로 나타내었으며, 도 2는 객체에 대한 요구 흐름을 나타내는 개략적인 블록도이다. 도 1 및 2에서, 클라이언트(11)는 HTTP와 같은 전송 메커니즘을 통해 게이트웨이(15)로부터 서버(17)에 저장된 객체로부터 객체를 요구한다. 검색 시에, 객체는 압축기(13)에 의해 압축되고, 그 다음에 게이트웨이를 통해 요구 클라이언트에게 반환된다. 도 2는 예비 인출 동작이 가능한 경우를 도시하고 있다. 따라서, 객체는 사전에 저장되며 압축을 위해 국부적으로 검색될 수 있다.

객체가 다양한 레벨의 해상도에서 요구되는 경우에 다른 문제가 발생한다. 현재, 객체는 요구될 때마다 캐시(또는 객체가 캐시에 저장되지 않은 경우에는 웹)로부터 검색되어야 하며, 또한 타겟 장치에 대한 적절한 정도의 압축을 이용하여 압축되어야 한다. 이것은 특정 객체가 반복적으로 압축되어야 한다는 것을 의미하는데, 여기서 객체의 해상도는 압축될 때마다 다를 수 있다.

마지막으로, 객체는 그 객체에 대해 상이한 포맷이 요구되는 다양한 타겟 장치에 대해 요구될 수도 있다. 예를 들면, 객체가 하나의 플랫폼에서는 HTML에 요구될 수도 있지만, 다른 플랫폼은 그 대신에 ASCII를 지원할 수도 있다. 따라서, 객체는 원래의 포맷으로부터 타겟 플랫폼 포맷으로 변환된 다음에 요구될 때마다 압축되어야 할 수도 있다.

이들 반복된 압축 및 포맷 변환 동작은 시스템에 상당한 버퍼링 및 처리 요건들을 추가한다.

재사용을 위해 압축된 객체를 저장하고 액세스하는 방법 및 장치를 제공하는 것이 유익할 것이다. 또한, 이러한 방법 및 장치가 여러 포맷들 및/또는 해상도 중 하나 이상으로 객체를 저장할 수 있으면 유익할 것이다.

본 발명은 재사용을 위해 압축된 객체를 저장하고 액세스하는 방법 및 장치를 제공한다. 예를 들어 웹으로부터 수신되는 객체와 같은 압축된 데이터는 캐시에 다시 기록된다. 이렇게 하면, 압축 설정에 따라서 동일한 객체에 대해 복수의 객체 사이즈로 저장하는 것이 가능하다. 객체가 압축되면, 그것을 다시 압축할 필요는 없다. 본 발명은 또한 예를 들어 만약 클라이언트를 통해 요구가 수신되면 객체에 대한 이 제 2 요구에 대해 부가적인 압축을 달성하기 위해 객체의 헤더를 압축하기 위해 제공한다. 클라이언트리스 모드에서는, 헤더를 압축할 필요가 전혀 없다.

도 1은 압축된 객체 및 예비 인출 동작의 사용이 없는, 객체에 대한 요구 흐름을 도시하는 개략적인 블록도.

도 2는 압축된 객체의 사용이 없는, 객체에 대한 요구 흐름을 도시하는 개략적인 블록도.

도 3은 본 발명의 제 1 실시예에 따른 객체에 대한 요구 흐름을 도시한 개략적인 블록도.

도 4는 본 발명의 제 2 실시예에 따른 객체에 대한 요구 흐름을 도시한 개략적인 블록도.

도 5는 본 발명의 제 3 실시예에 따른 객체에 대한 요구 흐름을 도시한 개략적인 블록도.

도 6은 요구의 흐름을 도시한 흐름도.

도 7은 예비 인출 측에서의 요구의 흐름을 도시한 흐름도.

도 8은 CO가 존재하지 않는 경우의 요구의 흐름을 도시한 흐름도.

도 9는 CO가 존재하지 않는 경우의 요구의 흐름을 도시한 흐름도.

본 발명은 재사용을 위해 압축된 객체를 저장하고 액세스하는 방법 및 장치를 제공한다. 예를 들어 웹으로부터 수신되는 객체와 같은 압축 데이터는 캐시에 다시 기록된다. 이렇게 하면, 압축 설정에 따라서 동일한 객체에 대해 복수의 객체 사이즈로 저장하는 것이 가능하다. 객체가 압축되면, 그것을 다시 압축할 필요는 없다. 본 발명은 또한 예를 들어 만약 클라이언트를 통해 요구가 수신되면 객체에 대한 이 제 2 요구에 대해 부가적인 압축을 달성하기 위한 객체의 헤더를 압축하기 위해 제공한다. 클라이언트리스 모드에서는, 헤더를 압축할 필요가 전혀 없다.

정의(Definition)

다음의 기억술은 관련 의미로 본 명세서에서 사용된다.

VS : 이것은 서버를 지칭한다.

VC : 이것은 클라이언트를 지칭한다.

VCO : 이것은 압축 객체를 저장하는데 사용되는 데이터 구조이다.

예비 인출(Prefetch) : 이것은 본 발명에 의해 향상되는 하부 데이터 구조이다.

COURL : 이것은 VCO 확장자를 갖는 변형 URL이다.

NMURL : 이것은 캐시로 전송되는 표준 URL이다.

CP : 이것은 COURL을 다루는데 사용되는 캐시 프록시이다

설명(Description)

객체가 검색되면, 압축기를 통해 진행한다. CPU는 객체를 압축하는데 많이 사용된다. 동일한 객체에 대해 동일한 압축을 행하는 것은 시간 소모적이며 느리다. 본 발명은 일단 객체를 압축한 다음에 이들을 캐시에 저장함으로써 CPU의 많은 사용을 회피한다는 견해에 기인한다. 본 발명의 바람직한 실시예는 압축 객체를 캐시에 저장한다. 특정 객체에 대한 새로운 요구가 수신되면, 그 객체는 캐시로부터 직접 검색되어 클라이언트로 전송될 수 있다.

현 실시예에서, 원래의 객체는 캐시에 저장된다. 전 객체가 수신되면, 데이터는 압축되지만, 헤더는 압축되지 않는다. 압축 객체(VCO)는 캐시에 저장된다. 사용된 압축 기법을 식별하기 위한 충분한 정보가 내부적으로 저장된다. 이 방법의 한가지 이점은 압축 객체가 후속 사용을 위해 캐시에 저장된다는 것이다. 그 객체에 대한 요구가 다시 이루어지면, URL이 대응하는 COURL로 변환되는데, 이것은 내부 테이블에 유지된다. 그 다음에, 압축 데이터가 캐시로부터 직접 검색될 수 있 다. 이 방법으로 캐시에 저장된 데이터는 압축되어 있기 때문에 보다 적은 버퍼를 사용한다. 이 방법은 또한 보다 적은 CPU를 사용하고, 데이터가 캐시로부터 서버로 보다 빠르게 전달되기 때문에 고속이며 이것은 전달하기에 적고 압축할 필요가 없다는 것이다. VCO가 요구되면, 헤더는 객체 그 자체를 포함하는 데이터보다 사이즈가 훨씬 더 작기 때문에 상대적으로 더 빠르게 압축될 수 있다. 그 다음에 VCO는 클라이언트로 전송된다.

이것은 도 3 내지 5에 가장 잘 도시되어 있는데, 도 3은 본 발명의 제 1 실시예에 따른 객체에 대한 요구 흐름을 도시하는 개략적인 블록도이고, 도 4는 본 발명의 제 2 실시예에 따른 객체에 대한 요구 흐름을 도시하는 개략적인 블록도이며, 도 5는 본 발명의 제 3 실시예에 따른 객체에 대한 요구 흐름을 도시하는 개략적인 블록도이다.

도 3에서, 클라이언트는 객체, 예를 들어 Taj.gif를 요구한다. 객체는 본 발명을 포함하는 게이트웨이(31)를 통해 액세스된다. 객체는 예비 인출 동작의 결과로서 저장될 수도 있고 또는 요구의 실행 시 인출될 수도 있다. 처음 요구될 때, 객체는 압축기(13)로 라우팅되고, 그 다음에 클라이언트로 제공되어 압축된 형태로 캐시에, 예를 들어 Taj.gif.vco로서 저장된다. 객체의 헤더는, 객체를 압축 해제하지 않고 객체를 배치하기 쉽게 하기 위해, 예를 들어 Vco.html처럼 압축되지 않은 형태로 객체로부터 멀리 유지된다. 포맷, 해상도 등과 같은 다양한 메타데이터가 객체명에 포함될 수 있다. 도 4는, 객체가 인출되고 압축되어 캐시에 저장되며, 예를 들어 gif 및 PNG와 같은 복수 객체의 포맷이 존재하는 일실시예를 도시하고 있 고, 도 5는 객체가 캐시 내에 이미 존재하며 단순히 압축 상태로 검색되는 다른 경우를 도시하고 있다.

기능(Functionality)

이하는 다른 모듈에 의해 사용되는 외부 함수이다.

*int http_a_prefetch(int wi, int flags);

*int http_vbuf_to_url(uchar*url, int bidx, int max_len);

*int vco_process_courl_request (int wi);

*int vco_process_http_request (int wi);

*int vco_set_compression_info (int wi);

*int fwd_vco_a_data(int wi, int idx, int ta_close, int flags);

*void vco_get_request_capability(int wi);

요건(Requirement)

VCO에 대한 주 상호작용은 압축기뿐만 아니라 HTTP 요구, 예비 인출 요구 사이에 있다.

유용성(Usability)

서버에서 도식적인 사용자 인터페이스(GUI, Graphical User Interface)는 구성되는 특징을 갖는다. 압축 페이지는 GUI 상의 주 페이지이다. 이것은 Gif2Png, J2k에 대한 구성을 갖는다. 이것은 또한 팝업 차단 및 Lossy HTML 필터도 갖는다. 이들은 VCO에 의해 사용되어 특성 함수를 통해 그들을 압축기 플래그로 변환시킨다.

GUI

GIF to PNG Conversion : [Image]

JPEG 2000 Support : [Image]

Send Original Images on Reload

Client/Server : [Image]

ClientLess : [Image]

다음은 VCO 환경을 구성하기 위한 GUI이다.

Caching Compressed Object : [Image]

이것은 사용불가 또는 사용가능한 체크박스이다.

설계 사양(Design Specification)

요구 흐름(Request Flow)

도 6은 요구의 흐름을 나타내는 흐름도이다. 이 요구는 클라이언트(VC)로부터 나온다. 요구가 존재하거나 또는 그렇지 않다면 VCO를 검사할 필요가 있다. 예비 인출로부터의 요구와 HTTP로부터의 요구를 구분한다.

예비 인출로부터의 요구(Request comes from Prefetch)

이 경우, 압축기는 기본 html 페이지를 분석하고, 그 다음에 페이지에 삽입된 객체에 대한 요구를 발행한다. 예비 인출 측에서의 흐름은 도 7에 도시되어 있다.

예비 인출(Prefetch)

예비 인출 요구는 VS에 의해 개시된다. 만약 객체가 VCO에 존재하지 않으면, 표준 헤더로 요구를 설정한다. 그 다음에 요구를 캐시로 전송한다. 캐시는 이것을 표준 요구(A1)로서 알고 서버 또는 원래의 서버로부터 요구를 실행한다. 응답(A2)이 돌아오면, 응답 헤더는 압축하지 않고 데이터를 압축하도록 지시하는 플래그와 함께 데이터를 압축기로 전송한다. 압축기가 압축된 객체를 다시 전송하면, 그것을 임시 버퍼에 저장한다. 압축기는 또한, 원래의 정보 및 압축 정보가 획득되면 그것을 통지한다. 그 다음에 압축기는 데이터 구조 내에 식별된 애플리케이션(Application Identified) 보조물을 설정한다. 이때 VS가 VS에 의해 개시되는 다른 요구인 COURL(A3)을 캐시로 전송한다. 캐시가 이 요구를 수신하면, 캐시로부터 그것을 직접 실행할 수 있다. VS에 의해 응답(A4)이 획득되면, 접속을 끊는다.

만약 서버가 데이터를 갖고 있지 않으면(요구가 처음이거나 또는 디스크로부터 그 데이터가 제거되었다면), 서버는 캐시 프록시(A5)의 포트(8009) 상의 COURL에 대해 VS로 요구를 다시 전송한다. VS가 이 요구를 획득하면, 이 요구를 그 전의 요구와 매칭시키고, 그 다음에 두 요구를 함께 연결한다. A3로부터의 소켓은 A2에 접속되고, A3는 종료된다. 그 다음에 데이터가 A2로 진행하고, 그 다음에 이 응답이 끊긴다. 따라서, 캐시는 이 데이터를 그 내부에 저장해야만 한다.

HTTP

요구는 HTTP로부터 나온다. 이 경우, 요구는 VC를 통해 또는 직접 브라우저에 의해 개시된다. 어느 경우든, 접속을 끊을 수는 없으며 따라서 예비 인출 요구와의 차이를 구별할 수 없다. 이 경우의 흐름은 객체가 VCO에 존재하는 지의 여부에 의존한다.

이 동안에, 관련되는 다양한 버킷(bucket) 내에 원래의 정보 및 압축 정보를 저장한다. 처음에는 압축 정보가 무엇인지 알지 못한다.

CO가 존재하지 않는 경우

도 8은 CO가 존재하지 않는 경우의 요구의 흐름을 도시한 흐름도이다.

CO가 존재하는 경우

도 9는 CO가 존재하지 않는 경우의 요구의 흐름을 도시하는 흐름도이다.

이 경우 동일한 객체에 대해 다음 요구를 갖는다.

서버 요구(Server Request)

만약 서버가 압축 객체를 가지면, 그것을 캐시로부터 바로 리턴할 것이다. 이것은 VCO가 실제로 유익한 경우이다. 이 목적을 위해 MCP를 사용한다. VCO 요구 가 COURL에 기초하여 MCP를 통해 들어오는 경우, VCO 내에 어떤 엔트리가 있는지를 알 수 있으며, 그 확장자는 압축 정보를 제공할 것이다. 따라서 요구들을 상관시킬 수 있다. 이들 값에 기초하여 hinfo를 설정한 다음에 NMURL 요구를 발행한다.

외부 캐시 지원(External Cache Support)

캐시는 외부 모드에서도 동작할 수 있다. 서버가 외부 캐시에 접속되는 경우, HTTP 요구를 프록시 요구로서 캐시로 전송한다. 그러면, 서버는 HTTP 서버로서 작동하며 외부 캐시는 HTTP 클라이언트로서 작동한다. VCO 확장자로 끝나는 경우에 요구를 사용자에게 전송하여 다시 서버로 전송할 수 있는 외부 캐시의 능력은, 외부 캐시가 이 특징을 이용할 수 있는 지의 여부를 결정한다. 캐시는 사용자에게 다시 돌아가는 요구를 발행할 수 있는 정규 표현을 사용한다. 다른 캐시는 이러한 유형의 구성을 지원해야 한다. 흐름의 나머지는 이와 유사하게 발생하며 특별히 주의해야 할 특별한 필요는 없다.

내부 구조

파일 포맷

Gif2Png, PPM, J2k에 대한 구성을 갖는 app.xml로 이동하는 두 개의 다른 테이블이 있다. 또한 팝업 차단 및 LosyHtml 필드가 추가되었다. 이들은 그 구성에 따라서 VCO에 의해 압축기 플래그를 설정하는데 사용된다.

레벨 4는 내부이고, 제어 재생 메커니즘에 사용되기 때문에 xml에서 일반적으로 오프(off)되어야 한다.

데이터 구조

현재 규정되어 있는 여섯 개의 압축기 유형이 있다.

#define COMP_TYPE_UNKNOWN 0

#define COMP_TYPE_NONE 1

#define COMP_TYPE_GIF 2

#define COMP_TYPE_JPG 3

#define COMP_TYPE_ZLIB 4

#define COMP_TYPE_HTML 5

UNKNOWN은 객체의 유형을 모르는 경우이다. 압축기가 응답을 확인하면, 그 유형이 무엇인 지를 결정할 수 있으며 그에 따라 유형을 설정한다.

압축기 제어 플래그는 이하에 정의되어 있다. 이들은 압축기가 응답을 어떻게 처리하는지를 알도록 VentS가 요구를 보내기 전에 설정하는 압축기에 대한 제어를 나타낸다. FORCE는 그 유형을 알고 있고 어떤 플래그가 설정되어야 하는지를 알고 있는 객체에 사용된다.

#define VCO_CC_FORCE 0x00000001

#define VCO_CC_COMP_HDR 0x00000002

#define VCO_CC_COMP_BODY 0x00000004

#define VCO_CC_ZLIB_HDR 0x00000008

#define VCO_CC_VALID 0x00000010

#define VCO_CC_PREFETCH 0x00000100

#define VCO_CC_HEAD 0x00000200

압축기 HDR 및 압축기 BODY 플래그는 압축기에게 응답의 어떤 부분이 압축될 필요가 있는 지를 알게 하는데 사용된다. ZLIB 헤더는 이에 따라서 설정된다. VALID 플래그는 되돌아오는 값이 유효하다는 것을 알게 하는 방식으로, 압축기로부터 VentS로의 신호로서 사용된다. PREFETCH는 예비 인출 환경이 온으로 되었고, HTML 내의 객체가 예비 인출될 수 있다는 것을 나타내도록 설정된다. HEAD는 헤드 요구를 나타내며, 따라서 이것에 대한 BODY를 갖지 않는다.

아래에는 VentS로부터 압축기로 그리고 다시 역전송되는 압축기 플래그가 제시되어 있다. VentS가 이들 값을 설정하면, 이것은 요구의 능력을 파악하여 이들 플래그 중 어느 것이 설정될 필요가 있는 지를 판정한다. 압축기가 VALID 플래그를 설정할 때, 또한 적절하게 작동할 수 있도록 객체에 무엇을 해야 하는 지를 나타낸다.

#define VCO_CF_STDDICT 0x00000001

#define VCO_CF_LDDICT 0x00000002

#define VCO_CF_PPM 0x00000004

#define VCO_CF_DEFLATE 0x00000008

#define VCO_CF_GZIP 0x00000010

#define VCO_CF_GIF2PNG 0x00000020

#define VCO_CF_POP-UP_BLOCK 0x00000040

#define VCO_CF_LOSSY_HTML 0x00000080

#define VCO_CF_CHUNK 0x00000100

#define VCO_CF_J2K 0x00000200

이들 플래그는 압축기로부터 설정된다. 이들은 VCO에 의해 이들을 역전송하는데 사용된다.

#define VCO_CF_ANIMATE 0x00001000

#define VCO_CF_LOSSLESS 0x00002000

#define VCO_CF_LOSSSY 0x00004000

Gif 이미지에 대해서는, 각 레벨에 대한 청킹(chunking)에 의해 gif, gif2png의 선택 사항을 갖는다. 고려할 다섯 레벨이 있기 때문에, 다음의 조합이 잠재적으로 허용된다.

JPEG 이미지에 대해서는, 각 레벨에 대한 청킹, jpeg, j2k의 선택 사항을 갖는다.

ZLIB 유형에 대해서는, 다음의 서브타입을 사용한다. 이들 서브타입은 5 개의 상이한 유형이다.

- PPM

- 표준 사전(dictionary)을 갖는 zlib

- 로딩 가능한 사전을 갖는 zlib

- DEFLATE

- GZIP

그 다음에, 청킹(chunking)하거나 하지 않을 기회를 갖는다. 따라서 다음의 조합이 생성된다.

HTML의 유형에 대해:

이것은 다른 ZLIB 옵션과 비교되는 타입의 특별한 유형으로서 취급된다. 이것은 최대 수의 옵션을 갖는다.

다음과 같은 서브타입이 있다. : STD 사전, 로딩 가능한 사전, PPM, Deflate 및 GZIP

각각의 서브타입에 대해 청킹, 손실 HTML 및 팝업 차단의 선택 사항이 있다. 따라서, 조작되는 5*8=20 개의 버킷 조합이 존재한다. 이들 버킷 조합은 다음과 같다.

다음은 VentS로부터 압축기로/로부터 정보를 전달하는데 사용되는 hinfo 구조이다.

함수 설명(Function Description)

이 섹션은 본 발명의 바람직한 실시예에서 실시된 코드를 보다 상세히 설명한다.

VCO에 대한 내부 함수(Internal Functions to VCO)

* static int vco_get_courl_extension (int wi, uchar *co_extension)

courl 확장자는 vco_<type %lu>_<comp_flags %lx>_<lddict %lu>_vco 포맷을 갖는다.

서버는 단부의 _vco를 지원하도록 구성되었다. 서버는 이러한 요구를 캐시 프록시로 전송한다(다시 VentS로 전송한다).

서버의 액세스 로그 내의 요구는 이하와 다소 유사하다.

* static int vco_get_ci_from_courl_extension

(uchar *co_extension, ulong *type, ulong *comp flags, ulong *ld_dict)

이 함수는 CO 확장자를 입력으로 취하고 타입 comp_flags 및 ld_dict를 리턴한다.

* static void vco_update_prefetch_record (int wi)

이것은 예비 인출 요구 또는 VCO 예비 인출 요구가 완료되었을 때 예비 인출 레코드를 갱신하는데 사용된다.

* static int get_compression_index (int wi, int *cidx)

이것은 어떠한 압축 값이 존재하는 지를 보는데 필요한 버킷을 획득한다.

* static int vco_set_hinfo_by_record (int wi, int cidx)

이 함수는 VCO 테이블 내의 특정 버킷으로부터 정보를 획득하고 이 정보에 기초하여 hinfo를 설정한다. 이것은 후속 요구에 사용되며, 이를 위해 이전의 완료로부터 사용된 플래그를 이용할 수 있다.

* static void vco_set_other_buckets (int wi, int cidx)

이 함수는 동일한 문자를 갖는 다른 버킷을 설정하도록 결정했을 때 호출된 다.

다음은 버킷의 간략한 설명이다. ZLIB 유형의 객체를 예로 든다.

좌측 열은 지원하는 플래그로서 압축기로 전송하는 것이다. 다른 열은 압축 정보으로 설정하고자 할 때 압축기가 설정하는 값들이다. 그러면, 청킹(chunking)의 조합이 있을 수도 있고 없을 수도 있다.

일부 객체에 대해 압축기로 아래와 같이 압축 플래그를 전송한다고 하자.

압축기가 유효 플래그를 가지고 복귀하면, 다음과 같다.

이제 유형이 5(HTML)임을 알게 되었으므로, 요구가 29. VCO_ST_DEF_CHUNK_

NLHNPB의 버킷을 갖는 지를 판단할 수 있다.이것은 그것이 압축(deflate)일 뿐만 아니라 청킹 지원되었으며 손실 HTML이 없고 팝업 차단도 없다는 것을 의미한다.

이제 문제는 이 정보로 채워질 수 있는 다른 버킷이 있다면 그처럼 잘 VCO를 할 수 있느냐는 것이다. VCO_ST_DEF_NLHNPB는 사용될 수 있는 다른 버킷(25)인 것으로 판명되었다. 이것은 압축(deflate)이며 손실(lossy) html을 갖지 않고 팝업 차단 세트를 갖지 않는 유사한 특징을 갖는다. 유일한 차이점은 청킹이 설정되지 않는다는 것이다. 그러나, 압축기는, 객체를 압축했을 때 청킹 비트를 설정하지 않았다. 이 버킷을 또한 사용할 수 있다. 이 방법에서 만약 HTTP/1.0 요구(청킹 없음)를 받게 되면, 여전히 그 요구를 서비스할 수 있다. 몇몇 경우에는 또한 복수의 조합이 있을 수 있다. 이 방법에서는 VCO가 그 곱으로부터 최대 이득을 얻을 수 있다. 이 동일한 예는 다른 유형의 객체에 대해서도 적용될 수 있다.

* static void veo_copy_cidx_new (int wi, int cidx, int cidx_new)

이것은 구 인덱스(cidx)로부터 새로운 인덱스(cidx_new)로 버킷 정보를 복사하는 유틸리티 함수이다. 이것은 또한 다른 버킷에 대해 파라미터를 설정하기 위해 vco_set_other_bucket에 의해 사용된다.

* static void print_compression_info (HdCompInfo *comp_info)

이것은 판독 방식이 보다 쉬운 압축 정보의 내용을 인쇄하는 유틸리티 디버그 함수 중 하나이다. 이것은 #define VCO_PRINT 9 //change to 100을 통해 오프되도록 제어된다.

외부 함수(External Function)

* int vco_iprocess_http_request (int wi)

이 함수는 클라이언트리스(clientless) 또는 클라이언트 사용자로부터 들어온 HTTP 요구에 대해 호출된다. 접속이 이루어지고 요구를 할 필요가 있으면, 이 함수를 호출한다. 이 함수의 목적은 요구를 처리할 방법을 결정하는 것이다. VCO에 관계없이 또는 예비 인출이 있던 없던 압축기 플래그를 설정할 필요가 있다.

출력(Output)

-1 : 에러가 발생하였으며 요구는 처리될 수 없다.

0 : 양호(OK)

1 : 확장자 추가를 위해 파서가 다시 호출될 필요가 있다.

이것은 hinfo 구조 내의 값을 설정한다. 또한 이것이 예비 인출 레코드 테이블(VCO 테이블)을 통해 진행하는 첫회인 지의 여부를 판정하고, 그 다음에 이것을 VCO URL 요구로 변환할 필요가 있는 지의 여부를 판정한다.

* int vco_process_courl_request (int wi)

이 함수는 서버로부터 캐시 프록시 포트를 통해 들어오는 캐시 프록시 요구를 처리하고자 할 때 호출된다. 이것은 확장자를 분석하고, 그것을 사용하는데 필요한 압축 정보를 얻는다. 이 요구에 대해, 이것은 서버로 진행하므로, 단지 본 문(body)만이 압축된다. 예비 인출의 경우에는, 서버가 요구를 전송하게 하는 이전의 접속으로부터 wiOld 데이터를 획득할 가능성이 있다. 이 경우, 두 요구를 연결만 하면 된다. 만약 구 요구가 그대로 있으면, 이 요구를 원래의 URL로 변환시켜 전송한다.

* int vco_set_compression_info (int wi)

이 함수는 압축기가 압축 정보를 가질 때 호출된다. 이것은 hinfo 구조 내의 값을 설정하고 캐시 제어 플래그 내의 VALID 플래그를 설정한다. 이것은 정보가 이용가능하게 된 VentS로의 지시를 나타낸다. 이 함수의 목적은 요구에 대한 버킷 내의 압축 정보를 설정하는 것이다. 만약 원래의 정보가 설정되지 않으면, 원래의 유형, 사이즈 및 레벨을 설정한다. 그 다음에 관심 버킷을 취하여 comp_flags, comp_control_flags 및 다른 파라미터에 대한 값을 설정한다. 그 다음에, 계속해서 동일한 특징을 가질 수 있는 다른 버킷들을 설정한다.

* void vco_get_request_capability (int wi)

이 함수는 요구 능력을 획득하는데 사용된다. 이것은 세 가지 방법을 통해 획득된다.

1. 서버 구성: 서버가 설정되는 플래그의 일부를 결정한다.

2. 클라이언트 능력

3. 요구 능력

압축기 플래그는 상기 사항에 기초하여 설정된다. 처음에는 요구의 유형이 무엇인지 알 수 없기 때문에 complnfo에 대한 필드를 unknown으로 설정한다. 그 다음에 압축기 플래그를 설정할 필요가 있다. 다음은 각 플래그에 대한 간략한 설명이다.

압축기 플래그 : 설명

VCO_CF_STDDICT : 이 압축기 플래그는 클라이언트가 표준 사전을 처리할 수 있다는 것을 나타낸다. 이것은 rcp->status 내의 AG_ZLIB에 기초하여 설정된다.

VCO_CF_LDDICT : 이 압축기 플래그는 클라이언트가 로딩 가능한 사전을 처리할 수 있음을 나타낸다. 이것은 rcp->status 내의 AG_LDDICT에 기초하여 설정된다. 이것은 클라이언트의 능력에서 비롯된다.

VCO_CF_PPM : 이 압축기 플래그는 클라이언트가 PPM 압축 방법을 사용할 수 있을 때 설정된다. 이것은 rcp->status 내의 AG_PPM 및 서버의 SvrCompCfg.ppmd에 기초한다. 이 구성 파라미터는 서버 상의 app.xml에 있으며 항상 ON이다.

VCO_CF_DEFLATE : 이 플래그는 클라이언트리스 모드에 있고 인코딩이 HCE_DEFLATE 및 HttpCfg.ss_comp==1 OR HttpCfg.ss_comp==3인 경우에 설정된다. 이 플래그는 넷스케이프의 구 버전을 취급하는 경우에 리셋된다.

VCO_CF_GZIP : 이 플래그는 클라이언트리스 모드에 있고 인코딩이 HCE_GZIP 및 HttpCfg.ss_comp==1 OR HttpCfg.ss_comp==2인 경우에 설정된다. 이 플 래그는 넷스케이프의 구 버전을 취급하는 경우에 리셋된다.

VCO_CF_GIF2PNG : 이 플래그는 Gif2PNG(SvrCompCfg.gif2png)가 인에이블되고 브라우저가 gif2png 변환을 지원할 때 설정된다(이것은 HS_BADIE 또는 VCO_CF_GIF2PNG가 아니다).

VCO_CF_POP-UP_BLOCK : 이 플래그는 압축 페이지 상에서 팝업 차단이 인에이블된 경우에 설정된다.

VCO_CF_LOSSY_HTML : 이플래그는 손실 html이 압축 페이지 상에서 인에이블 된 경우에 설정된다.

VCO_CF_CHUNK : 이 플래그는 브라우저가 청크 데이터를 이해할 수 있는 경우에 설정된다. 이것은 실제로 요구가 HS_HTTP1_1임을 의미한다.

VCO_CF_J2K : 이 플래그는 서버가 J2K에의해 인에이블되고 클라이언트 능력이 J2K를 지원한다고 하는 경우에 설정된다.

VCO_CF_ANIMATE : 이 플래그는 항상 처음에 설정된다. 이것은 단지 압축기가 애니메이션 이미지가 지원된다는 것을 알게 한다.

VCO_CF_LOSSLESS : 이 플래그는 항상 처음에 설정된다.

VCO_CF_LOSSY : 이 플래그는 항상 처음에 설정된다.

* int vco_get_comp_control_flags (int wi, int flags)

압축기 제어 플래그는 특정한 파라미터에 기초하여 설정된다. 이들 파라미터는 다음과 같다.

1. 클라이언트 없음(Clientless) : 이것은 요구가 클라이언트리스 사용자(clientless user) 또는 클라이언트로부터의 요구인 지를 알려준다.

2. VCO : 이것은 저장된 객체가 VCO 테이블에 있는 지의 여부를 알려준다.

3. 예비 인출(Prefetch) : 이것은 요구가 예비 인출 요구인 지의 여부를 알려준다.

4. 캐시프록시(CacheProxy) : 이것은 포트(8009)에서 서버로부터 돌아오는 요구이며 VCO요구이다.

이들 파라미터에 기초하여, FORCE, COMP_HDR 또는 COMP_BODY 플래그를 사용하고자 하는 지를 결정한다. "아니오(No)"는 그것이 설정되어 있지 않다는 것을 의미한다. "예(Yes)"는 그것이 설정되어 있다는 것을 의미한다. "-"는 이것이 가능하지 않다는 것을 의미한다. 플래그는 VCO 파라미터를 설정하는 것을 의미한다. 다른 것들은 구성 파라미터에 의해 발견된다.

이것은 또한 요구가 헤드 요구이면 VCO_CC_HEAD를 설정한다. 또한, 요구가 예비 인출 요구이면, VCO_CC_PREFETCH 플래그를 설정한다.

* int vco_http_process_courl_prefetch (int wi)

이 함수의 목적은 예비 인출될 필요가 있는 COURL을 처리하는 것이다. 원래의 예비 인출 요구를 전송하고 응답이 돌아오면, 압축된 본문 및 원래의 헤더를 저장한다. 그 다음에 COURL에 대해 이 호출을 발행한다. 만약 캐시가 이 객체를 갖고 있으면, 완료된다. 그렇지 않으면, 계속 진행한 후에 CPURL(포트 8009)을 VentS로 전송한다. 그 다음에, CPURL이 처리되고 두 개의 요구가 함께 결합된다. 이 방식으로 캐시가 적절한 방식으로 CPURL을 얻을 수 있다.

이상 바람직한 실시예를 참조하여 본 발명을 설명하였지만, 당업자라면 본 발명의 사상 및 범주를 벗어나지 않고 다른 애플리케이션이 본 명세서에 개시된 사항들을 대신할 수도 있다는 것을 알 수 있을 것이다. 따라서, 본 발명은 청구범위에 의해서만 한정된다.

Claims

객체를 저장하고 액세스하는 장치에 있어서,

객체를 요구하는 클라이언트와,

상기 요구된 객체를 검색하는 서버와,

상기 객체가 처음 요구되었을 때 상기 요구된 객체를 압축하는 압축기와,

상기 요구에 응답하여 상기 압축된 객체를 상기 클라이언트에게 제공하고, 재사용을 위해 상기 압축된 객체를 캐시에 저장하는 게이트웨이를 포함하는

객체를 저장하고 액세스하는 장치.
제 1 항에 있어서,

상기 압축기는 복수의 압축 레벨 중 하나에 영향을 주는 수단을 더 포함하되,

상기 게이트웨이는 상기 객체에 적용되는 각각의 압축 레벨로 상기 객체의 복사본을 저장하는

객체를 저장하고 액세스하는 장치.
제 1 항에 있어서,

상기 객체를 원 포맷(native format)으로부터 복수의 타겟 포맷 중 한 포맷으로 변환시키는 변환 장치를 더 포함하되,

상기 게이트웨이는 상기 객체가 변환되는 각각의 타겟 포맷으로 상기 객체의 복사본을 저장하는

객체를 저장하고 액세스하는 장치.
제 1 항에 있어서,

상기 객체를 예비 인출하는 수단을 더 포함하되,

상기 객체는 요구되기 전에 압축되어 상기 캐시에 저장되는

객체를 저장하고 액세스하는 장치.
제 1 항에 있어서,

상기 객체는 헤더를 더 포함하는

객체를 저장하고 액세스하는 장치.
제 5 항에 있어서,

상기 헤더는 압축되는

객체를 저장하고 액세스하는 장치.
제 5 항에 있어서,

상기 헤더는 압축되지 않는

객체를 저장하고 액세스하는 장치.
제 1 항에 있어서,

상기 객체가 요구되면 저장된 압축 객체를 식별하여 배치하기 위한 테이블을 더 포함하는

객체를 저장하고 액세스하는 장치.
제 1 항에 있어서,

상기 객체는 상기 객체와 관련된 메타데이터를 더 포함하는

객체를 저장하고 액세스하는 장치.
제 9 항에 있어서,

상기 메타 데이터는 객체 식별 정보, 객체 압축 요소, 객체 해상도, 객체 포맷, 객체 스케일링 요소(object scaling factor), 객체 암호화 정보 중 어느 하나를 포함하는

객체를 저장하고 액세스하는 장치.
객체를 저장하고 액세스하는 방법에 있어서,

클라이언트가 객체를 요구하는 단계와,

서버가 상기 요구된 객체를 검색하는 단계와,

상기 객체가 처음 요구되었을 때 상기 요구된 객체를 압축하는 단계와,

상기 요구에 응답하여 상기 압축된 객체를 상기 클라이언트에게 제공하는 단계와,

재사용을 위해 상기 압축된 객체를 저장하는 단계를 포함하는

객체를 저장하고 액세스하는 방법.
제 11 항에 있어서,

상기 압축 단계는

복수의 압축 레벨 중 한 레벨에 영향을 주는 단계를 더 포함하되,

상기 객체의 복사본은 상기 객체에 적용되는 각각의 압축 레벨로 저장되는

객체를 저장하고 액세스하는 방법.
제 11 항에 있어서,

상기 객체를 원 포맷으로부터 복수의 타겟 포맷 중 한 포맷으로 변환시키는 단계를 더 포함하되,

상기 객체의 복사본은 상기 객체가 변환되는 각각의 타겟 포맷으로 저장되는

객체를 저장하고 액세스하는 방법.
제 11 항에 있어서,

상기 객체를 예비 인출하는 단계를 더 포함하고,

상기 객체는 요구되기 전에 압축되어 상기 캐시에 저장되는

객체를 저장하고 액세스하는 방법.
제 11 항에 있어서,

상기 객체는 헤더를 더 포함하는

객체를 저장하고 액세스하는 방법.
제 15 항에 있어서,

상기 헤더는 압축되는

객체를 저장하고 액세스하는 방법.
제 15 항에 있어서,

상기 헤더는 압축되지 않는

객체를 저장하고 액세스하는 방법.
제 11 항에 있어서,

상기 객체가 요구되면 저장된 압축 객체를 식별하여 배치하기 위한 테이블을 제공하는 단계를 더 포함하는

객체를 저장하고 액세스하는 방법.
제 11 항에 있어서,

상기 객체는 상기 객체와 관련된 메타데이터를 더 포함하는

객체를 저장하고 액세스하는 방법.
제 19 항에 있어서,

상기 메타 데이터는 객체 식별 정보, 객체 압축 요소, 객체 해상도, 객체 포맷, 객체 스케일링 요소, 객체 암호화 정보 중 어느 하나를 포함하는

객체를 저장하고 액세스하는 방법.
객체를 저장하고 액세스하는 방법에 있어서,

객체를 1회 압축하는 단계와,

재사용을 위해 상기 압축된 객체를 캐시에 저장하는 단계와,

상기 캐시로부터 상기 압축된 객체를 직접 검색하는 단계와,

상기 압축된 객체를 클라이언트로 직접 전송하는 단계를 포함하는

객체를 저장하고 액세스하는 방법.
제 21 항에 있어서,

원래의 압축되지 않은 객체를 상기 캐시에 저장하는 단계를 더 포함하는

객체를 저장하고 액세스하는 방법.
제 22 항에 있어서,

상기 원래의 압축되지 않은 객체가 수신되면, 상기 객체 내의 데이터는 압축되지만, 객체 헤더는 압축되지 않는

객체를 저장하고 액세스하는 방법.
제 21 항에 있어서,

상기 압축 단계는 사용된 압축 기법을 식별하기 위한 정보를 내부적으로 저장하는 단계를 더 포함하는

객체를 저장하고 액세스하는 방법.
제 21 항에 있어서,

객체에 대한 요구가 재차 이루어질 때, 상기 객체에 대한 식별자가 대응하는 압축된 객체 식별자로 변환되어, 내부 테이블에 유지되는

객체를 저장하고 액세스하는 방법.
제 21 항에 있어서,

상기 객체를 압축된 데이터 부분과 별도의 압축되지 않은 헤더 부분으로 보존하는 단계를 더 포함하되,

상기 헤더는 상기 객체를 식별하는데 사용되며,

압축된 객체가 요구되는 경우, 상기 객체 헤더는 상기 객체 자체를 포함하는 데이터보다 사이즈가 훨씬 더 작기 때문에 신속하게 압축될 수 있는

객체를 저장하고 액세스하는 방법.
객체를 저장하고 액세스하는 방법에 있어서,

객체에 대한 예비 인출 요구를 개시하는 단계와,

상기 객체가 압축된 객체로서 캐시에 존재하지 않으면, 표준 헤더로 요구를 설정하는 단계와,

상기 요구를 서버로 전송하고, 상기 서버가 상기 서버 또는 원 서버(origin server)로부터 상기 요구를 실행하는 단계와,

상기 서버로부터 응답이 오면, 상기 객체와 관련된 데이터를 압축하되 응답 헤더는 압축하지 않도록 지시하는 플래그와 함께 상기 객체를 압축기로 전송하는 단계와,

상기 압축기가 압축된 객체를 다시 전송해오면, 상기 압축된 객체를 큐에 저장하는 단계와,

제 2 요구를 상기 서버로 전송하는 단계와,

상기 서버가 상기 제 2 요구를 수신하면, 상기 서버가 상기 캐시로부터 직접 상기 제 2 요구를 실행하는 단계를 포함하는

객체를 저장하고 액세스하는 방법.