KR19980703863A - 데이타 캐쉬 저장 방법 및 장치와 컴퓨터 프로그램 제품 - Google Patents

Abstract

본 발명은 제 1 애플리케이션으로부터 수신되고 제 2 애플리케이션으로부터의 요구에 응답하여 제 2 애플리케이션으로 제공되는 데이타를 캐쉬하는 방법, 장치 및 컴퓨터 프로그램 제품에 관한 것이다. 본 발명의 방법, 장치 및 컴퓨터 프로그램 제품은 제 1 애플리케이션으로부터 수신되고 제 2 애플리케이션으로 제공되는 데이타 스트림을 캐쉬에 저장하여 제 2 애플리케이션으로부터의 요구에 대응하는 클라이언트 캐쉬 엔트리를 생성하는 방안을 포함한다. 또한, 본 발명은 클라이언트 캐쉬 엔트리의 생성 시간을 저장하여 클라이언트 캐쉬 엔트리 시간 기록을 생성한다. 본 발명은 제 2 애플리케이션으로부터의 요구를 질의하여 요구에 대응하는 클라이언트 캐쉬 엔트리가 존재하는지를 판정한다. 본 발명은 제 2 애플리케이션으로부터의 요구에 대응하는 클라이언트 캐쉬 엔트리에 대한 클라이언트 캐쉬 엔트리 시간 기록을 평가하여, 제 2 애플리케이션이 정보를 요구하기 전에 사전설정된 클라이언트 코히어런시 시간 구간 동안 제 2 애플리케이션으로부터의 요구에 대응하는 클라이언트 캐쉬 엔트리가 생성되었는지를 판정한다. 본 발명은 제 2 애플리케이션이 정보를 요구하기 전에 사전설정된 클라이언트 코히어런시 시간 구간 동안 상기 제 2 애플리케이션에 대한 클라이언트 캐쉬 엔트리가 생성되었을 때 클라이언트 캐쉬 엔트리를 요구에 응답하는 제 2 애플리케이션에 제공한다.

Description

데이타 캐쉬 방법 및 장치와 컴퓨터 프로그램 제품

최근 정보 고속화(information superhighway)에 대한 여론 및 중요성이 크게 대두되었으며 인터넷(Internet)을 대중 통신 매체로 채택하였다. 또한, 이러한 인터넷이 다중 네트워크를 거쳐 통신 및 대화하기 위한 실행가능한 매체로서 광범위하게 인식됨에 따라, 컴퓨터 네트워크들간의 대화를 위해 다수의 사용자에 의해 설정되도록 설계된 인터넷 표준 프로토콜들이 생겨났다.

이러한 인터넷에 대한 사례로는 인터넷 클라이언트(브라우저)가 인터넷 서버와 통신하는 클라이언트 서버 관계를 들 수 있다. 인터넷에 대한 액세스를 보다 많이 제공하기 위해, 클라이언트 및 서버에 의해 사용되는 통신 프로토콜 및 언어는 표준화되었다. 이들 프로토콜은 클라이언트와 서버 사이를 통신하는데 사용되는 통신 프로토콜인 HTTP(Hyper-Text Transfer Protocol)와 TCP/IP를 포함하며, TCP 부분은 컴퓨터 또는 애플리케이션들 사이를 통신하기 위한 이동 지정 프로토콜(transport specific protocol)이다. 클라이언트 및 서버가 통신하는 HTML(Hyper-Text Markup Language)로 일컬어지는 언어도 또한 표준화된다. 이들 프로토컬 및 언어는 머신(machine)과 독립적이고, 전송 정보에 대해 최대의 효율보다 떨어지는 접속-프로토콜을 이용하기 때문에, 각각의 트랜잭션(transaction)은 모두 자체 포함된다. 따라서, 예를 들어, 클라이언트로부터의 각각의 메시지는 브라우저의 성능에 대한 정보를 포함하며, 통신을 완료하기 위해 임의의 다른 통신과는 독립적이다. 이와 같이 클라이언트와 서버간의 통신을 자체 구비한 특징은 스테이트리스(stateless) 통신으로 일컬어지며, 주어진 통신을 위해 클라이언트와 서버 사이에 전송되는 데이타의 양을 증대시킨다.

월드 와이드 웹(World Wide Web)의 클라이언트/서버 애플리케이션 환경에서, 클라이언트는 사용자 인터페이스로서 기능하는 웹 브라우저일 수 있다. 웹 브라우저는 사용자 요구를 적절한 웹 서버에 전송하고, 웹 서버로부터 반환된 HTML 데이타를 포맷하여 디스플레이한다. 또한, 웹 브라우저는 HTML 데이타를 평가하여, HTML의 데이타에 차후의 브라우저 요구를 필요로 하는 소정의 내장형 하이퍼 링크 구문(hyper-link statements)이 존재하는지를 판정하며, 이러한 브라우저 요구는 브라우저에 의해 개시될 수 있다. 웹 서버는 클라이언트에 대한 서버로서 기능을 수행하고, 웹 브라우저의 요구를 프로세싱하고, 요구된 응답을 HTTP 데이타 스트림의 HTML 데이타의 일부로서 반환한다.

전형적인 월드 와이드 웹(WWW) 통신의 하나의 예로서, 웹 서버로부터 홈 페이지(home page)에 대한 요구를 개시하는 웹 브라우저의 경우는 HTTP, HTML, TCP, 웹 브라우저 및 서버간의 기본 관계를 나타낸다. 웹 브라우저의 사용자가 지정된 웹 사이트로부터의 정보를 요구하면, 웹 브라우저는 예를 들어 홈 페이지일 수 있는 원하는 웹 사이트의 URL(Universal Resource Locator)을 지정하는 웹 서버에 획득된(get) 요구를 전송함으로써 웹 서버와 통신을 개시한다. URL은 웹 사이트의 어드레스로서 기능을 수행하며 인터넷 전체를 통해 단지 하나만 존재한다. 이어서, 웹 서버는 URL에 의해 지정된 홈 페이지에 대응하는 HTML 데이타를 획득하여 이를 웹 브라우저에게 제공할 수 있다. 이러한 동작은 인터넷 웹 서버에 의한 인터넷상의 통신을 또한 포함할 수 있고, 또한 URL은 브라우저가 접속되는 로컬 네트워크에 위치하는 서버를 지정할 수 있다. 이어서, 웹 브라우저는 웹 서버로부터 HTTP 데이타 스트림으로서 수신된 HTML 데이타를 평가하여 아이콘(icon) 또는 이미지와 같은 소정의 내장형 하이퍼 링크가 존재하는지를 판정할 수 있다. 만일 하이퍼 링크가 존재하면 하이퍼 링크의 URL을 지정하는 요구를 개시하여 지정된 데이타를 획득할 수 있다. 그러면, 획득된 데이타는 홈 페이지에 통합되고 사용자에게 디스플레이될 수 있다. 이와 같은 단순한 예의 경우와 같이, 웹 브라우저에 의한 단일 사용자 입력 요구의 결과에 따라 사용자 입력 요구에 대응하는 HTML 데이타의 수신에 응답하여 웹 브라우저에 의해 자동적으로 수행되는 다수의 부가적인 요구가 생성될 수 있다.

도 1에는 인터넷을 기초로 하는 시스템의 기본적인 통신 구조가 도시되어 있다. 도 1에서, 웹 브라우저(10)는 통신 링크(15)를 통해 웹 서버(20)와 통신한다. 이러한 통신 링크는 통상적으로 근거리망 접속, 광역망 접속, 전화선을 통한 접속 또는 이들의 조합이다. 웹 브라우저(10)는 TCP/IP를 이용하여 웹 서버(20)와 통신한다. 대부분의 인터넷 통신에 있어서, 웹 브라우저는 웹 브라우저와 웹 서버 사이의 TCP/IP 링크를 통해 웹 브라우저와 웹 서버 사이로 전송되는 일반적인 통신 프로토콜인 HTTP를 이용하여 웹 서버와 통신한다. 전술한 바와 같이, 웹 브라우저(10)와 웹 서버(20) 사이에 전송되는 실제 데이타는 HTTP 데이타 오브젝트(예를 들어, HTML 데이타)이다. 웹 서버(20)는 다수의 웹 브라우저로부터 웹 브라우저 통신을 수신하고 이들을 적절한 서버에 라우팅하는 프락시(proxy)일 수 있다.

웹 브라우저/웹 서버, 이들의 공통적인 정보, 전송 프로토콜, HTML 및 HTTP의 대중화로 인해 네트워크의 정보 액세스에 대한 범용 인터페이스와 같은 웹 기술이 급격히 보편화되었다. 또한, 웹 브라우저와 웹 서버간의 통신에 대한 프로토콜 및 언어가 표준화됨에 따라, 사용자가 네트워크 정보를 액세스하기 위해 Netscape Navigator^TM, NCSA Mosaic^TM, WebExplorer^TM또는 임의의 다른 웹 브라우저를 웹 브라우저로서 사용하더라도 통신 프로토콜 및 언어는 동일하다. 따라서, HTTP에 의해 정의된 CGI(Common Gateway Interface)를 이용함으로써 인터넷의 접속과 웹 애플리케이션 서버의 용이한 기록을 조합한 웹 브라우저에 대한 대량 설정된 사용자 베이스로 인해, 다수의 부류의 형태를 기초로 한 애플리케이션에 매우 적합한 웹 기술이 구현된다.

최근 인터넷이 대중화되고 보편화됨과 동시에 이동 컴퓨터도 또한 크게 일반화되었다. 랩탑, 노트북, PDA/PCA(Personal Digital/Communication Assistants) 및 다른 휴대용 장치의 사용 증가로 인해 무선 통신의 수요가 급격히 증가되었다. 그렇지만, 무선 광역망, 셀룰라 통신 및 패킷 무선을 웹 문맥(web context)에 사용하는 경우 여러가지 공통적인 문제점들이 발생되었다. 통신 바이트당 고비용과, 낮은 응답 시간과, 낮은 대역폭과, 낮은 신뢰성은 모두 월드 와이드 웹(world wide web)의 스테이트리스 통신 프로토콜에 대한 무선 기술의 사용에서 저해 요인이다. 또한, 웹 프로토콜은 스테이트리스이므로, 통신을 자체적으로 구비하지 않으면, 요구당 데이타의 양과 무선 접속을 통해 전송된 통신 요구의 수는 필요로 하는 것보다 많다. 따라서, 보편적으로 웹 기술이 발전함에 따라 무선 기술의 문제점이 더욱 저해되기 때문에, 무선 기술 또는 소정의 저속 통신 기술을 웹 기술과 조합하는 것은 비실용적이다

본 발명은 캐쉬 구조 및 방법에 관한 것으로, 특히, 한쪽은 클라이언트 애플리케이션(client application)을 실행하고 다른쪽은 서버 애플리케이션(server application)을 실행하는 두 컴퓨터 사이의 저속 또는 무선 통신 링크를 통해 통신을 수행하는 시스템에 유용한 캐쉬 구조 및 방법에 관한 것이다.

도 1은 전형적인 웹 브라우저/웹 서버 시스템의 블럭도이다.

도 2는 클라이언트 인터셉트 및 서버 인터셉트를 이용하는 본 발명의 하나의 실시예에 따른 웹 브라우저/웹 서버 시스템의 블럭도이다.

도 3은 코히어런트 캐쉬 시스템을 이용하여 본 발명의 바람직한 실시예의 클라이언트측 인터셉트 모듈에 의해 수행되는 동작을 도시한 흐름도이다.

도 4는 코히어런트 캐쉬 시스템을 이용하여 본 발명의 바람직한 실시예의 클라이언트측 인터셉트 모듈에 의해 수행되는 동작을 도시한 흐름도이다.

도 5는 코히어런트 캐쉬 시스템을 이용하여 본 발명의 바람직한 실시예의 서버측 인터셉트 모듈에 의해 수행되는 동작을 도시한 흐름도

도 6은 코히어런트 캐쉬 시스템을 이용하여 본 발명의 바람직한 실시예의 서버측 인터셉트 모듈에 의해 수행되는 동작을 도시한 흐름도이다.

도 7은 상이한 데이타 전송 시스템을 이용하여 본 발명의 바람직한 실시예의 클라이언트측 인터셉트 모듈에 의해 수행되는 동작을 도시한 흐름도이다.

도 8은 상이한 데이타 전송 시스템을 이용하여 본 발명의 바람직한 실시예의 클라이언트측 인터셉트 모듈에 의해 수행되는 동작을 도시한 흐름도이다.

도 9는 상이한 데이타 전송 시스템을 이용하여 본 발명의 바람직한 실시예의 서버측 인터셉트 모듈에 의해 수행되는 동작을 도시한 흐름도이다.

도 10은 상이한 데이타 전송 시스템을 이용하여 본 발명의 바람직한 실시예의 서버측 인터셉트에 의해 수행되는 동작을 도시한 흐름도이다.

도 11은 가상 소켓을 이용하는 본 발명의 하나의 실시예의 블럭도이다.

도 12는 가상 소켓을 이용하는 본 발명의 하나의 실시예에 따른 클라이언트측 인터셉트 모듈 및 서버측 인터셉트 모듈의 블럭도이다.

도 13은 가상 소켓을 이용하여 본 발명의 하나의 실시예에 따른 클라이언트측 인터셉트 모듈 또는 서버측 인터셉트 모듈의 소켓 관리자에 의해 수행되는 동작을 도시한 흐름도이다.

도 14는 가상 소켓을 이용하여 본 발명의 하나의 실시예의 클라이언트측 인터셉트 함수에 의해 수행되는 동작을 도시한 흐름도이다.

도 15는 가상 소켓을 이용하여 본 발명의 하나의 실시예의 서버측 인터셉트 함수에 의해 수행되는 동작을 도시한 흐름도이다.

도 16-1은 가상 소켓을 이용하여 본 발명의 하나의 실시예에 따른 가상 생성 동작을 도시한 흐름도이다.

도 16-2는 가상 소켓을 이용하는 본 발명의 하나의 실시예에 따른 가상 전송 동작을 도시한 흐름도이다.

도 16-3은 가상 소켓을 이용하는 볼 발명의 하나의 실시예에 따른 가상 수신 동작을 도시한 흐름도이다.

도 16-4는 가상 소켓을 이용하는 본 발명의 하나의 실시예에 따른 가상 선택 동작을 도시한 흐름도이다.

도 17-1은 가상 소켓을 이용하는 본 발명의 하나의 실시예에 따른 가상 플러쉬 동작을 도시한 흐름도이다.

도 17-2는 가상 소켓을 이용하는 본 발명의 하나의 실시예에 따른 가상 폐쇄 동작을 도시한 흐름도이다.

전술한 문제점을 해결하기 위해, 본 발명의 목적은 캐쉬된 데이타를 갱신하지 않고서도 신뢰성 있는 데이타를 제공하는 캐쉬 시스템을 제공하는데 있다.

본 발명의 다른 목적은 웹 브라우저/서버 환경에 사용될 수 있는 캐쉬 구조를 제공하는데 있다.

본 발명의 또다른 목적은 웹 브라우저 또는 웹 서버 애플리케이션을 변경하지 않고서도 저속 또는 무선 통신 시스템의 기존의 통신 프로토콜 및 언어와 호환할 수 있도록 하는데 있다.

본 발명의 또다른 목적은 웹 브라우저와 웹 서버 사이에 요구되는 통신의 양을 줄여 통신 시스템의 성능이 향상되도록 하는 캐쉬 방법을 제공하는데 있다.

전술한 목적 및 다른 목적과 더불어, 본 발명은 제 1 애플리케이션으로부터 수신되고 제 2 애플리케이션으로부터의 요구에 응답하여 제 2 애플리케이션으로 제공되는 데이타를 캐쉬하는 방법을 제공한다. 본 발명의 방법은 제 1 애플리케이션으로부터 수신되고 제 2 애플리케이션으로 제공되는 데이타 스트림(data stream)을 캐쉬에 저장하여, 제 2 애플리케이션으로부터의 요구에 대응하는 클라이언트 캐쉬 엔트리(client cache entry)를 생성하는 단계를 포함한다. 또한, 본 발명의 방법은 클라이언트 캐쉬 엔트리가 생성된 시간을 저장하여 클라이언트 캐쉬 엔트리의 시간 기록(client cache entry time record)을 생성한다. 본 발명의 방법은 제 2 애플리케이션으로부터의 요구를 질의(interrogate)하여 요구에 대응하는 클라이언트 캐쉬 엔트리가 존재하는지를 판정한다. 만일 요구에 대응하는 클라이언트 캐쉬 엔트리가 존재하면, 제 2 애플리케이션으로부터의 요구에 대응하는 클라이언트 캐쉬 엔트리에 대한 클라이언트 캐쉬 엔트리 시간 기록을 평가(evaluate)하여, 제 2 애플리케이션이 정보를 요구하기 전에 사전설정된 클라이언트 코히어런시 시간 구간(predetermined client coherency time interval) 동안 제 2 애플리케이션으로부터의 요구에 대응하는 클라이언트 캐쉬 엔트리가 생성되었는지를 판정한다. 제 2 애플리케이션이 정보를 요구하기 전에 사전설정된 클라이언트 코히어런시 시간 구간 동안 제 2 애플리케이션에 대한 클라이언트 캐쉬 엔트리가 생성되었으면, 클라이언트 캐쉬 엔트리를 요구에 응답하는 제 2 애플리케이션에 제공한다. 또한, 본 발명은 제 2 애플리케이션의 다수의 인스탄스(instances)에 걸쳐 클라이언트 캐쉬 엔트리를 보유한다.

본 발명의 다른 실시예에 있어서, 제 1 애플리케이션은 제 1 컴퓨터에 상주하고, 제 2 애플리케이션은 제 2 컴퓨터에 상주하고, 제 1 및 제 2 애플리케이션은 외부 통신 링크를 통해 서로 통신한다. 또다른 실시예에 있어서, 본 발명은 제 2 애플리케이션으로부터의 요구에 응답하여 제 1 애플리케이션으로부터의 데이타 스트림을 제 1 컴퓨터에 상주하는 캐쉬에 저장하여 서버 요구 캐쉬 엔트리를 생성하는 방안을 포함한다. 본 발명은 제 2 애플리케이션에 의해 개시된 요구를 평가하여 요구에 대응하는 서버 요구 캐쉬 엔트리가 캐쉬내에 이전에 저장되었는지를 판정한다. 이어서, 제 2 애플리케이션으로부터의 요구에 대응하는 서버 요구 캐쉬 엔트리는 외부 통신 링크를 통해 제 2 컴퓨터에 상주하는 제 2 애플리케이션으로 전송된다.

본 발명의 또다른 부가적인 실시예에 있어서, 제 1 컴퓨터는 제 1 컴퓨터가 요구를 수신하기 전에 사전설정된 클라이언트 코히어런시 시간 구간 동안 제 2 애플리케이션으로부터의 요구에 대응하는 서버 요구 캐쉬 엔트리가 생성되었는지를 판정한다. 사전설정된 클라이언트 코히어런시 시간 구간 동안 서버 요구 캐쉬 엔트리가 생성되었으면, 제 2 애플리케이션으로부터의 요구에 대응하는 서버 요구 캐쉬 엔트리는 제 2 컴퓨터로 전송된다.

또한, 본 발명의 또다른 실시예는 요구에 대응하는 서버 캐쉬 엔트리와 동일한 제 2 애플리케이션으로부터의 요구에 대응하는 클라이언트 캐쉬 엔트리가 존재하는지를 판정하는 방안을 포함한다. 본 발명은 컴퓨터가 제 2 애플리케이션으로부터의 요구를 수신했을 때의 시간과 제 2 애플리케이션으로부터의 요구에 대응하는 서버 요구 캐쉬 엔트리가 생성되었을 때의 시간 사이의 시간 구간을 계산(calculate)하여 엔트리 수명 데이타(entry age data)를 제공한다. 제 2 애플리케이션으로부터의 요구에 대응하는 서버 캐쉬 엔트리에 대한 엔트리 수명 데이타는 제 2 컴퓨터에 상주하는 제 2 애플리케이션으로 전송되고, 제 2 애플리케이션으로부터의 요구에 대응하는 클라이언트 캐쉬 엔트리 시간 기록은 제 2 컴퓨터의 현재의 시간에서 제 1 컴퓨터로부터 수신된 엔트리 수명 데이타를 감산함으로써 갱신된다.

본 발명의 부가적인 실시예에 있어서, 제 2 애플리케이션은 웹 브라우저이고, 제 1 애플리케이션은 웹 서버이고, 제 1 및 제 2 컴퓨터는 무선 통신 링크를 통해 통신한다.

본 기술 분야에 통상의 지식을 가진 자라면, 전술한 본 발명의 실시예들이 장치 또는 컴퓨터에 의해 판독가능한 프로그램 수단을 구비한 프로그램 제품으로 또한 구현될 수도 있음을 이해할 것이다.

이하, 본 발명은 본 발명의 바람직한 실시예가 도시된 첨부된 도면을 참조하여 더욱 상세히 기술될 것이다. 그렇지만, 본 기술 분야에 통상의 지식을 가진 자라면, 본 발명은 본 발명을 완전히 이해하도록 제공된 본 발명의 실시예대신 본 발명의 영역을 벗어나지 않은 범위내에서 다수의 다른 형태로 제공될 수 있으며, 본 명세서에 개시된 실시예로 한정되지 않음을 이해할 것이다. 동일한 참조 부호는 동일한 구성 요소를 나타낸다.

도 3 내지 도 10과 도 13 내지 도 17-2는 본 발명에 따른 방법 및 시스템을 도시한 흐름도이다. 예시된 흐름도의 각각의 블럭과 예시된 흐름도의 블럭의 조합들은 컴퓨터 프로그램 인스트럭션에 의해 구현될 수도 있음을 이해하여야 한다. 이들 컴퓨터 프로그램 인스트럭션은 컴퓨터 또는 다른 프로그램가능한 장치상에서 실행하는 인스트럭션들이 흐름도의 블럭(들)에 지정된 함수를 실행하는 수단을 생성하도록 머신(machine)을 생성하는 컴퓨터 또는 다른 프로그램가능한 장치상으로 로딩될 수 있다. 이들 컴퓨터 프로그램 인스트럭션은 컴퓨터 또는 다른 프로그램가능한 장치를 특정한 방식으로 함수에 지정하는 컴퓨터에 의해 판독가능한 메모리에 또한 저장될 수 있으며, 이에 따라 컴퓨터에 의해 판독가능한 메모리에 저장된 인스트럭션은 흐름도의 블럭(들)에 지정된 함수를 실행하는 인스트럭션 수단을 포함하는 제조 물품을 생성시킬 수 있다. 또한, 컴퓨터 또는 다른 프로그램가능한 장치상에서 실행하는 인스트럭션들이 흐름도의 블럭(들)에 지정된 함수를 실행하는 단계들을 제공하기 위해, 컴퓨터 프로그램 인스트럭션들은 컴퓨터 또는 다른 프로그램가능한 장치에서 일련의 동작 단계들을 수행하여 컴퓨터에 의해 실행되는 프로세스를 생성하는 컴퓨터 또는 다른 프로그램가능한 장치상으로 로딩될 수 있다.

따라서, 예시된 흐름도의 블럭들은 지정된 함수를 수행하는 수단들의 조합과 지정된 함수를 수행하는 단계들의 조합을 지원한다. 예시된 흐름도의 각각의 블럭과 예시된 흐름도의 블럭의 조합은 지정된 함수 또는 단계를 수행하는 특수 목적의 하드웨어 기반의 컴퓨터 또는 특수 목적의 하드웨어 및 컴퓨터 인스트럭션의 조합에 의해 실행될 수도 있음을 이해하여야 한다.

도 2는 본 발명의 하나의 실시예를 도시한 도면이다. 도 2에 도시된 바와 같이, 웹 브라우저(10)는 클라이언트측 인터셉트 모듈(client-side intercept module: CSI)(30)과 통신한다. 웹 서버(20)는 서버측 인터셉트 모듈(server-side intercept module: SSI)(40)과 통신한다. 이어서, 클라이언트측 인터셉트 모듈(30)은 통신 링크(35)를 통해 서버측 인터셉트 모듈(40)과 통신한다. 웹 브라우저(10)와 클라이언트측 인터셉트 모듈(30)은 제 1 컴퓨터(5)내에 포함될 수 있다. 서버측 인터셉트 모듈(40)과 웹 서버(20)는 제 2 컴퓨터(6)내에 포함될 수 있다. 제 1 컴퓨터(5)와 제 2 컴퓨터(6)는 외부 통신 링크(35)를 통해 통신한다.

바람직하게, 웹 브라우저(10)는 HTTP 및 HTML을 이용하고 인터넷 웹 서버(20)와 통신하는 인터넷 웹 브라우저로서, 인터넷 웹 서버(20)도 HTTP 및 HTML을 또한 사용한다. 동작시, 웹 브라우저(10)는 클라이언트측 인터셉트 모듈(30)에 의해 인터셉트된 HTTP 데이타 스트림을 출력할 수 있다. 클라이언트측 인터셉트 모듈(30)에 의한 HTTP 데이타 스트림의 인터셉트는 클라이언트측 인터셉트 모듈(30)이 127.0.0.1과 같은 127 네트워크 번호를 갖는 IP 어드레스에서 상주하는 TCP/IP의 역 루프 형태(loop-back feature)를 이용함으로써 달성될 수 있다. 이어서, 클라이언트측 인터셉트 모듈(30)은 HTTP 데이타 스트림을 클라이언트/서버 지정 프로토콜로 변경하거나 혹은 변환하고, 클라이언트/서버 지정 데이타 스트림을 외부 통신 링크(35)상으로 전송한다. 서버 사이트 인터셉트 모듈(40)은 클라이언트/서버 지정 데이타 스트림을 수신하고, 웹 브라우저에 의해 개시되는 통신에 대응하는 원래의 HTTP 데이타 스트림을 재구성한다. 이어서, 재구성된 HTTP 데이타 스트림은 웹 서버(20)로 전송된다. 웹 서버(20)는 인터넷 웹 서버의 정규 방식으로 HTTP 데이타 스트림에 응답한다. 본 기술 분야에 통상의 지식을 가진 자라면 이해하듯이, 웹 서버(20)는 또한 다수의 브라우저가 인터넷에 접속하도록 하는 프락시일 수 있다.

예를 들어, 지정된 URL 홈 페이지에 대한 브라우저 요구에 응답하여 웹 서버(20)가 웹 브라우저(10)에 전송하기 위한 정보를 수신하면, 웹 서버(20)는 통신에 대응하는 HTTP 데이타 스트림을 웹 브라우저(10)로 출력한다. 이러한 웹 서버에 의해 개시되는 통신은 서버측 인터셉트 모듈(40)에 의해 인터셉트되고, 클라이언트/서버에 의해 지정된 데이타 스트림으로 변환된다. 이어서, 웹 서버에 의해 개시된 통신에 대응하는 클라이언트/서버 지정 데이타 스트림은 제 2 컴퓨터로부터 외부 통신 링크(35)를 통해 제 1 컴퓨터로 전송된다. 클라이언트/서버 지정 데이타 스트림은 클라이언트측 인터셉트 모듈(30)에 의해 수신되고, 웹 서버에 의해 개시된 통신에 대응하는 원래의 HTTP 데이타 스트림은 재구성되어 웹 브라우저(10)로 제공된다.

본 발명의 특정한 실시예에 있어서, 외부 통신 링크(35)는 무선 통신 링크이다. 이 경우, 사용자에게 허용가능한 성능을 갖춘 시스템을 제공하기 위해, 외부 통신 링크(35)상의 통신의 크기를 통신 링크(35)상으로 전송되는 통신 주파수 및 정보의 크기로 줄이는 것이 바람직하다. 따라서, 본 발명은 캐쉬 기법, 차분 기법 및 프로토콜 감축 기법을 이용하여 외부 통신 링크(35)상에서 필요로 하는 통신의 크기를 최소화할 수 있다. 이러한 기법들은 HTTP의 스테이트리스 프로토콜(stateless protocol) 또는 확률 프로토콜(stochastic protocol)을 클라이언트/서버 지정 프로토콜로 변환함으로써 구현되며, 클라이언트 서버 지정 프로토콜은 클라이언트 및 서버에 대해 지정된 정보를 이용하여 통신의 크기 및 빈도를 줄일 수 있다.

본 발명은 단일 웹 브라우저 애플리케이션 및 단일 웹 서버 애플리케이션에 대해 기술되지만, 본 기술 분야에 통상의 지식을 가진 자라면 이해하듯이, 본 발명의 이점 및 장점들은 단일 웹 서버와 관련된 다수의 웹 브라우저를 이용함으로써 또한 달성될 수 있다. 따라서, 본 발명의 방법, 장치 및 프로그램 제품은 클라이언트측 인터셉트 모듈 및 이들 클라이언트측 인터셉트 모듈과 각각 통신하는 다수의 브라우저와 함께 웹 서버 또는 웹 프락시의 서버측 인터셉트 모듈과 통신할 수 있다.

본 발명의 하나의 실시예에 있어서, 클라이언트측 인터셉트 모듈(30) 및 서버측 인터셉트 모듈(40)은 캐쉬 저장 능력을 갖는다. 제 1 컴퓨터에 상주하는 클라이언트 캐쉬는 웹 브라우저에 의해 개시된 통신에 응답하여 웹 브라우저에 의해 수신되는 HTTP 데이타 스트림을 저장한다. 제 2 컴퓨터에 상주하는 서버 캐쉬는 브라우저에 의해 개시된 통신에 응답하여 웹 서버로부터 수신되는 HTTP 데이타 스트림을 저장한다.

본 발명의 통상의 지식을 가진 자라면 이해하듯이, 제 1 컴퓨터 또는 제 2 컴퓨터에 상주하는 캐쉬는 컴퓨터의 지정 하드웨어 구성을 기초로 하여 소정의 크기를 가질 수 있다. 이들 캐쉬는 통신 URL과, 통신 데이타의 사이클 중복 검사(cyclic redundancy check: CRC)와 같이 통신 내용을 기초로 한 고유의 식별자와, 캐쉬 엔트리가 생성 또는 재생될 때의 시간을 나타내는 저장 날짜 시간(store date time: SDT)과, 통신 데이타를 포함하는 각각의 통신 정보를 저장한다. 따라서, 캐쉬내에 저장된 각각의 통신에 대한 캐쉬 엔트리의 디렉토리가 생성될 수 있다. 또한, 소정의 주어진 하드웨어 구성에서 이용할 수 있는 자원이 한정되어 있기 때문에, 본 기술 분야에 통상의 지식을 가진 자에게 잘 알려진 캐쉬 방안들 중 임의의 방안을 이용하여 제 1 컴퓨터 및 제 2 컴퓨터에 상주하는 캐쉬를 보유할 수 있다. 따라서, 예를 들어, 캐쉬는 새로운 엔트리를 추가할 때 사용자에 의해 정의된 캐쉬 사이즈가 초과되는 경우 가장 오래된 디렉토리 엔트리를 무효화하고, 무효화된 엔트리대신 새로운 엔트리를 추가할 수 있다. 또한, 웹 브라우저 또는 웹 서버 애플리케이션 또는 제 1 또는 제 2 컴퓨터의 전원 사이클의 다수의 인터탄스(instances)상에 캐쉬 엔트리를 보유할 수 있다.

이하, 클라이언트측 인터셉트 모듈(30) 및 서버측 인터셉트 모듈(40)의 동작을 기술한 흐름도인 도 3 내지 도 6을 참조하여 본 발명의 하나의 특징에 따른 캐쉬 구조의 동작이 기술될 것이다.

도 3을 참조하면, 블럭(100)은 클라이언트측 인터셉트 모듈(30)이 웹 브라우저(10)로부터의 요구를 수신한 것을 나타낸다. 이러한 요구는 HTTP 데이타 스트림의 형태를 취할 수 있다. 블럭(105)에서 클라이언트측 인터셉트 모듈(30)은 입력중인 요구의 URL을 검사한다. 클라이언트측 인터셉트 모듈(30)은 URL로부터 웹 브라우저에 의해 개시된 요구에 대응하는 정보가 이전에 제 1 컴퓨터에 상주하는 클라이언트 캐쉬내에 저장되었는지를 판정한다.

URL에 대응하는 정보가 클라이언트 캐쉬에 이전에 저장되지 않았으면, 클라이언트측 인터셉트 모듈에 의해 블럭(106)에 도시된 동작이 수행된다. 클라이언트측 인터셉트 모듈(30)은 요구를 외부 통신 링크(35)를 통해 서버측 인터셉트 모듈(40)에 전송한다.

그러나, 웹 브라우저에 의해 개시된 통신에 대한 질의 신호가 제공될 때 블럭(105)에 도시된 바와 같이 웹 브라우저에 의해 개시되는 통신에 대응하는 클라이언트 캐쉬 엔트리가 존재하면, 가장 간단한 실시예로 이 정보는 웹 브라우저에 HTTP 데이타 스트림으로서 제공될 수 있다. 그러나, 도 3에 도시된 바와 같이, 본 발명의 바람직한 실시예는 웹 브라우저에 의해 개시되는 통신에 대응하는 캐쉬 엔트리상에서 코히어런시 인터벌 검사(coherency interval check)를 수행한다. 이러한 동작은 도 3의 블럭(110)에 도시되어 있다.

클라이언트측 인터셉트 모듈의 코히어런시 인터벌은 사용자에 의해 정의될 수 있고, 캐쉬 엔트리가 무효화되기 전에 존재하는 시간 주기이며, 만일 캐쉬 엔트리가 존재하면 캐쉬 엔트리는 웹 서버로부터 웹 브라우저에 의해 개시된 통신에 대응하는 정보를 요구함으로써 필수적으로 재생된다. 블럭(110)에 도시된 코히어런시 인터벌 검사는 현재의 날짜 및 시간을 웹 브라우저에 의해 개시된 통신에 대응하는 캐쉬 엔트리의 SDT와 사용자에 의해 지정된 코히어런시 인터벌의 합과 비교함으로써 이루어질 수 있다. 현재의 날짜 및 시간이 전술한 합보다 크면, 웹 브라우저에 의해 개시되는 통신에 대응하는 캐쉬에 저장된 정보는 무효화되고 블럭(110)의 부정 경로가 선택된다. 그러나, 현재의 날짜 및 시간이 SDT와 사용자에 의해 정의된 코히어런시 인터벌의 합보다 적으면, 블럭(111)에 도시된 바와 같이, 블럭(110)의 긍정 경로가 선택되고, 캐쉬 엔트리는 브라우저에 HTTP 데이타 스트림으로서 제공된다. 그러면, 도 3의 블럭(100)의 클라이언트측 인터셉트 모듈(30)에 의해 수신된 브라우저 개시 통신은 완료된다.

블럭(110)에 도시된 코히어런시 인터벌 검사에서 제 1 컴퓨터에 상주하는 캐쉬 엔트리가 무효인 것으로 판정되면, 서버측 인터셉트 모듈(40)에 대한 요구를 생성하여 제 2 컴퓨터에 상주하는 캐쉬 엔트리의 코히어런시를 검사한다. 이러한 동작은 도 3의 블럭(112)에 도시되어 있다. 이것은 특정한 클라이언트측 인터셉트 모듈(30)에 대한 코히어런시 인터벌과, 웹 브라우저(10)에 의해 개시된 HTTP 요구와, 웹 브라우저에 의해 개시된 통신의 URL에 대응하는 클라이언트 캐쉬의 내용의 고유의 표시신호를 외부 통신 링크(35)를 거쳐 서버측 인터셉트 모듈(40)에 제공함으로써 달성된다. 바람직한 실시예에 있어서, 고유의 표시신호는 캐쉬 엔트리에 대한 CRC의 결과이다.

도 5를 참조하면, 클라이언트측 인터셉트 모듈(30)로부터 외부 통신 링크(35)를 통해 수신된 정보에 응답하여 수행하는 서버측 인터셉트 모듈의 동작이 도시되어 있다. 서버측 인터셉트 모듈(40)이 클라이언트측 인터셉트 모듈로부터의 요구를 수신할 때, 서버측 인터셉트 모듈(40)은 사전설정된 클라이언트 코히어런시 시간 인터벌, 클라이언트 캐쉬 엔트리에 대한 CRC 값 및 웹 브라우저에 의해 개신된 HTTP 요구를 수신한다. 이러한 정보의 수신은 도 5의 블럭(120)에 도시되어 있다.

클라이언트측 인터셉트 모듈(30)로부터 정보를 수신한 후, 서버측 인터셉트 모듈(40)은 제 2 컴퓨터에 상주하는 서버 캐쉬를 검사하여, 웹 브라우저에 의해 개시된 HTTP 요구의 URL에 대응하는 서버 캐쉬 엔트리가 존재하는지를 판정한다. 만일 조건이 충족되면, 블럭(125)에 도시된 바와 같이, 웹 브라우저에 의해 개시되는 통신에 대한 질의신호를 제공한 후, 서버측 인터셉트 모듈(40)이 웹 브라우저에 의해 개시되는 통신에 의해 요구된 정보에 대응하는 캐쉬 엔트리가 존재하는 것으로 판정하면, 블럭(125)의 긍정 경로가 선택된다. 이어서, 서버측 인터셉트 모듈(40)은 SSI 모듈(40)의 현재의 날짜 및 시간을 웹 브라우저에 의해 개시된 통신에 의해 요구된 정보에 대응하는 서버 캐쉬 엔트리의 SDT와 클라이언트측 인터셉트 모듈로부터 수신된 사전설정된 클라이언트 코히어런시 시간 인터벌의 합과 비교한다.

현재의 날짜 및 시간이 서버 캐쉬 엔트리 및 코히어런시 인터벌에 대한 SDT의 합보다 적으면, 도 5의 블럭(130)의 긍정 경로가 선택된다. 이어서, 서버측 인터셉트 모듈(40)은 서버 캐쉬 엔트리의 CRC를 클라이언트 캐쉬 엔트리의 CRC와 비교하여, 두개의 캐쉬 엔트리가 동일한지를 판정한다. 두개의 캐쉬 엔트리가 동일하면, 블럭(136)에 도시된 바와 같이 블럭(135)의 긍정 경로가 선택되고, 코히어런트 응답은 클라이언트측 인터셉트 모듈(30)로 제공된다.

블럭(135)의 조건에서 CRC가 동일하지 않은 것으로 판정되면, 클라이언트 캐쉬와 서버 캐쉬에 포함된 정보는 동일하지 않으며, 블럭(137)에 도시된 바와 같이 서버측 인터셉트 모듈은 서버 캐쉬 엔트리를 외부 통신 링크를 통해 제 1 컴퓨터에 제공한다. 서버 캐쉬 엔트리를 클라이언트측 인터셉트 모듈(30)에 전송시, 서버측 인터셉트 모듈은 엔트리를 클라이언트 지정 통신 프로토콜로 변환하며, 이 프로토콜은 서버 캐쉬 엔트의 CRC와, 서버 캐쉬 엔트리의 데이타와, 서버 캐쉬 엔트리의 수명(age)를 포함한다. 서버 캐쉬 엔트리의 수명은 현재의 날짜 및 시간과 캐쉬 엔트리의 SDT를 감산함으로써 계산된다.

마지막으로, 도 5를 참조하면, SDT와 사전설정된 클라이언트 코히어런시 시간 인터벌간의 합이 현재의 날짜 및 시간보다 적거나 또는 웹 브라우저에 의해 개시된 통신의 URL에 대응하는 캐쉬 엔트리가 존재하지 않으면, 블럭(130)의 부정 경로 또는 블럭(125)의 부정 경로가 각각 선택된다. 그러면, 블럭(126)의 동작이 수행되고, 서버측 인터셉트 모듈(40)은 웹 브라우저에 의해 개시된 통신을 서버에 HTTP 데이타 스트림으로서 전송할 것이다. 서버측 인터셉트 모듈(40)이 웹 브라우저에 의해 개시된 통신을 서버에 HTTP 데이타 스트림으로서 전송하는 경우, 서버측 인터셉트 모듈(40)은 도 6의 동작을 실행할 것이다.

도 6의 블럭(140)에 도시된 바와 같이, 웹 브라우저에 의해 개시된 통신에 응답하여 서버측 인터셉트 모듈은 웹 서버(20)로부터 HTTP 데이타 스트림을 수신할 것이다. HTTP 데이타 스트림을 수신하면, 서버측 인터셉트 모듈(40)은 HTTP 데이타 스트림에 대한 CRC를 계산하고, HTTP 데이타 스트림을 임시 저장할 것이다. 이어서, 블럭(145)에 도시된 바와 같이, 서버측 인터셉트 모듈은 HTTP 데이타 스트림을 질의하여, HTTP 데이타 스트림의 URL에 대응하는 서버 캐쉬 엔트리가 존재하는지를 판정한다. 만일 엔트리가 존재하면, 블럭(145)의 긍정 경로가 선택된다. 이어서, 블럭(150)에 도시된 바와 같이, 서버측 인터셉트 모듈(40)은 웹 서버(20)로부터 수신된 HTTP 데이타 스트림의 최근에 계산된 CRC를 웹 서버에 의해 개시된 응답 통신의 URL에 대응하는 서버 캐쉬 엔트리의 CRC와 비교한다. 이들 CRC가 동일하면, 블럭(150)의 긍정 경로가 선택된다. 서버측 인터셉트 모듈(40)은 블럭(151)에 도시된 바와 같이 서버 캐쉬 엔트리에 대한 SDT 엔트리를 갱신하고, 블럭(152)에 도시된 바와 같이 웹 서버(20)에 의해 수신된 임시 저장장치로부터의 HTTP 데이타 스트림을 삭제한다.

CRC의 비교 결과 서버 캐쉬 엔트리가 웹 서버(20)로부터 수신된 HTTP 데이타 스트림과 다른 것으로 나타나면, 블럭(150)의 부정 경로가 선택된다. 서버측 인터셉트 모듈(40)은 블럭(153)에 도시된 바와 같이 서버 캐쉬로부터 기존의 데이타를 제거하고, 이어서 블럭(154)에 도시된 바와 같이 새로운 정보를 갖는 서버 캐쉬를 갱신한다. 블럭(154)에 도시된 바와 같이, 이러한 갱신은 웹 서버 통신의 CRC를 서버 캐쉬에 저장하는 단계와, 캐쉬 엔트리에 대한 SDT와 동일한 현재의 날짜 및 시간을 캐쉬 엔트리의 일부로서 저장하는 단계와, HTTP 데이타 스트림을 저장하는 단계를 포함한다. 이 경우, 서버 캐쉬 엔트리가 갱신되거나 혹은 서버 캐쉬 엔트리가 웹 서버(20)로부터 수신된 HTTP 데이타 스트림과 동일한 것으로 검출되면, 서버측 인터셉트 모듈은 서버 캐쉬 엔트리가 웹 브라우저에 의해 개시되는 통신에 대응하는 클라이언트 캐쉬 엔트리와 동일한지를 판정한다. 이러한 동작은 블럭(155)에 도시되어 있다.

웹 서버(20)로부터 수신된 응답에 대응하는 캐쉬 엔트리가 서버측 인터셉트 모듈(40)에 의해 존재하지 않은 것으로 판정되면, 블럭(145)의 부정 경로가 선택된다. 블럭(146)에 도시된 바와 같이 서버 캐쉬 엔트리는 웹 서버로부터의 응답의 URL을 저장하고, 웹 서버로부터의 응답의 CRC를 저장하고, HTTP 데이타 스트림을 저장하고, 현재의 날짜 및 시간을 SDT로서 저장함으로써 생성된다. 웹 브라우저에 의해 개시된 통신에 대응하는 캐쉬 엔트리를 생성한 후, 블럭(155)에 도시된 바와 같이 서버측 인터셉트 모듈(40)은 이 서버 캐쉬 엔트리의 CRC를 대응하는 클라이언트 캐쉬 엔트리의 CRC와 다시 비교한다.

서버 캐쉬 엔트리와 클라이언트 캐쉬 엔트리의 비교 결과 이들 캐쉬 엔트리가 동일한 것으로 나타나면, 블럭(155)의 긍정 경로가 선택되고, 블럭(156)의 동작이 수행된다. 블럭(156)에 도시된 바와 같이, 서버측 인터셉트 모듈(40)은 코히어런트 응답을 클라이언트측 인터셉트 모듈(30)에 전송한다. 코히어런트 응답을 전송하고 제로의 수명을 클라이언트측 인터셉트 모듈에 전송함으로써, 서버측 인터셉트 모듈(40)은 서버 요구 캐쉬 엔트리를 클라이언트/서버 지정 데이타 스트림으로 변환시킨다.

서버측 인터셉트 모듈(40)에 의해 클라이언트 캐쉬 엔트리가 웹 브라우저에 의해 개시된 통신에 대응하는 서버 캐쉬 엔트리와 동일하지 않은 것으로 판정되면, 블럭(155)의 부정 경로가 선택되고, 블럭(157)의 동작이 수행된다. 블럭(157)에 도시된 바와 같이, 서버측 인터셉트 모듈(40)은 서버 캐쉬 엔트리를 클라이언트/서버 지정 데이타 스트림으로 변경하거나 혹는 변환시킨다. 데이타 스트림은 서버 캐쉬 엔트리의 CRC와, 서버 캐쉬 엔트리의 HTTP 데이타 스트림과, 제로로 세트된 캐쉬 엔트리의 수명을 포함한다. 이어서, 이러한 클라이언트/서버 지정 통신은 외부 통신 링크(35)를 통해 클라이언트측 인터셉트 모듈(30)로 전송된다.

이하, 서버측 인터셉트 모듈로부터 통신을 수신할 때의 클라이언트측 인터셉트 모듈(30)의 함수를 도 4를 참조하여 기술할 것이다. 블럭(160)에 도시된 바와 같이, 클라이언트측 인터셉트 모듈(30)은 외부 통신 링크(35)를 통해 제공된 클라이언트/서버 지정 데이타 스트림을 수신하거나 혹은 획득한다. 이어서, 블럭(165)에 도시된 바와 같이 클라이언트측 인터셉트 모듈은 서버측 인터셉트 모듈(40)로부터 수신된 응답의 유형이 어떤 것인지를 판정한다. 서버측 인터셉트 모듈(40)에 의해 클라이언트 캐쉬 엔트리가 코히어런트인 것으로 나타나면, 즉, 서버 캐쉬 엔트리와 클라이언트 캐쉬 엔트리가 동일한 것으로 나타나면, 블럭(166)에 도시된 동작이 수행된다. 블럭(166)에 도시된 바와 같이, 클라이언트측 인터셉트 모듈(30)은 현재의 날짜 및 시간과 서버측 인터셉트 모듈(40)로부터 수신된 수명간의 차이를 이용하여 웹 브라우저에 의해 개시된 통신에 대응하는 클라이언트 캐쉬 엔트리의 SDT를 갱신한다. 따라서, 제 1 컴퓨터(5)와 제 2 컴퓨터(6)의 두개의 클럭을 동기화시키지 않고서도 본 발명은 제 1 컴퓨터의 캐쉬 엔트리의 코히어런시 시간을 정정하여 제 2 컴퓨터의 새로운 데이타를 나타날 수 있다. 웹 브라우저에 의해 개시되는 통신에 대응하는 클라이언트 캐쉬 엔트리의 SDT를 갱신한 후, 클라이언트측 인터셉트 모듈(30)은 클라이언트 캐쉬 엔트리를 웹 브라우저(10)에 HTTP 데이타 스트림으로서 제공한다. 이러한 동작을 블럭(174)에 도시되어 있다.

그라나, 클라이언트측 인터셉트 모듈(30)에 의해 응답 유형이 데이타 또는 데이타 스트림 응답인 것으로 판정되면, 블럭(165)의 스트림 경로가 선택되고, 블럭(167)의 동작이 수행된다. 클라이언트측 인터셉트 모듈(30)은 HTTP 데이타 스트림을 수신하고 이 데이타를 임시 저장한다. 이어서, 도 4의 블럭(170)에 도시된 바와 같이, 클라이언트측 인터셉트 모듈(30)은 웹 브라우저에 의해 개시되는 통신에 대응하는 캐쉬 엔트리가 존재하는지를 판정한다. 캐쉬 엔트리가 존재하면, 블럭(170)의 긍정 경로가 선택되고, 블럭(171)에 도시된 바와 같이 현재의 캐쉬 엔트리가 플러쉬(flush)된다. 이어서, 클라이언트측 인터셉트 모듈은 서버측 인터셉트 모듈(40)로부터 수신된 HTTP 데이타 스트림의 CRC를 저장하고, 현재의 날짜 및 시간과 서버측 인터셉트 모듈(40)로부터 수신된 수명간의 차이를 SDT로서 저장하고, HTTP 데이타 스트림을 저장함으로써, 웹 브라우저에 의해 개시된 통신에 대응하는 클라이언트 캐쉬 엔트리를 갱신한다. 이러한 동작은 블럭(172)에 도시되어 있다.

웹 브라우저에 의해 개시되는 통신에 대응하는 캐쉬 엔트리가 존재하지 않으면, 블럭(170)의 부정 경로가 선택된다. 클라이언트 캐쉬 엔트리는 블럭(173)에 도시된 동작을 수행함으로써 생성된다. 블럭(173)에 도시된 바와 같이, 클라이언트측 인터셉트 모듈(30)은 서버측 인터셉트 모듈(40)로부터 수신된 HTTP 데이타 스트림의 URL을 저장하고, 서버측 인터셉트 모듈(40)로부터 수신된 HTTP 데이타 스트림의 CRC를 저장하고, HTTP 데이타 스트림을 저장함으로써, 클라이언트 캐쉬 엔트리를 생성한다. 또한, 클라이언트측 인터셉트 모듈(30)은 현재의 날짜 및 시간에서 서버측 인터셉트 모듈(40)로부터 외부 통신 링크(35)를 통해 수신된 수명을 감산함으로써 SDT를 갱신하거나 혹은 SDT를 저장한다.

하지만, 클라이언트측 인터셉트 모듈이 클라이언트 캐쉬 엔트리를 웹 브라우저(10)에 HTTP 데이타 스트림으로서 전송하거나 혹은 제공하는데 블럭들(166, 172 또는 173) 중 어떠한 블럭을 선택해서 동작을 행하더라도 클라이언트 캐쉬 엔트리가 생성된다. 이들 동작은 도 4의 블럭(174)에 도시되어 있다.

본 기술 분야에 통상의 지식을 가진 자라면 이해하듯이, 클라이언트 캐쉬 및 서버 캐쉬는 메모리로 구현되거나 혹은 하드 디스크, 판독/기록 CD-ROM, 광 디스크 또는 다른 저장 기술과 같은 대량 저장장치로 구현될 수 있다. 또한, 본 기술 분야에 통상의 지식을 가진 자라면 이해하듯이, 클라이언트측 인터셉트 모듈과 서버측 인터셉트 모듈은 소프트웨어, 하느웨어 또는 이들을 조합하여 구현될 수 있다.

본 발명은 특정한 제 1 또는 제 2 컴퓨터에 상주하는 캐쉬를 참조하여 기술하였지만, 본 기술 분야에 통상의 지식을 가진 자라면 이해하듯이, 캐쉬를 제 1 컴퓨터에 상주시키지 않고 단순히 컴퓨터와 동일한 외부 통신 링크측상에 위치시켜도 본 발명을 구현할 수 있다. 따라서, 하드웨어 캐쉬는 클라이언트 캐쉬로서 수행하는 제 1 컴퓨터 외부에서 구현되고 고속 통신에 의한 제 1 컴퓨터에 접속될 수 있으며, 캐쉬를 제 1 컴퓨터와 동일한 외부 통신 링크측에 위치시키면 본 발명의 장점들이 구현될 수 있다.

본 발명의 또다른 실시예에 있어서, 서버측 인터셉트 모듈(40)은 웹 서버(20)로부터 수신된 HTTP 데이타 스트림의 사본을 보유하지 않고, 단순히 통신에 대한 디렉토리 엔트리만을 보유한다. 디렉토리 엔트리는 통신 URL과, HTTP 데이타 스트림에 대해 계산된 CRC 및 HTTP 데이타 스트림이 웹 서버로부터 수신된 시간과, CRC가 계산될 때의 시간으로 세트되는 통신 SDT를 포함할 수 있다. 이 경우, 클라이언트측 인터셉트 모듈(30)에 의해 서버측 인터셉트 모듈이 CTC 및 SDT를 보유한 URL에 대응하는 통신 서버 사이트 인터셉트 모듈(40)에 요구가 전송되면, 서버측 인터셉트 모듈은 클라이언트측 인터셉트 모듈(30)로부터 수신된 CRC를 검사하고, 이 CRC가 지정된 URL에 대해 가장 나중의 HTTP 데이타 스트림의 CRC에 대응하는지를 판정한다. 만일 정합이 이루어지면, 코히어런트 응답이 클라이언트측 인터셉트 모듈에 제공된다. 정합이 이루어지지 않으면, 서버측 인터셉트 모듈은 클라이언트측 인터셉트 모듈로부터 수신된 HTTP 데이타 스트림을 웹 서버(20)에 전송하고, 웹 서버(20)로부터 수신된 응답을 클라이언트측 인터셉트 모듈(30)로 반환시킨다.

차분 기법을 이용하여 외부 통신 링크(35)를 통해 제공되는 데이타를 줄이는 본 발명의 다른 실시예에 있어서, 도 7, 8, 9 및 10은 클라이언트측 인터셉트 모듈(30) 및 서버측 인터셉트 모듈(40)에 의해 수행되는 동작을 도시한 도면이다. 도 7에 도시된 바와 같이, 블럭(200)에서 클라이언트측 인터셉트 모듈(30)은 웹 브라우저(10)로부터 HTTP 요구를 수신한다. 블럭(205)에 도시된 바와 같이, 클라이언트측 인터셉트 모듈(30)은 웹 브라우저(10)로부터 인터셉트된 HTTP 요구를 질의하여 이 요구가 공통 게이트웨이 인터페이스(CGI)에 관한 것인지를 판정한다. 만일 요구가 공통 게이트웨이 인터페이스에 관한 것이 아니면, 도 3 내지 도 6에 도시되고 도 7의 블럭(206)으로 도시된 바와 같이 클라이언트측 인터셉트 모듈(30)은 요구를 서버측 인터셉트 모듈에 제공한다.

그러나, 웹 브라우저에 의해 개시된 통신이 CGI 요구에 대응하면, 블럭(205)의 긍정 경로가 선택된다. 블럭(210)에 도시된 바와 같이, 대응하는 CGI 요구에 응답하여 클라이언트/서버 인터셉트 모듈(30)은 웹 브라우저에 이전에 제공된 HTTP 데이타 스트림에 대응하는 클라이언트 기본 캐쉬 엔트리가 존재하는지를 판정한다. 이러한 CGI 요구의 질의는 웹 브라우저에 의해 개시된 통신 URL을 클라이언트 기본 캐쉬에 저장된 URL과 비교함으로써 달성될 수 있다.

클라이언트 기본 캐쉬는 클라이언트측 인터셉트 모듈(30)에 의해 수신되어 주어진 URL에 대해 웹 브라우저(10)로 제공되는 제 1 HTTP 데이타 스트림을 저장함으로써 초기화될 수 있다. 웹 브라우저(10)의 다수의 인스탄스 또는 세션(sessions)을 통해 이러한 클라이언트 기본 캐쉬 엔트리를 보유할 수 있다. 클라이언트 기본 캐쉬 엔트리는 도 7, 8, 9 및 도 10에 도시된 바와 같이 갱신될 수 있다. 웹 브라우저에 의해 개시된 통신에 대한 URL에 대응하는 클라이언트 기본 캐쉬 엔트리가 존재하면, 외부 통신 링크(35)를 통해 서버측 인터셉트 모듈(40)에 전송되는 CRC는 도 7의 블럭(211)에 도시된 바와 같이 클라이언트 기본 캐쉬 엔트리에 대한 CRC와 동일하게 세트된다. 클라이언트 기본 캐쉬 엔트리가 존재하지 않으면, 도 7의 블럭(210)의 부정 경로가 선택되고, 외부 통신 링크(35)를 통해 서버측 인터셉트 모듈(40)에 전송되는 요구에 대한 CRC는 널(null)된다. 이러한 동작은 도 7의 블럭(212)에 도시되어 있다.

블럭(213)은 CGI 요구를 외부 통신 링크를 통해 서버측 인터셉트 모듈(40)에 전송하는 동작을 도시한 것이다. 블럭(213)에 도시된 바와 같이, 클라이언트측 인터셉트 모듈(30)은 HTTP 요구와, CGI 요구의 URL에 대한 클라이언트 기본 캐쉬 엔트리가 존재하지 않은 경우 널로 세트되고 엔트리가 존재하는 경우 클라이언트 기본 캐쉬 엔트리의 CRC로 세트되는 CRC 요구를 전송한다. 따라서, 클라이언트측 인터셉트 모듈은 CGI 요구를 클라이언트/서버 지정 프로토콜로 변경하고, 클라이언트/서버 지정 통신을 서버측 인터셉트 모듈(40)에 의해 수신되는 외부 통신 링크상으로 전송하였다.

도 9에는 CGI 요구가 수신될 때 서버측 인터셉트 모듈에 의해 취해진 동작이 도시되어 있다. 블럭(220)에는 서버측 인터셉트 모듈(40)에 의한 CGI 요구 수신이 도시되어 있다. 서버측 인터셉트 모듈(40)이 CGI 요구를 수신하면 모듈(40)은 CRC의 값 및 HTTP 요구의 사본을 저장한다. 블럭(221)에 도시된 바와 같이, 서버측 인터셉트 모듈(40)은 HTTP 요구를 웹 서버(20)에 제공한다.

서버측 인터셉트 모듈(40)이 웹 브라우저에 의해 개시된 통신에 대응하는 HTTP 요구 또는 CGI 요구에 대한 응답을 수신하면, 도 10의 블럭(230)에 도시된 바와 같이 서버측 인터셉트 모듈(40)은 이 응답을 HTTP 데이타 스트림으로서 수신한다. 블럭(230)에 도시된 바와 같이, 서버측 인터셉트 모듈(40)은 HTTP 데이타 스트림을 저장하고, 웹 서버(20)로부터 수신된 HTTP 데이타 스트림에 대한 CRC 값을 계산한다. 또한, 서버측 인터셉트 모듈(40)은 차분값을 널화하여 차분 데이타를 초기화한다. 이어서, 블럭(235)에 도시된 바와 같이 서버측 인터셉트 모듈은 웹 서버에 의해 개시된 통신으로서 수신된 응답이 CGI에 대한 응답인지를 판정한다. 만일 응답이 부정이면, 도 10의 블럭(235)의 부정 경로가 선택되고, 블럭(236)의 동작을 실행하여 HTTP 데이타 스트림을 클라이언트측 인터셉트 모듈에 전송한다. 블럭(236)에 도시된 바와 같이, 이러한 동작은 도 3 내지 도 6에 도시된 캐쉬 동작을 포함할 수 있다. 블럭(230)에 수신된 응답이 CGI 응답이면, 블럭(235)의 긍정 경로가 선택되고, 이어서 블럭(240)에 도시된 바와 같이 서버측 인터셉트 모듈은 CGI 응답에 대한 서버 기본 캐쉬 엔트리가 존재하는지를 판정한다.

서버측 인터셉트 모듈(40)이 CGI 요구에 대한 응답을 수신하는 제 1 시간 동안 서버 기본 캐쉬 엔트리가 생성될 수 있다. 이 경우, 블럭(240)에 도시된 조건 결과에 따라 블럭(240)의 부정 경로가 선택될 것이다. 이어서, 서버측 인터셉트 모듈(40)은 CGI에 대한 URL과, CGI 요구에 응답하는 HTTP 데이타 스트림과, HTTP 데이타 스트림에 대한 CRC를 저장함으로써 CGI 요구에 대응하는 서버 기본 캐쉬 엔트리를 생성한다. 이러한 동작은 블럭(241)에 도시되어 있다. 도 3 내지 도 6에 예시된 코히어런트 캐쉬 시스템을 비교해 보면, 서버 기본 캐쉬 엔트리는 SDT를 또한 포함할 수 있다. 본 명세서에 사용된 서버 CGI의 기본 형태는 웹 브라우저(10)로부터 수신된 CGI 요구에 대응하는 서버 기본 캐쉬 엔트리로 지칭한다.

CGI 요구에 대응하는 서버 기본 캐쉬 엔트리가 존재하면, 블럭(240)의 긍정 경로가 선택된다. 서버측 인터셉트 모듈은 서버 기본 캐쉬 엔트리의 CRC를 웹 서버(20)로부터 수신된 응답의 CRC과 비교한다. 이러한 동작은 도 10의 블럭(245)에 도시되어 있다. 이들 CRC가 동일하면, 서버측 인터셉트 모듈은 서버 기본 캐쉬 엔트리에 대한 CRC가 클라이언트 기본 캐쉬 엔트리에 대한 CRC에 대응한다. 이들 두 CRC 값이 동일하면, 클라이언트 기본 캐쉬 엔트리, 서버 기본 캐쉬 엔트리 및 웹 서버(20)로부터 수신된 응답은 모두 동일한 HTTP 데이타 스트림을 포함한다. 서버 기본 캐쉬 엔트리와 클라이언트 기본 캐쉬 엔트리의 비교는 블럭(250)에 도시되어 있다.

이들 두 기본 캐쉬 엔트리가 동일하면, 서버측 인터셉트 모듈은 전술한 기본 캐쉬 엔트리를 클라이언트측 인터셉트 모듈(30)에 전송할 필요가 없으므로, 블럭(251)에 도시된 바와 같이 클라이언트측 인터셉트 모듈(30)에 전송되는 HTTP 데이타 스트림 데이타는 널화된다. 이어서, 블럭(252)에 도시된 바와 같이, CGI 요구에 대응하는 서버 기본 캐쉬에 저장된 HTTP 데이타 스트림의 CRC와, 널화된 HTTP 데이타 스트림 데이타와, 널화된 차분 데이타를 전송하여 CGI 요구에 대한 응답이 클라이언트 기본 캐쉬 엔트리와 동일함을 나타내기 위해, 서버측 인터셉트 모듈(40)은 웹 서버(20)로부터 수신된 HTTP 데이타 스트림을 클라이언트/서버 지정 통신 프로토콜로 변환된다.

블럭(245)을 참조하면, 웹 브라우저에 의해 개시된 CGI 요구에 응답하여 CGI 요구에 대응하는 서버 기본 캐쉬 엔트리에 대한 CRC가 웹 서버로부터 수신된 응답에 대한 CRC와 상이하면, 블럭(245)의 부정 경로가 선택된다. 이어서, 서버측 인터셉트 모듈(40)은 블럭(246)에 도시된 동작을 수행한다. 서버측 인터셉트 모듈(40)은 인터셉트된 CGI 응답을 인트셉트된 CGI 요구 또는 서버 CGI의 기본 형태에 대응하는 서버 기본 캐쉬 엔트리와 비교한다. 이러한 서버 CGI 기본 형태에 대해 인터셉트된 CGI 응답과 서버 CGI의 기본 형태와의 비교에서는 인터셉트된 CGI 응답과 서버 CGI의 기본 형태간의 차에 대응하는 CGI 차분 데이타를 제공한다.

기본 형태와 변경된 형태간의 차이를 판정하는 차분 동작은 본 기술 분야에 통상의 지식을 가진 자에게 잘 알려져 있는 소정의 방법으로 수행될 수 있다. 본 발명에서 사용하는데 적절한 차분 동작의 하나의 방법은 카피터스(Coppieters)에 의해 기술되어a Cross-platform Binary Diff이란 명칭의Dr. Dobb's Journal, May 1995, pp. 32-36의 문헌에 개시되어 있으며, 이는 본 발명의 참조로 인용된다. 차분 데이타를 판정하는데 사용되는 다른 방안은IBM Technical Disclosure Bulletin, Vol. 22, No. 8A, January 1980의 문헌에 개시되어 있으며, 이는 본 발명의 참조로 인용된다.

이어서, 블럭(247)에 도시된 바와 같이 서버측 인터셉트 모듈(40)은 서버 CGI의 기본 형태를 갱신해야 하는지를 판정한다. 이러한 판정은 인터셉트된 CGI 응답과 서버 CGI의 기본 형태간의 평균 차분 데이타가 서전정의된 임계치를 초과하는지를 판정함으로써 결정될 수 있다. CGI 요구에 대응하는 서버의 기본 캐쉬 엔트리를 갱신해야 하는지를 판정하는 다른 방안은 도 3 내지 도 6에 개시된 것과 같은 시간 코히어런시를 포함하거나 혹은 새로운 기본 캐쉬 엔트리를 생성하여 재기준화(rebase)하여 시스템의 성능이 향상될 정도로 차분 데이타가 증가되었는지를 판정하는 본 기술 분야에 통상의 지식을 가진 자에게 잘 알려진 다른 방안들을 포함할 수 있다.

서버의 재기준화가 필요치 않으면, 블럭(247)의 부정 경로가 선택되고, 서버측 인터셉트 모듈(40)은 블럭(250)의 동작을 수행하여 클라이언트 기본 캐쉬 엔트리의 CRC가 서버 기본 캐쉬 엔트리의 것과 동일한지 혹은 서버 CGI 기본 형태가 웹 브라우저에 의해 개시된 통신의 특정한 CGI 요구에 대응하는 서버 및 클라이언트의 기본 캐쉬 엔트리인 클라이언트 CGI 기본 형태와 동일한지를 판정한다. 이들 기본 형태가 동일하면, 블럭(251)에 도시된 바와 같이 클라이언트는 재기준화될 필요가 없으며, HTTP 데이타 스트림 정보는 널화된다. 이어서, 서버측 인터셉트 모듈(40)은 CGI 요구에 대응하는 서버 기본 캐쉬 엔트리의 CRC(즉, 서버 CGI 기본 형태의 CRC)를 전송하고, 기본 데이타에 대응하는 널화된 HTTP 데이타 스트림을 전송하고, 블럭(246)에서 결정된 차분 데이타를 전송함으로써, 차분 응답을 클라이언트측 인터셉트 모듈(30)에 전송한다. 이러한 동작은 도 10의 블럭(252)에 도시되어 있다.

서버측 인터셉트 모듈(40)에 의해 클라이언트 CGI 기본 형태 및 서버 CGI 기본 형태에 대한 이들 CRC가 동일하지 않은 것으로 판정되면, 클라이언트는 재기준화될 필요가 없다. 클라이언트의 재기준화 동작에서는 서버 CGI 기본 형태를 클라이언트측 인터셉트 모듈(30)에 전송하는 단계를 포함한다. 이러한 동작을 수행하기 위해 서버측 인터셉트 모듈은 서버 CGI의 기본 형태와 동일한 클라이언트측 인터셉트 모듈(30)에 전송될 HTTP 데이타 스트림 데이타를 세트시킨다. 이러한 동작은 블럭(253)에 도시되어 있다. 이어서, 블럭(252)에 도시된 바와 같이, 서버측 인터셉프 모듈(40)은 서버 CGI의 기본 형태의 CRC와, 서버 CGI의 기본 형태에 대응하는 HTTP 데이타 스트림 데이타와, CGI의 기본 형태와 웹 서버로부터 수신된 응답간의 차분 데이타를 전송함으로써, 웹 서버로부터 수신된 HTTP 데이타 스트림을 클라이언트/서버 지정 프로토콜로 변환시킨다. 이어서, 이러한 정보는 외부 통신 링크(35)를 통해 클라이언트측 인터셉트 모듈(30)에 전송된다.

블럭(247)을 참조하면, 서버의 재기준화를 필요로 하면, 블럭(247)의 긍정 경로가 선택된다. 블럭(248)에 도시된 바와 같이, 서버측 인터셉트 모듈은 브라우저에 의해 개시된 통신에 대응하는 서버 기본 캐쉬 엔트리를 웹 서버로부터 수신된 HTTP 데이타 스트림과 갱신한다. 응답 CRC도 또한 갱신되고, CGI 차분 데이타는 널화된다. 이어서, 서버측 인터셉트 모듈은 블럭(250)에 도시된 바와 같이 새로운 서버측 캐쉬 엔트리의 CRC를 비교하고 전술한 바와 같이 전송한다.

도 8에는 서버측 인터셉트 모듈(40)로부터 응답 수신시 클라이언트측 인터셉트 모듈의 동작이 도시되어 있다. 블럭(260)에는 클라이언트측 인터셉트 모듈(30)에 의한 서버측 인터셉트 모듈(40)로부터의 응답 수신이 도시되어 있다. 블럭(265)에 도시된 바와 같이, 클라이언트측 인터셉트 모듈(30)은 응답이 CGI 요구에 대한 응답인지를 판정한다. 응답이 CGI 요구에 대한 응답이 아니면, 클라이언트측 인터셉트 모듈은 도 3 내지 도 6에 도시된 캐쉬 동작을 포함하는 블럭(267)의 동작을 수행한다. 그러나, 응답이 CGI 요구에 대한 응답이면, 블럭(265)의 긍정 경로가 선택된다. 클라이언트측 인터셉트 모듈(30)은 외부 통신 링크를 통해 제공된 HTTP 데이타 스트림 데이타와, 차분 데이타와, 클라이언트/서버 지정 데이타 스트림으로부터 획득된 CRC를 저장한다. 이러한 동작은 도 8의 블럭(266)에 도시되어 있다.

이어서, 클라이언트측 인터셉트 모듈(30)은 클라이언트 CGI 기본 형태를 포함할 수 있는 인터셉트된 CGI 요구에 대응하는 클라이언트 기본 캐쉬 엔트리가 존재하는지를 판정한다. 이러한 질의는 블럭(270)에 도시되어 있으며, HTTP 요구 또는 HTTP 응답의 URL을 조사함으로써 수행될 수 있다. 클라이언트 CGI 기본 형태가 존재하면, 블럭(270)의 긍정 경로가 선택된다. 이어서, 블럭(275)에 도시된 바와 같이, 클라이언트측 인터셉트 모듈(30)은 외부 통신 링크를 통해 수신된 CRC를 클라이언트 CGI 기본 형태의 CRC와 비교한다. 만일 이들이 상이하면, 블럭(275)의 부정 경로가 선택되고, 클라이언트는 웹 브라우저에 의해 개시된 통신에 대한 CGI 요구의 URL에 대응하는 클라이언트 기본 캐쉬 엔트리를 서버측 인터셉트 모듈(40)로부터 외부 통신 링크(35)를 통해 수신된 HTTP 데이타 스트림 데이타로 대체하여 CGI 기본 형태를 갱신함으로써 재기준화한다. 또한, 클라이언트 기본 캐쉬 엔트리는 HTTP 데이타 스트림에 대한 CRC에 대해 갱신된다. 이러한 동작은 도 8의 블럭(276)에 도시되어 있다.

외부 통신 링크(35)를 통해 수신된 CRC는 CGI 기본 형태의 CRC와 동일하면, 서버측 인터셉트 모듈 서버 CGI 기본 형태는 클라이언트측 인터셉트 모듈 클라이언트 CGI 기본 형태와 동일하고, 블럭(275)의 긍정 경로가 선택된다.

이들 기본 형태가 동일하거나 혹은 클라이언트가 재기준화되면, 블럭(277)에 도시된 동작이 클라이언트측 인터셉트 모듈(30)에 의해 수행된다. 블럭(277)에서, 클라이언트 CGI 기본 형태를 외부 통신 링크(35)를 통해 수신된 CGI 차분 데이타와 조합함으로써 클라이언트측 인터셉트 모듈(30)은 외부 통신 링크(35)를 통해 수신된 클라이언트/서버 지정 데이타 스트림으로부터 웹 서버(20)로부터의 통신에 대응하는 HTTP 데이타 스트림을 재구성하여, 인터셉트된 CGI 응답에 대응하는 HTTP 데이타 스트림을 생성한다. 블럭(278)에 도시된 바와 같이, 이러한 응답은 웹 브라우저(10)에 HTTP 데이타 스트림으로서 제공된다.

CGI 요구의 URL에 대응하는 클라이언트에 CGI 기본 형태가 존재하지 않으면, 도 8의 블럭(270)의 부정 경로가 선택된다. 블럭(271)에 도시된 바와 같이, 클라이언트측 인터셉트 모듈(30)은 URL과, 서버측 인터셉트 모듈(40)로부터 외부 통신 링크를 통해 수신된 HTTP 데이타 스트림의 CRC와, 실제 HTTP 데이타 스트림의 데이타를 저장함으로써 CGI 요구의 URL에 대응하는 클라이언트 기본 캐쉬 엔트리를 생성한다. 이러한 정보 저장에서는 인터셉트된 CGI 요구에 대응하는 클라이언트 기본 캐쉬 엔트리를 생성하므로, 클라이언트 CGI의 기본 형태가 생성된다. 이어서, 클라이언트측 인터셉트 모듈은 블럭(277)의 동작을 수행하여, 클라이언트 CGI 기본 형태를 널화된 CGI 차분 데이타과 조합하거나 병합함으로써 HTTP 데이타 스트림이 재구성되도록 한다.

본 발명의 차분 방안은 비-CGI 데이타에도 또한 적용될 수 있다. 예를 들어, 서버측 인터셉트 모듈(40)은 다수의 서버 기본 캐쉬 엔트리를 계속적으로 생성하여 웹 서버에 접속된 웹 브라우저의 클라이언트측 인터셉트 모듈이 다른 기본 형태를 갖도록 할 수 있다. 이어서, 서버측 인터셉트 모듈은 정합이 이루어질 때까지 클라이언트측 인터셉트 모듈로부터 수신된 CRC를 이전에 생성된 각각의 서버 기본 형태의 CRC를 비교할 수 있다. 이어서, 서버측 인터셉트 모듈(40)은 클라이언트측 인터셉트 모듈(30)을 선택사양적으로 재설정하거나 혹은 차분 데이타를 단순히 클라이언트측 인터셉트 모듈(30)에 제공할 수 있다. 따라서, 본 명세서에서 CGI 요구에 대해 기술된 차분 방안들은 소정의 HTTP 요구 및 응답에도 동일하게 적용할 수 있다.

기본 형태를 다수로 생성하는 전술한 시스템은 비-CGI 요구에 대한 차분 방안을 사용할 수 있도록 하지만, 이러한 방안은 메모리 또는 저장장치의 저장 능력을 더욱 높일 수 있지만 전술한 캐쉬 용량을 충분히 활용하지는 못한다. 메모리 또는 저장장치의 요건을 줄이고 전술한 캐쉬 방안들을 활용하기 위해, 비-CGI 요구에 대한 차분 방안을 이용하는 다음과 같은 바람직한 방안이 사용될 수 있다. 이러한 바람직한 구현에 있어서, 서버측 인터셉트 모듈은 요구에 대응하는 서버 기본 형태와 웹 서버로부터의 응답 HTTP 데이타 스트림간의 차를 계산한다. 그러면, 이러한 차분 데이타는 서버측 인터셉트 모듈에 의해 저장된다. 이어서, 서버 기본 형태는 기본 형태의 CRC를 갱신하는 것을 포함하여 기본 형태를 웹 서버로부터의 새로운 응답으로 대체함으로써 갱신된다. 그러나, 이전의 CRC를 포기하지 않고 이전의 기본 형태에 대한 CRC가 차분 데이타로서 저장된다. 이어서, 이전의 생성된 차분 데이타 및 CRC는 비-CGI 요구에 대응하는 클라이언트 기본 형태의 CRC를 기초로 하여 클라이언트측 인터셉트 모듈로 선택적으로 전송된다.

비-CGI 차분 방안의 하나의 예로서, 서버측 인터셉트 모듈이 비-CGI 요구를 수신하는 경우, 이 요구는 비-CGI 요구의 URL에 대응하는 클라이언트측 인터셉트 모듈에 상주하는 기본 형태의 CRC와 함께 제공될 수 있다. 서버측 인터셉트 모듈이 웹 서버로부터 응답을 수신한 경우에, 서버측 인터셉트 모듈은 응답의 CRC를 계산할 수 있다. 이어서, 서버측 인터셉트 모듈은 이러한 응답과 URL에 대한 서버 기본 형태간의 차를 계산하고 이 차분 데이타를 저장할 수 있다. 서버측 인터셉트 모듈은 응답 데이타를 이용하여 서버 기본 형태를 갱신하고, 이전의 기본 형태의 CRC와 응답 및 이전의 기본 형태간의 차분 데이타를 보관할 수 있다. 이어서, 서버측 인터셉트 모듈은 클라이언트 기본 형태의 CRC와 서버 기본 형태의 CRC 및 소정의 저장 또는 보관된 CRC를 비교하여 정합이 이루어졌는지를 판정할 수 있다. 정합이 검출되지 않았으면, 응답은 클라이언트측 인터셉트 모듈에 단순히 전송된다.

만일 정합이 검출되면, CRC 정합에 대응하는 차분 데이타와 현재의 차분 데이타까지 포함하는 소정의 차후의 차분 데이타는 클라이언트측 인터셉트 모듈에 전송된다. 이어서, 클라이언트측 인터셉트 모듈은 차분 데이타를 클라이언트 기본 형태로 제공하여 응답을 재구성한다. 따라서, 만일 CRC의 정합이 이전에 3개로 생성된 기본 형태의 CRC와 함께 이루어지면, 3개의 차분 데이타 세트는 클라이언트측 인터셉트 모듈에 전송되고 응답 구성은 3개의 연속적인 차분 데이타 세트를 클라이언트 기본 형태로 제공함으로써 달성될 수 있다. 그러나, 응답을 재구성하는데 필요한 차분 데이타 세트의 수 또는 차분 데이타 세트의 크기가 너무 커서 실제 응답 전송이 데이타 전송보다 적은 경우, 응답은 서버측 인터셉트 모듈에 의해 자체적으로 전송될 수 있다. 어떤 경우에 있어서, 응답을 재구성하거나 수신한 후, 클라이언트측 인터셉트 모듈은 응답 데이타를 이용하여 요구 URL에 대한 클라이언트 기본 형태를 갱신하고, 응답 CRC를 이용하여 CRC를 갱신할 수 있다. 클라이언트 기본 형태는 응답이 특정한 URL에 대해 수신될 때 갱신되기 때문에, 전술한 클라이언트 캐쉬는 클라이언트 기본 형태에 대한 캐쉬로서 이용될 수 있으며, 그 결과 차분 방안이 비-CGI 요구시 이용되는 경우 클라이언트 기본 형태에 대한 각각의 캐쉬를 구비하지 않아도 된다.

본 발명의 또다른 특징에 있어서, 부가적인 통신 저장 방안은 HTTP와 같은 스테이트리스 통신 프로토콜의 중복성을 기초로 하여 달성될 수 있다. 이와 같은 프로토콜에 있어서, 클라이언트는 통신이 개시될 때마다 자신에 관한 정보를 서버에 전송한다. 마찬가지로, 서버는 응답이 개시될 때마다 자신에 관해 지정된 정보를 클라이언트에 전송한다.

본 발명의 또다른 실시예에 있어서, 제 1 컴퓨터(5)는 제 1 컴퓨터의 사전정의된 특징에 대응하는 컴퓨터 지정 정보를 제 2 컴퓨터(6)에 전송한다. 제 2 컴퓨터는 컴퓨터 지정 정보를 저장한다. 그러면, 제 1 컴퓨터는 외부 통신 링크(35)를 통해 전송하기 전에 차후의 웹 브라우저에 의해 개시된 통신으로부터 컴퓨터 지정 정보를 제거한다. 이어서, 제 2 컴퓨터(6)는 저장된 컴퓨터 지정 정보를 외부 통신 링크(35)를 통해 수신된 차후의 통신과 조합한 다음 원래의 웹 브라우저에 의해 개시된 통신을 재설정하여 HTTP 데이타 스트림을 생성한다.

웹 브라우저에 의해 개시된 통신으로부터 컴퓨터 지정 정보를 제거하는 것과 더불어, 웹 서버에 의해 개시된 통신으로부터 컴퓨터 지정 정보를 또한 제거할 수 있다. 이 경우, 도 2의 제 2 컴퓨터(6)는 제 2 컴퓨터(6)의 사전정의된 특성에 대응하는 컴퓨터 지정 정보를 외부 통신 링크(35)를 통해 제 1 컴퓨터(5)에 제공한다. 제 1 컴퓨터(5)는 컴퓨터 지정 정보를 저장하여 서버 헤더 정보를 제공할 수 있도록 한다. 차후의 통신에서, 제 2 컴퓨터(6)는 웹 서버에 의해 개시된 통신으로부터 컴퓨터 지정 정보를 제거하고, 웹 서버에 의해 개시된 통신의 나머지 부분을 외부 통신 링크(35)상으로 전송한다. 제 1 컴퓨터(5)는 외부 통신 링크를 통해 통신을 수신하고, 서버 헤더 정보와 외부 통신 링크를 통해 수신된 클라이언트/서버 지정 데이타 스트림을 조합함으로써 원래의 웹 서버에 의해 개시된 통신을 재설정하여 HTTP 데이타 스트림을 생성한다. 이러한 실시예에 있어서, 컴퓨터 지정 정보를 제거하고 정보를 저장하여 서버 헤더 정보 또는 클라이언트 헤더 정보중 어느 하나를 생성하는 동작은 이 동작이 제 1 컴퓨터(5) 또는 제 2 컴퓨터(6)에서 발생되는지에 따라 클라이언트측 인터셉트 모듈(30) 또는 서버측 인터셉트 모듈(40)에 의해 수행된다.

본 발명의 하나의 실시예에 있어서, 웹 브라우저(10)는 TCP/IP를 이용하여 클라이언트측 인터셉트 모듈(30)과 통신한다. TCP는 외부 통신 링크(35)를 통해 클라이언트측 인터셉트 모듈(30)과 서버측 인터셉트 모듈(40) 사이의 통신에 또한 사용될 수 있다. 마지막으로, TCP는 서버측 인터셉트 모듈(40)과 웹 서버(20) 사이의 통신에 사용될 수 있다. TCP는 본 발명의 시스템을 구성하는 여러 구성 요소들 사이의 통신에 사용될 수 있지만, HTTP 프로토콜은 외부 통신 링크를 통해 통신하는데 필요한 가장 효율적인 수단을 제공하지는 못한다. 외부 통신 링크(35)의 성능을 향상시키기 위해, 본 발명의 하나의 실시예에서는 웹 브라우저와 클라이언트측 인터셉트 모듈(30)간의 접속 및 서버측 인터셉트 모듈(40)과 웹 서버(20)간의 접속에 사용되는 가상 소켓(virtual sockets)으로 일컬어지는 것을 생성한다. 이러한 가상 소켓의 동작은 이하 도 11 내지 도 17을 참조하여 기술될 것이다.

도 11은 가상 소켓의 개념을 이용한 본 발명의 실시예의 블럭도이다. 도 11에 도시된 바와 같이, 컴퓨터(5)와 컴퓨터(6)는 외부 통신 링크(35)를 통해 접속된다. 웹 브라우저(10)는 웹 브라우저(10)와 클라이언트측 인터셉트 모듈(30)을 접속하는 다수의 실제 소켓을 포함한다. 도 11에 도시된 바와 같이, 참조부호(65a)로 도시된 제 1 실제 소켓은 웹 브라우저(10)상에 위치되고, 참조부호(65b)로 도시된 대응하는 소켓은 클라이언트측 인터셉트 모듈(30)상에 위치되어 있다. 제 1 실제 소켓은 TCP 소켓으로서, 웹 브라우저(10)는 이 소켓을 통해 클라이언트측 인터셉트 모듈(30)로부터의 다른 접속을 요구한다.

웹 브라우저(10)가 새로운 TCP 접속을 요구하면, 실제 소켓(65b)에서 수신되는 통신은 실제 소켓(65a)을 통해 이루어진다. 이어서, 클라이언트측 인터셉트 모듈(30)은 웹 브라우저(10)와의 통신을 위해 또다른 실제 소켓을 생성할 것이다. 도 11에 도시된 바와 같이, 다수의 실제 소켓은 웹 브라우저(10)상에서 생성되고, 대응하는 실제 소켓도 클라이언트측 인터셉트 모듈(30)상에서 생성된다. 이들 실제 소켓은 웹 브라우저(10)상에 참조부호(60a∼64a)로 도시되고, 클라이언트측 인터셉트 모듈(30)상에 참조부호(60b∼64b)로 도시되어 있다. 이들 실제 소켓을 통해 웹 브라우저(10)는 클라이언트측 인터셉트 모듈(30)과의 통신을 수행한다. 실제 소켓(60a∼64a 및 60b∼64b)을 생성한 후, 이들 소켓을 통해 이루어지는 통신은 클라이언트측 인터셉트 모듈(30)을 외부 통신 링크(35)에 액세스하는 실제 소켓(36a)상에서 멀티플렉싱된다. 실제 소켓(36a 및 36b)은 요구가 컴퓨터(5)의 실제 소켓(37a)를 통해 컴퓨터(6)의 실제 소켓(37b)에 제공될 때 생성된다. 실제 소켓(37b)에 의한 접속 요구를 수신시, 실제 소켓(36a 및 36b)이 생성된다. 소켓(37a 및 37b)은 클라이언트측 인터셉트 모듈과 서버측 인터셉트 모듈 사이의 통신을 위한 제 1 실제 소켓으로서 기능하고, 소켓(36a 및 36b)으로 도시된 두개의 모듈간의 접속을 설정하는 데에만 사용될 수 있다. 이들 각각의 소켓들은 표준 TCP/IP 프로토콜에 따라 동작한다. 제 2 컴퓨터(6)가 외부 통신 링크(35)를 통해 통신을 수신하면, 통신은 실제 소켓(36b)에서 수신된다. 이어서, 서버측 인터셉트 모듈(40)은 소켓(36b)에서 수신된 통신을 디멀티플렉싱하고, 이를 웹 서버(20)에 전송하는데 적합한 소켓에 제공한다. 따라서, 지정된 URL로부터 정보를 요구하기 위해 예를 들어, 소켓(60a)을 통해 소켓(60b)으로 제공되는 통신은 소켓(36a)상에서 멀티플렉싱되고, 소켓(36b)에 의해 수신되고, 서버측 인터셉트 모듈(40)에 의해 디멀티플렉싱되고, 소켓(60c)로부터 웹 서버(20)상의 소켓(60d)로 전송된다. 마찬가지로, 소켓(61a)상에서 발생된 통신은 소켓(61b)에 의해 수신되고, 클라이언트측 인터셉트 모듈(30)에 의해 멀티플렉싱되고, 소켓(36a)으로부터 소켓(36b)에 전송되며, 소켓(36b)에서 서버측 인터셉트 모듈(40)은 통신을 디멀티플렉싱하여 이를 소켓(61c)을 통해 소켓(61d)에 전송한다. 따라서, 소켓(60a 및 60b, 61a 및 61b, 62a 및 62b, 63a 및 63b, 64a 및 64b)은 통한 통신은 서버측 인터셉트 모듈(40)과 웹 서버(20) 사이의 소켓(60c 및 60d, 61c 및 61d, 62c 및 62d, 63c 및 63d, 64c 및 64d)의 각각의 대응하는 소켓상으로 전송된다.

유사한 방식으로, 웹 브라우저(10)로부터의 요구에 대한 웹 서버(20)의 응답은 또한 웹 서버(20)와 서버측 인터셉트 모듈(40)을 접속하는 소켓을 거쳐 외부 통신 링크(35)와 클라이언트측 인터셉트 모듈(30)을 통해 웹 브라우저(10)로 또한 전송된다. 따라서, 예를 들어 웹 서버(20)에 의해 개시된 응답은 소켓(60d)를 통해 소켓(60c)으로 전송되고, 서버측 인터셉트 모듈(40)에 의해 소켓(36b)상에서 멀티플렉싱되고, 외부 통신 링크(35)를 통해 소켓(36a)으로 전송된다. 이어서, 클라이언트측 인터셉트 모듈(30)은 통신을 디멀티플렉싱한 다음 이를 소켓(60b)에 제공하여 웹 브라우저(10)상의 소켓(60a)에 전송되도록 한다. 웹 브라우저(10) 또는 웹 서버(20)에 의해 사용되는 각각의 소켓에 대한 통신 경로도 이와 유사하게 설정될 수 있다. 본 발명은 웹 브라우저(10)와 웹 서버(20) 사이에 4개의 소켓 접속에 대해 기술되었지만, 본 기술 분야에 통상의 지식을 가진 자라면, 웹 브라우저(10)와 웹 서버(20) 사이에 통신을 액세스하는 소켓이 임의의 갯수로 제공될 수 있음을 이해할 것이다.

도 12는 클라이언트측 인터셉트 모듈(30)과 서버측 인터셉트 모듈(40)의 가상 소켓 시스템의 실시예를 도시한 블럭도이다. 이들 모듈 외부에 위치한 클라이언트측 인터셉트 모듈(30)과 웹 브라우저(10)간의 실제 소켓과, 서버측 인터셉트 모듈(40)과 웹 서버(20)간의 실제 소켓은 정규 TCP/IP 소켓으로서 기능한다. 따라서, 웹 브라우저(10)와 웹 서버(20)에 대한 가상 소켓의 사용을 명백하게 이해할 것이다.

이하, 도 12의 블럭도 및 도 13 내지 도 17의 흐름도에 대한 본 발명의 특정한 실시예가 기술될 것이다. 도 13은 도 12에 블럭(68)으로 도시된 소켓 관리자에 대한 흐름도이다. 도 13을 참조하면, 블럭(300)에서 클라이언트측 인터셉트 모듈(30)의 실제 소켓 관리자(68)가 생성된다. 실제 소켓 관리자(68)가 생성된 후, 관리자(68)는 도 12의 소켓(65b)으로서 도시된 제 1 실제 소켓을 생성한다. 이러한 제 1 실제 소켓의 생성은 도 13의 블럭(301)에 도시되어 있다. 도 13의 블럭(302)에 도시된 바와 같이, 클라이언트측 인터셉트 모듈(30)에 상주하고 본 명세서에 클라이언트 소켓 관리자로서 또한 일컬어지는 소켓 관리자(68)는 제 1 실제 소켓(65b)상의 이벤트(event)를 대기한다. 제 1 실제 소켓(65b)상에서 이벤트가 수신되면, 도 13의 블럭(305)에 도시된 바와 같이 실제 소켓 관리자(68)는 이벤트를 검사하고, 이러한 검사를 기초로 하여 5개의 경로들 중 하나를 선택한다.

제 1 실제 소켓(65b)에서 수신된 통신 요구에 응답하여 실제 소켓이 생성되면, 도 13의 블럭(305)에서 블럭(306)으로 진행되는 경로에 나타난 바와 같이, 실제 소켓 관리자(68)는 실제 소켓을 실제 이벤트 리스트에 추가한다. 이어서, 블럭(307)에 도시된 바와 같이, 실제 소켓 관리자는 단방향 가상 소켓을 생성한다. 도 13의 블럭(308)에 도시된 바와 같이, 클라이언트측 인터셉트 모듈의 경우에 있어서, 실제 소켓 관리자는 생성된 가상 소켓에 대한 클라이언트측 인터셉트 모듈의 함수를 수행하는 애플리케이션 함수를 개시한다.

본 명세서에서 사용된 단방향 소켓(simplex socket) 또는 단향향 가상 소켓(simplex virtual socket)은 단일 소켓 또는 단일 애플리케이션과 직접 접속하는 소켓으로 지칭한다. 본 명세서에서 사용된 다중 소켓(multiplex socket)은 다수의 다른 소켓과 접속하는 소켓으로 지칭한다. 따라서, 다중 소켓은 멀티플렉싱 또는 디멀티플렉싱 함수를 수행하고, 단방향 소켓은 1 대 1 접속을 수행한다. 따라서, 예를 들어, 도 13의 블럭(306 내지 308)의 함수를 수행하는 경우, 클라이언트 소켓 관리자(68)는 제 1 실제 소켓(65b)에 의해 수신된 제 1 접속 요구에 응답하여 실제 소켓(60b) 및 단방향 가상 소켓(70)을 생성하고, 애플리케이션(80)의 클라이언트측 인터셉트 함수를 개시할 수 있다. 마찬가지로, 실제 소켓이 생성되는 차후의 이벤트의 경우, 실제 소켓 관리자는 실제 소켓(61b, 62b, 63b 또는 64b)와 단방향 가상 소켓(71, 72, 73 또는 74)을 생성하고, 생성된 실제 소켓 및 도 12에 블럭(81, 82, 83 또는 84)으로 도시된 가상 소켓에 대응하는 CSI를 개시할 수 있다.

이하, 도 12에 도시된 실제 소켓(60b), 단방향 가상 소켓(70) 및 클라이언트측 인터셉트 함수(80)에 대한 클라이언트측 인터셉트 함수의 동작이 기술될 것이다. 도 14의 블럭(325)은 클라이언트측 인터셉트 함수(80)의 생성을 나타낸다. 생성시, 블럭(326)으로 도시된 바와 같이, 클라이언트측 인터셉트 함수(80)는 단방향 가상 소켓(70)상의 이벤트를 대기한다. 이러한 대기 동작은 도 16-4에 도시되어 있는 가상 선택 함수를 수행함으로써 행해진다. 이벤트 수신시, 블럭(330)에 도시된 바와 같이 이벤트를 검사한다. 만일 이벤트가 폐쇄된 가상 소켓이면, 클라이언트측 인터셉트 함수(80)는 블럭(349)에 도시된 바와 같이 단방향 가상 소켓(70)을 제거하고 도 14의 블럭(350)에서 종료한다.

만일 이벤트가 데이타를 수신하면, 블럭(330)에서 블럭(331)으로 진행되는 경로가 선택되고, 클라이언트측 인터셉트 함수(80)는 도 16-3에 대해 본 명세서에서 기술된 가상 수신 동작을 실행함으로써 단방향 가상 소켓(70)으로부터 브라우저에 의해 개시된 통신을 수신한다. 이어서, 블럭(332)에 도시된 바와 같이 클라이언트측 인터셉트 함수는 전술한 바와 같이(예를 들어 도 3 및 도 7을 참조) 클라이언트측 인터셉트 모듈의 함수를 수행한다. 이어서, 클라이언트측 인터셉트 함수(80)는 클라이언트측 인터셉트 모듈(30)의 실제 소켓(36a)에 접속되는 다중 가상 소켓(90)을 생성한다. 실제 소켓(36a)은 서버측 인터셉트 모듈(40)상의 실제 소켓(36b)과 접속된다. 다중 가상 소켓의 생성은 도 14의 블럭(33)에 도시되어 있으며, 도 16-1을 참조하여 본 명세서에서 기술된 가상 생성 동작을 수행함으로써 행해진다. 블럭(334)은 웹 브라우저에 의해 개시된 통신에 대한 클라이언트측 인터셉트 함수(80)를 수행한 후, 웹 브라우저로부터 실제 소켓(60b) 및 단방향 가상 소켓(70)을 통해 수신된 정보를 전송하는 동작을 나타낸다. 이러한 통신은 도 16-2를 참조하여 본 명세서에 기술된 가상 전송 동작을 수행함으로써 다중 가상 소켓(90)에 큐잉(queue)된다. 클라이언트측 인터셉트 함수(80)는 요구를 다중 가상 소켓(90)에 큐잉한 후, 도 14의 블럭(335)에 도시된 바와 같이 다중 가상 소켓(90)에 큐잉된 데이타를 플러쉬하고, 이어서 블럭(336)에 도시된 다중 가상 소켓상의 이벤트를 대기한다. 가상 플러쉬 함수는 다중 가상 소켓의 큐로부터 데이타를 취하고 이를 실제 소켓(36a)에 제공하는 도 17-1을 참조하여 본 명세서에서 기술된 가상 플러쉬 동작을 수행함으로써 행해진다. 대기 동작은 도 16-4에 도시된 가상 선택 함수를 수행함으로써 행해질 수 있다. 이때, 클라이언트측 인터셉트 모듈은 웹 브라우저에 의해 개시된 통신을 인터셉트하고, 통신을 외부 통신 링크(35)를 통해 서버측 인터셉트 모듈로 전송한다.

도 13을 참조하면, 서버측 인터셉트 모듈(40) 또는 클라이언트측 인터셉트 모듈(30)의 소켓 관리자에 대한 흐름도가 도시되어 있다. 도 12의 블럭(69)에 도시된 바와 같이, 서버측 인터셉트 모듈의 실제 소켓 관리자 또는 서버 소켓 관리자는 블럭(68)에 도시된 클라이언트 소켓 관리자와 동일한 함수를 수행한다. 블럭(301)에 도시된 제 1 실제 소켓을 생성하는 경우, 서버측 인터셉트 모듈(30)은 서버측 인터셉트 모듈(40)과 관련된 클라이언트측 인터셉트 모듈(30)로부터 소켓에 대한 요구를 수신하기 위해 공지의 포트(37b)를 생성한다. 서버측 인터셉트 모듈(40)의 실제 소켓(36b)상에 실제 이벤트가 발생되면, 블럭(305)에 도시된 바와 같이 이벤트를 검사한다. 이 경우, 실제 소켓(36a)으로부터 데이타를 수신하는 이벤트이면, 도 13의 블럭(305)에서 블럭(320)으로 진행하는 경로가 선택된다. 실제 소켓(36b)상에서 수신된 데이타를 조사할 때, 예를 들어 데이타가 클라이언트측 인터셉트 모듈에 의해 전송된 웹 브라우저 개시 통신이면, 서버측 인터셉트 모듈(40)에 새로운 가상 소켓을 생성해야 한다. 따라서, 도 13의 블럭(320)에서 블럭(321)으로 진행하는 경로가 선택된다. 이어서, 서버 소켓 관리자(69)는 도 13의 블럭(321, 322, 323, 324)에 도시된 동작을 수행한다. 서버 소켓 관리자(69)는 블럭(321)에 도시된 바와 같이 다수의 가상 소켓(95)을 생성하고, 블럭(322)에 도시된 바와 같이 다수의 소켓 활성 타이머를 취소하고, 도 13의 블럭(323)의 블럭으로 도시되고 도 12의 블럭(85)으로 도시된 바와 같이 서버측 인터셉트 함수의 애플리케이션을 개시한다. 이어서, 실제 소켓(36b)에서 수신된 데이타는 다중 가상 소켓(95)에 큐잉되고, 가상 이벤트가 제공된다.

블럭(323)에 도시된 바와 같은 서버측 인터셉트 함수의 생성은 도 15의 블럭(360)에 도시되어 있다. 서버측 인터셉트 함수(85)를 생성한 후, 함수는 클라이언트측 인터셉트 모듈(30)로부터 제공되고 웹 브라우저에 의해 개시된 통신에 대응하는 다중 가상 소켓(95)으로부터 데이타를 수신한다. 이러한 동작은 도 15의 블럭(361)에 도시되어 있다. 블럭(362)에는 서버측 함수의 수행이 도시되어 있다(예를 들어, 도 5 및 도 9를 참조). 정보를 프로세싱한 후, 서버측 인터셉트 함수(85)는 가상 생성을 수행함으로써 단방향 가상 소켓(75)을 생성하며, 이러한 가상 생성 동작은 본 명세서에서 도 16-1을 참조하여 기술된다. 이러한 동작은 도 15의 블럭(363)에 도시되어 있다. 이어서, 서버측 인터셉트 함수(85)는 가상 전송을 수행함으로써 블럭(364)에 도시된 바와 같이 웹 브라우저에 의해 개시된 통신을 단방향 가상 소켓(75)에 전송하며, 이러한 가상 전송 동작은 본 명세서에서 도 16-2를 참조하여 기술된다. 이어서, 서버측 인터셉트 함수(85)는 가상 플러쉬(virtual flush)를 수행하여 단방향 가상 소켓(75)에 큐잉된 데이타를 실제 소켓(60C)으로 플러쉬하고, 단방향 가상 소켓(75)상의 이벤트를 대시한다. 가상 플러쉬 동작은 본 명세서에서 도 17-1을 참조하여 기술될 것이다. 전송 및 플러쉬 동작은 도 15의 블럭(364) 및 블럭(365)에 도시되어 있다. 서버측 인터셉트 함수(85)가 단방향 가상 소켓(75)을 생성하면, 이에 대응하는 실제 소켓(60c)도 또한 생성된다. 웹 브라우저에 의해 개시된 통신을 단방향 가상 소켓(75)에 전송함으로써, 서버측 인터셉트 함수(85)는 웹 브라우저에 의해 개시된 통신을 웹 서버에 전송한다.

서버측 인터셉트 모듈(40)이 실제 소켓(60c)상의 웹 서버로부터 응답을 수신하면, 실제 이벤트가 발생되고, 서버 소켓 관리자(69)는 도 13의 블럭(302)으로 진행하여 블럭(305)에 도시된 바와 같이 실제 소켓(60c)상에서 발생된 이벤트를 조사한다. 이 경우, 이벤트가 기존의 가상 소켓에 대한 데이타이면, 도 13의 블럭(320)에서 블럭(324)으로 진행되는 경로가 선택된다. 실제 소켓(60c)상에서 수신된 데이타는 가상 소켓(75)에 큐잉되고 가상 이벤트에 신호가 제공된다. 가상 이벤트가 제공되면, 가상측의 인터셉트 함수(85)는 도 15의 블럭(366)을 빠져나와 블럭(370)에서 이벤트를 조사한다. 이벤트가 폐쇄된 소켓이면, 에러 상태가 발생되고, 도 15의 블럭(375)에 도시된 바와 같이 에러 메시지는 응답으로서 구성된다. 그러나, 이벤트가 데이타 수신에 관한 것이면, 블럭(370)에서 블럭(371)으로 진행되는 경로가 선택되고, 도 16-3을 참조하여 본 명세서에서 기술된 바와 같이 서버측 인터셉트 함수(85)는 가상 수신을 수행하여, 블럭(371)에 도시된 바와 같이 단방향 가상 소켓(75)으로부터 서버 응답을 획득한다. 이어서, 서버측 인터셉트 함수(85)는 본 명세서에서 도 17-2에 대해 기술되고 블럭(372)으로 도시된 바와 같이 단방향 가상 소켓(75)을 가상적으로 폐쇄하고, 서버측 인터셉트 모듈에 대해 기술하고 블럭(373)에 도시된 응답을 프로세싱한다(예를 들어, 도 6 및 도 10을 참조).

도 15의 블럭(370)의 출력 경로가 블럭(375)에 대한 에러 경로 혹은 블럭(371)에 대한 데이타 경로이든지 간에, 블럭(374)에서 단방향 가상 소켓(75)이 제거된다. 이어서, 서버측 인터셉트 함수는 다중 가상 소켓(95)에 대한 가상 전송 동작을 수행하여, 블럭(376)에 도시된 바와 같이 웹 서버에 의해 개시된 통신이 클라이언트측 인터셉트 모듈(30)로 제공되도록 한다. 이어서, 서버측 인터셉트 함수(85)는 가상 플러쉬 동작을 수행하여 다중 가상 소켓(95)에 큐잉된 데이타를 플러쉬한다. 이들 동작은 블럭(377)에 도시되어 있다. 이어서, 도 15의 블럭(378)에 도시된 바와 같이 서버측 인터셉트 함수(85)는 가상 폐쇄 동작을 수행하여 다중 가상 소켓(95)을 폐쇄한다. 마지막으로, 블럭(379 및 380)에 도시된 바와 같이, 서버측 인터셉트 함수(85)는 다중 가상 소켓을 제거하여 종료한다.

서버측 인터셉트 함수는 다중 가상 소켓(95)에 대한 가상 전송 및 플러쉬 동작을 수행한다. 실제 소켓(36a) 및 클라이언트 소켓 관리자(68)상의 트리거 이벤트(trigger events)는 블럭(302)를 빠져나와 블럭(305)에 도시된 바와 같이 이벤트를 조사하며, 만일 실제 소켓(36a)상에서 데이타가 수신되면 도 13의 블럭(305)에서 블럭(320)으로 진행되는 경로가 선택되고, 데이타는 다중 가상 소켓(90)에 큐잉된다. 따라서, 실제 소켓(36a)이 실제 소켓(36b)으로부터 외부 통신 링크(35)를 통해 웹 서버 응답을 수신하면, 이 정보는 디멀티플렉싱되어 적절한 다중 가상 소켓으로 제공된다. 데이타를 수신하면 도 13의 블럭(324)에 도시된 바와 같이 가상 이벤트가 발생되고, 도 14의 블럭(336)은 종료되고, 클라이언트측 인터셉트 함수(80)는 도 14의 블럭(340)에 도시된 바와 같이 이벤트를 조사할 수 있다.

만일 이벤트가 폐쇄된 소켓 응답이면, 도 14의 블럭(340)에서 블럭(345)으로 진행되는 경로가 선택되고, 클라이언트측 인터셉트 함수(80)는 에러 메시시 응답을 생성하여 블럭(14)의 블럭(344)으로 진행한다. 만일 이벤트가 본 예의 경우와 같이 수신된 데이타이면, 도 14의 블럭(340)에서 블럭(341)으로 진행되는 경로가 선택되고, 클라이언트측 인터셉트 함수(80)는 가상 수신 동작을 수행하여 다중 가상 소켓(90)으로부터 응답을 수신한다. 이러한 수신 동작은 도 14의 블럭(341)에 도시되어 있다. 다중 가상 소켓(90)으로부터 데이타를 수신한 후, 블럭(342)에 도시된 바와 같이 클라이언트측 인터셉트 함수(80)는 가상 폐쇄 동작을 수행하여 다중 가상 소켓(90)을 폐쇄시킨다. 이어서, 블럭(343)에 도시된 바와 같이, 클라이언트측 인터셉트 함수(80)는클라이언트측 인터셉트 모듈에 대해 전술한 응답을 프로세싱한다(예를 들어, 도 4 및 도 8을 참조).

이어서, 블럭(340)을 출력하는 경로가 어느 쪽으로 선택되더라도, 블럭(344)의 동작이 수행된다. 클라이언트측 인터셉트 함수(80)는 블럭(344)에 도시된 바와 같이 다중 가상 소켓을 제거하고, 이어서 블럭(346)에 도시된 바와 같이 응답을 단방향 가상 소켓(70)을 거쳐 브라우저에 전송한다. 가상 전송 동작이 완료되면, 클라이언트측 인터셉트 함수(80)는 가상 플러쉬 동작을 수행하여 블럭(347)에 도시된 바와 같이 단방향 가상 소켓에 큐잉된 데이타를 실제 소켓(60b)에 플러쉬하고, 이어서 가상 폐쇄 동작을 수행하여 블럭(348)에 도시된 바와 같이 단방향 가상 소켓을 폐쇄한다. 클라이언트측 인터셉트 함수에 대한 단방향 가상 소켓이 폐쇄된 후, 도 14의 블럭(349 및 350)에 도시된 바와 같이 단방향 가상 소켓이 제거되고, 클라이언트측 인터셉트 함수가 종료된다.

본 발명은 단방향 및 다중 가상 소켓과 클라이언트측 인터셉트 및 서버측 인터셉트 함수의 생성의 하나의 특정한 실시예로 기술되었지만, 이들 다수의 함수들은 본 기술 분야에 통상의 지식을 가진 자라면 이해하듯이 단일 클라이언트측 인터셉트 모듈 또는 서버측 인터셉트 모듈내에서 생성될 수 있음을 이해할 것이다. 따라서, 본 발명에 따른 클라이언트측 인터셉트 모듈 및 서버측 인터셉트 모듈은 클라이언트측 인터셉트 모듈(30)과 서버측 인터셉트 모듈(40) 사이에서 TCP/IP 접속을 생성하고, 이어서 TCP/IP 접속을 유지하는 동안 TCP/IP상에서 웹 브라우저 또는 웹 서버에 의해 개시된 다수의 통신을 멀티플렉싱할 수 있다.

나머지 클라이언트 소켓 관리자 및 서버 소켓 관리자의 함수들은 도 16-1∼도 16-4 및 도 17-1 및 도 17-2를 참조하면 용이하게 이해될 수 있으며, 이들 도면은 도 14 및 도 15의 흐름도로 도시된 바와 같이 가상 생성, 가상 전송, 가상 수신, 가상 선택, 가상 플러쉬 또는 가상 폐쇄 동작이 실행될 때 클라이언트측 인터셉트 모듈 및 서버측 인터셉트 모듈에 의해 수행되는 동작을 나타낸다. 도 14의 블럭(333) 및 도 15의 블럭(363)에 도시된 바와 같이 가상 생성 동작이 수행되면, 도 16-1의 블럭(400)에서 개시되는 동작이 수행된다. 이어서, 블럭(405)에 도시된 바와 같이, 소켓 관리자는 실제 소켓을 필요로 하는지를 판정한다. 만일 기존의 실제 소켓에 접속되는 다중 가상 소켓을 생성하는 경우와 같이 실제 소켓이 이미 존재하면, 블럭(405)의 부정 경로가 선택되고, 가상 소켓은 블럭(409)에 도시된 바와 같이 실제 소켓에 접속된다. 그러나, 만일 실제 소켓을 필요로 하면, 블럭(405)의 긍정 경로가 선택된다. 이어서, 블럭(406)에서 실제 소켓이 생성된다. 이어서, 도 13의 블럭(302)에 도시된 바와 같은 감시를 위해 블럭(408)에서 실제 소켓은 이벤트 리스트에 추가된다. 실제 소켓이 생성되고 접속이 설정된 후, 블럭(409)에서 가상 소켓은 실제 소켓에 접속되고, 블럭(410)에서 생성 동작이 완료된다.

도 14의 블럭(334 및 246) 또는 도 15의 블럭(364 및 376)에 도시된 가상 전송 동작을 수행하기 위해, 도 16-2의 블럭(420)에서 동작이 수행된다. 데이타는 블럭(427)에 도시된 바와 같이 가상 소켓 큐에 추가되고, 이러한 추가 동작이 완료되면 블럭(428)에 도시된 바와 같이 전송 동작을 종료한다.

도 14의 블럭(331 및 341) 및 도 15의 블럭(361 및 371)에 도시된 가상 수신 동작은 도 16-3의 블럭(430)에서 개시되는 동작을 수행함으로써 행해진다. 블럭(435)에 도시된 바와 같이, 가상 소켓 큐를 평가하여, 가상 소켓 큐에 소정의 데이타가 존재하는지를 판정한다. 만일 가상 소켓 큐상에 데이타가 존재하면, 블럭(435)의 긍정 경로가 선택되고, 블럭(436)에 도시된 바와 같이 데이타는 수신 동작을 호출하는 함수에 반환된다. 만일 가상 소켓 큐상에 데이타가 존재하지 않고 소켓이 폐쇄로 표시되지 않으면, 판단 블럭(440)의 부정 경로가 선택되고, 블럭(441)에 도시된 바와 같이 영(nothing)을 반환한다. 그러나, 데이타가 큐상에 존재하지 않고 소켓이 폐쇄로 표시되면, 블럭(440)의 긍정 경로가 선택되고, 블럭(442)에 도시된 바와 같이 소켓은 폐쇄된 것으로 표시되고, 블럭(443)에 도시된 바와 같이 폐쇄된 소켓 응답은 수신을 요구하는 동작으로 반환된다.

도 14의 블럭(326 및 336) 및 도 15의 블럭(366)에서 수행되는 가상 선택 동작은 도 16-4의 블럭(445)에서 개시되는 동작을 수행함으로써 행해진다. 블럭(446)에 도시된 바와 같이, 선택된 가상 소켓에 대해 데이타 또는 가상 폐쇄 동작이 수행(pending)중인지를 우선 판정한다. 만일 데이타 또는 가상 폐쇄 동작이 수행중에 있지 않으면, 블럭(446)의 부정 경로가 선택되고, 블럭(447)에 도시된 바와 같이 선택된 가상 소켓상의 가상 이벤트를 대기하고, 블럭(448)에 도시된 바와 같이 이벤트를 수신한 후에 프로세스를 종료한다. 만일 데이타 또는 가상 폐쇄 동작이 선택된 가상 소켓에 대해 수행중이면, 가상 이벤트는 이미 발생되었으며, 블럭(446)의 긍정 경로가 선택되고, 블럭(448)에서 프로세스를 종료한다.

도 14의 블럭(335 및 347) 및 도 15의 블럭(365 및 377)에서의 가상 플러쉬 동작은 도 17-1의 블럭(450)에서 개시되는 동작을 수행함으로써 행해진다. 호출되면, 판단 블럭(455)에서 플러쉬되는 가상 소켓 큐에 소정의 데이타가 존재하는지를 판정한다. 가상 소켓 큐에 데이타가 존재하지 않으면, 플러쉬 동작은 종료되어 블럭(455)의 부정 경로의 호출 함수로 반환된다. 그러나, 큐에 데이타가 존재하면, 블럭(455)의 긍정 경로가 선택되고, 블럭(460)에서 가상 소켓 큐가 다중 소켓에 대한 것인지를 판정한다. 만일 다중 소켓이 존재하면, 블럭(461)에 도시된 바와 같이 소켓에 대해 고유의 식별자 및 전송자의 데이타의 크기를 나타내고 3 바이트로 구성된 소켓 헤더가 실제 소켓 버퍼에 부가된다. 다중 소켓이든지 혹은 단방향 소켓이든지 간에, 블럭(462)에 도시된 바와 같이 실제 소켓에 대한 데이타는 실제 소켓 버퍼로 이동된다. 실제 소켓 버퍼가 충만하면, 블럭(465)의 긍정 경로가 선택되고, 블럭(466)에 도시된 바와 같이 실제 소켓 버퍼로부터의 데이타는 실제 소켓상으로 전송된다. 만일 실제 버퍼가 충만되지 않으면, 블럭(465)의 부정 경로가 선택된다. 이어서, 가상 플러쉬 함수는 소정의 다른 다중 가상 소켓 큐상에 실제 소켓에 전송되는 소정의 다른 데이타가 존재하는지를 판정한다. 만일 조건이 긍정이면, 블럭(470)의 긍정 경로가 선택되고, 가상 플러쉬 동작이 다시 호출되어 다른 가상 소켓 큐들중 하나가 플러쉬될 때까지 실제 소켓 버퍼내의 데이타는 전송되지 않는다. 만일 다른 데이타가 존재하지 않거나 혹은 다른 다중 가상 소켓으로부터 데이타가 부가되면, 블럭(466)의 동작이 수행되고, 실제 소켓 버퍼내의 데이타는 실제 소켓상으로 전송된다. 가상 플러쉬 동작을 호출한 함수에 대응하는 가상 소켓 큐내의 모든 데이타가 실제 소켓으로 전송된 후에, 블럭(467)에서 가상 플러쉬 동작이 종료된다.

도 14의 블럭(342 및 348) 및 도 15의 블럭(372 및 378)에 도시된 가상 폐쇄 동작은 도 17-2의 블럭(480)에서 개시되는 동작을 수행함으로써 행해진다. 가상 폐쇄 동작이 호출되면, 블럭(485)에 도시된 바와 같이 가상 폐쇄가 다중 가상 소켓인지를 판정한다. 만일 가상 폐쇄가 다중 가상 소켓이면, 블럭(485)의 긍정 경로가 선택되고, 폐쇄 동작 표시자가 가상 소켓 큐에 부가된다. 가상 폐쇄가 다중 가상 소켓이든지 아니든지 간에 가상 폐쇄 동작은 블럭(487)에 도시된 바와 같이 가상 플러쉬 동작을 호출하고, 블럭(488)에서 실제 소켓으로부터의 접속을 해제한다. 이어서, 블럭(490)에 도시된 바와 같이 가상 폐쇄가 단방향 가상 소켓인지를 판정하며, 만일 조건이 충족되지 않으면, 블럭(495)의 부정 경로가 선택된다. 가상 폐쇄가 다중 가상 소켓이므로, 블럭(495)에서 가상 폐쇄가 최종 다중 가상 소켓인지를 판정하고, 만일 가상 폐쇄가 최종 다중 가상 소켓이면 블럭(496)에 도시된 바와 같이 다중 활성 타이머를 세트시킨다. 만일 가상 폐쇄가 최종 다중 가상 소켓이 아니면, 블럭(496)을 스킵(skip)한다.

블럭(496)에서 가상 폐쇄가 단방향 가상 소켓이면, 블럭(491)에 도시된 바와 같이 이벤트 리스트로부터 대응하는 실제 소켓이 제거되고, 블럭(492)에 도시된 바와 같이 실제 소켓이 폐쇄되고 제거된다. 이러한 소켓이 단방향 또는 다중 가상 소켓이든지 간에 가상 소켓은 블럭(497)에서 폐쇄된 것으로 표시되고, 블럭(498)에서 폐쇄 동작을 종료한다.

이하, 도 16-1 내지 도 16-4 및 도 17-1 및 도 17-2와 관련하여 도 13을 기술할 것이다. 실제 이벤트가 발생되면, 도 13의 블럭(302)을 통과하고, 소켓 관리자는 이벤트가 어떻게 발생되었는지를 기초로 하여 이벤트를 조사한다. 만일 이벤트가 도 17-2의 블럭(496)에서 세트된 다중 소켓 활성 타이머를 타이밍 아웃하면, 도 13의 블럭(305)에서 블럭(312)로 진행되는 경로가 선택된다. 이어서, 도 13에 도시된 바와 같이 블럭(312 및 313)의 동작은 소켓 관리자에 의해 수행되어, 다중 실제 소켓을 폐쇄하고, 클라이언트측 인터셉트 모듈을 서버측 인터셉트 모듈에 접속하는 소켓에 대응하는 다중 실제 소켓을 제거한다. 이어서, 소켓 관리자는 후속 실제 이벤트를 대기한다. 이러한 다중 이벤트 타이머는 블럭(322)에 도시된 바와 같이 다중 가상 소켓을 생성함으로써 리셋된다.

실제 소켓상에서 발생되는 이벤트가 웹 서버와 서버측 인터셉트 모듈 사이의 소켓 접속상에서 폐쇄 동작을 수행하는 웹 서버와 같은 실제 소켓 폐쇄이면, 도 13의 블럭(305)에서 블럭(309)로 진행되는 경로가 선택된다. 소켓 관리자는 블럭(309)에 도시된 바와 같이 실제 이벤트 리스트로부터 실제 소켓을 제거하고, 블럭(310)에 도시된 바와 같이 실제 소켓(들)로부터의 다수의 다중 소켓인 경우 가상 소켓(들)을 접속 해제한다. 이어서, 소켓 관리자는 가상 소켓을 폐쇄로서 표시하고 가상 이벤트에 신호한다. 이러한 동작은 블럭(311)에 도시되어 있으며, 가상 소켓 큐로부터 모든 데이타가 존재하지 않으면, 가상 소켓은 폐쇄될 것이다. 가상 소켓이 폐쇄된 것으로 표시된 후, 판단 블럭(315)에 도시된 바와 같이 소켓 관리자는 폐쇄되는 실제 소켓이 단방향 소켓인지를 판정한다. 이어서, 블럭(302)에 도시된 바와 같이 소켓 관리자는 후속 실제 이벤트를 대기한다.

실제 소켓이 폐쇄되는 단방향 실제 소켓이 아니면, 블럭(315)의 부정 경로가 선택되고, 이어서 소켓 관리자는 후속 실제 이벤트를 대기한다. 따라서, 다중 실제 소켓 또는 클라이언트측 인터셉트 모듈 및 서버측 인터셉트 모듈을 접속하는 소켓은 다중 소켓 활성 타이머를 타이밍 아웃함으로써 유일하게 폐쇄될 수 있다. 이로 인해, 모듈들 간의 최종 통신이 사용자에 의해 지정된 사전설정된 시간 동안 발생된 후에도 클라이언트측 인터셉트 모듈과 서버측 인터셉트 모듈간의 접속을 계속 유지할 수 있다. 다중 소켓 활성 타이머를 타이밍 아웃하기 전에 브라우저로부터 차후 접속이 요구되는 경우, 클라이언트측 인터셉트 모듈과 서버측 인터셉트 모듈간의 접속을 재설정하지 않고서도 통신을 수행할 수 있으며, 그 결과 접속을 재설정하기 위한 오버헤드를 줄일 수 있다.

도 13에 도시된 최종 경로는 실제 이벤트가 발생될 때 이벤트가 도 12의 다중 실제 소켓(들)(36a 또는 36b)상의 데이타를 수신하는 것에 관한 것이다. 다중 실제 소켓상의 데이타를 수신할 때 이 데이타를 조사하고, 도 17-2의 블럭(486)에서 가상 큐에 부가되는 것과 같이 데이타가 폐쇄 동작 표시자를 포함하면, 가상 폐쇄 동작이 수행되고, 블럭(320)에서 블럭(310)으로 진행되는 경로가 선택된다. 소켓 관리자는 블럭(310)에 도시된 바와 같이 실제 소켓상에서 수신된 데이타로 식별된 다중 가상 소켓을 실제 소켓으로부터 접속 해제시키고, 블럭(311)에 도시된 바와 같이 가상 소켓을 폐쇄로서 표시하고, 가상 이벤트에 신호한다. 폐쇄 소켓이 다중 가상 소켓에 대한 것이므로, 블럭(315)의 부정 경로가 선택되고, 소켓 관리자는 블럭(302)에 도시된 바와 같이 다른 실제 이벤트를 대기한다.

도 13∼17에 도시된 동작을 수행함으로써, 본 발명의 특정한 실시예에서는 외부 통신 링크를 통해 제 1 컴퓨터와 제 2 컴퓨터 사이에 지속적인 접속(persistent connection)을 설정한다. 지속적인 접속은 모든 웹 브라우저에 의해 개시된 통신이 완료되고 다수의 웹 브라우저에 의해 개시된 통신이 인터셉트될 때까지 유지되며, 지속적인 접속이 유지되는 동안 외부 통신 링크상에서 이들 통신이 멀티플렉싱된다. 이어서, 클라이언트/서버 지정 데이타 스트림을 디멀티플렉싱하여 다수의 HTTP 데이타 스트림을 생성하고, 다수의 HTTP 데이타 스트림은 웹 서버에 제공된다. 또한, 지속적인 접속은 웹 서버에 의해 개시된 통신이 모두 완료될 때까지 유지된다. 지속적인 접속이 유지되는 동안 웹 서버에 의해 개시된 다수의 통신이 인터셉트되고 외부 통신 링크상에서 멀티플렉싱된다. 또한, 클라이언트/서버 지정 데이타 스트림을 디멀티플렉싱하여, 다수의 HTTP 데이타 스트림 및 웹 서버에 제공되는 다수의 HTTP 데이타 스트림을 생성할 수 있다.

본 발명의 바람직한 실시예가 개시된 도면 및 명세서에서는 특정한 용어들이 사용되고 있지만, 이들 용어는 일반적이고 서술적인 의미로만 사용되며 이하의 특허 청구범위에 정의된 본 발명의 영역을 제한하고자 의도한 것은 아니다.

Claims (21)

1. 제 1 애플리케이션(a first application)으로부터 수신되고, 제 2 애플리케이션(a second application)으로부터의 요구에 응답하여

   상기 제 2 애플리케이션으로 제공되는 데이타를 캐쉬(cache)하는 방법에 있어서,

   ① 상기 제 1 애플리케이션으로부터 수신되고 상기 제 2 애플리케이션으로 제공되는 데이타 스트림(a data stream)을 캐쉬에 저장하여, 상기 제 2 애플리케이션으로부터의 요구에 대응하는 클라이언트 캐쉬 엔트리(a client cache entry)를 생성하는 단계와,

   ② 상기 클라이언트 캐쉬 엔트리가 생성된 시간을 저장하여 클라이언트 캐쉬 엔트리의 시간 기록(a client cache entry time record)을 생성하는 단계와,

   ③ 상기 제 2 애플리케이션으로부터의 요구를 질의(interrogate)하여 상기 요구에 대응하는 클라이언트 캐쉬 엔트리가 존재하는지를 판정하는 단계와,

   ④ 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 클라이언트 캐쉬 엔트리에 대한 상기 클라이언트 캐쉬 엔트리의 시간 기록을 평가(evaluate)하여, 상기 제 2 애플리케이션이 정보를 요구하기 전에 사전설정된 클라이언트 코히어런시 시간 구간(a predetermined client coherency time interval) 동안 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 클라이언트 캐쉬 엔트리가 생성되었는지를 판정하는 단계와,

   ⑤ 상기 평가 단계에서 상기 제 2 애플리케이션이 정보를 요구하기 전에 사전설정된 클라이언트 코히어런시 시간 구간 동안 상기 제 2 애플리케이션에 대한 클라이언트 캐쉬 엔트리가 생성된 것으로 판정되면, 상기 클라이언트 캐쉬 엔트리를 상기 요구에 응답하는 상기 제 2 애플리케이션에 제공하는 단계를 포함하는

   데이타 캐쉬 방법.
2. 제 1 항에 있어서,

   상기 제 2 애플리케이션의 다수의 인스탄스(multiple instances)에 걸쳐 클라이언트 캐쉬 엔트리를 보유하는 단계를 더 포함하는 데이타 캐쉬 방법.
3. 제 1 항에 있어서,

   상기 제 1 애플리케이션은 상기 제 1 컴퓨터에 상주하고, 상기 제 2 애플리케이션은 상기 제 2 컴퓨터에 상주하고, 상기 제 1 및 제 2 애플리케이션은 외부 통신 링크(an external communication link)를 통해 서로 통신하고,

   ① 상기 제 2 애플리케이션으로부터의 요구에 응답하여 상기 제 1 애플리케이션으로부터의 상기 데이타 스트림을 상기 제 1 컴퓨터에 상주하는 캐쉬에 저장하여 서버 요구 캐쉬 엔트리(a server request cache entry)를 생성하는 단계와,

   ② 상기 제 2 애플리케이션에 의해 개시된 요구를 질의(interrogate)하여, 상기 요구에 대응하는 서버 요구 캐쉬 엔트리가 상기 캐쉬내에 이전에 저장되었는지를 판정하는 단계와,

   ③ 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 서버 요구 캐쉬 엔트리를 상기 외부 통신 링크를 통해 상기 제 2 컴퓨터에 상주하는 상기 제 2 애플리케이션에 전송(send)하는 단계를 더 포함하는

   데이타 캐쉬 방법.
4. 제 3 항에 있어서,

   상기 제 1 컴퓨터가 상기 요구를 수신하기 전에 사전설정된 클라이언트 코히어런시 시간 구간 동안 상기 제 2 애플리케이션으로부터의 요구에 대응하는 서버 요구 캐쉬 엔트리가 생성되었는지를 판정(determine)하는 단계를 더 포함하고,

   상기 전송 단계는 상기 판정 단계에 의해 상기 사전설정된 클라이언트 코히어런시 시간 구간 동안 상기 서버 요구 캐쉬 엔트리가 생성된 것으로 판정된 경우에 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 서버 요구 캐쉬 엔트리를 전송하는 단계를 포함하는

   데이타 캐쉬 방법.
5. 제 3 항에 있어서

   상기 요구에 대응하는 서버 캐쉬 엔트리와 동일한 상기 제 2 애플리케이션으로부터의 요구에 대응하는 클라이언트 캐쉬 엔트리가 존재하는지를 판정하는 단계와,

   상기 컴퓨터가 상기 제 2 애플리케이션으로부터의 요구를 수신했을 때의 시간과 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 서버 요구 캐쉬 엔트리가 생성되었을 때의 시간 사이의 시간 구간을 계산(calculate)하여 엔트리 수명 데이타(entry age data)를 제공하는 단계와,

   상기 전송 단계는 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 서버 캐쉬 엔트리에 대한 상기 엔트리 수명 데이타를 상기 제 2 컴퓨터에 상주하는 상기 제 2 애플리케이션에 전송하는 단계를 포함하고,

   상기 제 2 컴퓨터의 현재의 시간에서 상기 제 1 컴퓨터로부터 수신된 상기 엔트리 수명 데이타를 감산하여, 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 클라이언트 캐쉬 엔트리 시간 기록을 갱신하는 단계를 더 포함하는

   데이타 캐쉬 방법.
6. 제 1 항에 있어서,

   상기 제 2 애플리케이션은 웹 브라우저(a web browser)이고, 상기 제 1 애플리케이션은 웹서버(a web server)인 데이타 캐쉬 방법.
7. 제 3 항에 있어서,

   상기 제 1 애플리케이션은 웹 서버이고, 상기 애플리케이션은 웹 브라우저이고, 상기 제 1 및 제 2 컴퓨터는 무선 통신 링크를 통해 통신하는 데이타 캐쉬 방법.
8. 제 1 애플리케이션으로부터 수신되고, 제 2 애플리케이션으로부터의 요구에 응답하여 상기 제 2 애플리케이션으로 제공되는 데이타를 캐쉬하는 장치에 있어서,

   ① 상기 제 1 애플리케이션으로부터 수신되고 상기 제 2 애플리케이션으로 제공되는 데이타 스트림을 캐쉬에 저장하여, 상기 제 2 애플리케이션으로부터의 요구에 대응하는 클라이언트 캐쉬 엔트리를 생성하는 수단과,

   ② 상기 클라이언트 캐쉬 엔트리가 생성된 시간을 저장하여 클라이언트 캐쉬 엔트리의 시간 기록을 생성하는 수단과,

   ③ 상기 제 2 애플리케이션으로부터의 요구를 질의하여 상기 요구에 대응하는 클라이언트 캐쉬 엔트리가 존재하는지를 판정하는 수단과,

   ④ 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 클라이언트 캐쉬 엔트리에 대한 상기 클라이언트 캐쉬 엔트리의 시간 기록을 평가하여, 상기 제 2 애플리케이션이 정보를 요구하기 전에 사전설정된 클라이언트 코히어런시 시간 구간 동안 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 클라이언트 캐쉬 엔트리가 생성되었는지를 판정하는 수단과,

   ⑤ 상기 평가 단계에서 상기 제 2 애플리케이션이 정보를 요구하기 전에 사전설정된 클라이언트 코히어런시 시간 구간 동안 상기 제 2 애플리케이션에 대한 클라이언트 캐쉬 엔트리가 생성되었으면, 상기 클라이언트 캐쉬 엔트리를 상기 요구에 응답하는 상기 제 2 애플리케이션에 제공하는 수단을 포함하는

   데이타 캐쉬 장치.
9. 제 8 항에 있어서,

   상기 제 2 애플리케이션의 다수의 인스탄스에 걸쳐 클라이언트 캐쉬 엔트리를 보유하는 단계를 더 포함하는 데이타 캐쉬 장치.
10. 제 8 항에 있어서,

    상기 제 1 애플리케이션은 상기 제 1 컴퓨터에 상주하고, 상기 제 2 애플리케이션은 상기 제 2 컴퓨터에 상주하고, 상기 제 1 및 제 2 애플리케이션은 외부 통신 링크를 통해 서로 통신하고,

    ① 상기 제 2 애플리케이션으로부터의 요구에 응답하여 상기 제 1 애플리케이션으로부터의 상기 데이타 스트림을 상기 제 1 컴퓨터에 상주하는 캐쉬에 저장하여 서버 요구 캐쉬 엔트리를 생성하는 수단과,

    ② 상기 제 2 애플리케이션에 의해 개시된 요구를 질의하여, 상기 요구에 대응하는 서버 요구 캐쉬 엔트리가 상기 캐쉬내에 이전에 저장되었는지를 판정하는 수단과,

    ③ 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 서버 요구 캐쉬 엔트리를 상기 외부 통신 링크를 통해 상기 제 2 컴퓨터에 상주하는 상기 제 2 애플리케이션에 전송하는 수단을 더 포함하는

    데이타 캐쉬 장치.
11. 제 10 항에 있어서,

    상기 제 1 컴퓨터가 상기 요구를 수신하기 전에 사전설정된 클라이언트 코히어런시 시간 구간 동안 상기 제 2 애플리케이션으로부터의 요구에 대응하는 서버 요구 캐쉬 엔트리가 생성되었는지를 판정하는 수단을 더 포함하고,

    상기 전송 수단은 상기 판정 수단에 의해 상기 사전설정된 클라이언트 코히어런시 시간 구간 동안 상기 서버 요구 캐쉬 엔트리가 생성된 것으로 판정된 경우에 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 서버 요구 캐쉬 엔트리를 전송하는 수단을 포함하는

    데이타 캐쉬 장치.
12. 제 10 항에 있어서,

    상기 요구에 대응하는 서버 캐쉬 엔트리와 동일한 상기 제 2 애플리케이션으로부터의 요구에 대응하는 클라이언트 캐쉬 엔트리가 존재하는지를 판정하는 수단과,

    상기 컴퓨터가 상기 제 2 애플리케이션으로부터의 요구를 수신했을 때의 시간과 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 서버 요구 캐쉬 엔트리가 생성되었을 때의 시간 사이의 시간 구간을 계산(calculate)하여 엔트리 수명 데이타를 제공하는 수단과,

    상기 전송 수단은 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 서버 캐쉬 엔트리에 대한 상기 엔트리 수명 데이타를 상기 제 2 컴퓨터에 상주하는 상기 제 2 애플리케이션에 전송하는 수단을 포함하고,

    상기 제 2 컴퓨터의 현재의 시간에서 상기 제 1 컴퓨터로부터 수신된 상기 엔트리 수명 데이타를 감산하여, 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 클라이언트 캐쉬 엔트리 시간 기록을 갱신하는 수단을 더 포함하는

    데이타 캐쉬 장치.
13. 제 8 항에 있어서,

    상기 제 2 애플리케이션은 웹 브라우저이고, 상기 제 1 애플리케이션은 웹서버인 데이타 캐쉬 장치.
14. 제 10 항에 있어서,

    상기 제 1 애플리케이션은 웹 서버이고, 상기 애플리케이션은 웹 브라우저이고, 상기 제 1 및 제 2 컴퓨터는 무선 통신 링크를 통해 통신하는 데이타 캐쉬 장치.
15. 제 1 애플리케이션으로부터 수신되고, 제 2 애플리케이션으로부터의 요구에 응답하여 상기 제 2 애플리케이션으로 제공되는 데이타를 캐쉬하는 컴퓨터 프로그램 제품(a computer program product)에 있어서,

    컴퓨터에 의해 판독가능한 프로그램 코드 수단을 자체 내장하여 구비한 컴퓨터 판독가능한 저장 매체를 포함하고, 상기 컴퓨터 판독가능한 프로그램 코드 수단은,

    ① 상기 제 1 애플리케이션으로부터 수신되고 상기 제 2 애플리케이션으로 제공되는 데이타 스트림을 캐쉬에 저장하여, 상기 제 2 애플리케이션으로부터의 요구에 대응하는 클라이언트 캐쉬 엔트리를 생성하는 컴퓨터에 의해 판독가능한 프로그램 코드 수단과,

    ② 상기 클라이언트 캐쉬 엔트리가 생성된 시간을 저장하여 클라이언트 캐쉬 엔트리의 시간 기록을 생성하는 컴퓨터에 의해 판독가능한 프로그램 코드 수단과,

    ③ 상기 제 2 애플리케이션으로부터의 요구를 질의하여 상기 요구에 대응하는 클라이언트 캐쉬 엔트리가 존재하는지를 판정하는 컴퓨터에 의해 판독가능한 프로그램 코드 수단과,

    ④ 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 클라이언트 캐쉬 엔트리에 대한 상기 클라이언트 캐쉬 엔트리의 시간 기록을 평가하여, 상기 제 2 애플리케이션이 정보를 요구하기 전에 사전설정된 클라이언트 코히어런시 시간 구간 동안 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 클라이언트 캐쉬 엔트리가 생성되었는지를 판정하는 컴퓨터에 의해 판독가능한 프로그램 코드 수단과,

    ⑤ 상기 평가를 수행하는 컴퓨터에 의해 판독가능한 프로그램 코드 수단에 의해 상기 제 2 애플리케이션이 정보를 요구하기 전에 사전설정된 클라이언트 코히어런시 시간 구간 동안 상기 제 2 애플리케이션에 대한 클라이언트 캐쉬 엔트리가 생성된 것으로 판정되면, 상기 클라이언트 캐쉬 엔트리를 상기 요구에 응답하는 상기 제 2 애플리케이션에 제공하는 컴퓨터에 의해 판독가능한 프로그램 코드 수단을 포함하는

    컴퓨터 프로그램 제품.
16. 제 15 항에 있어서,

    상기 제 2 애플리케이션의 다수의 인스탄스에 걸쳐 클라이언트 캐쉬 엔트리를 보유하는 컴퓨터에 의해 판독가능한 프로그램 코드 수단을 더 포함하는 컴퓨터 프로그램 제품.
17. 제 15 항에 있어서,

    상기 제 1 애플리케이션은 상기 제 1 컴퓨터에 상주하고, 상기 제 2 애플리케이션은 상기 제 2 컴퓨터에 상주하고, 상기 제 1 및 제 2 애플리케이션은 외부 통신 링크를 통해 서로 통신하고,

    ① 상기 제 2 애플리케이션으로부터의 요구에 응답하여 상기 제 1 애플리케이션으로부터의 상기 데이타 스트림을 상기 제 1 컴퓨터에 상주하는 캐쉬에 저장하여 서버 요구 캐쉬 엔트리를 생성하는 컴퓨터에 의해 판독가능한 프로그램 코드 수단과,

    ② 상기 제 2 애플리케이션에 의해 개시된 요구를 질의하여, 상기 요구에 대응하는 서버 요구 캐쉬 엔트리가 상기 캐쉬내에 이전에 저장되었는지를 판정하는 컴퓨터에 의해 판독가능한 프로그램 코드 수단과,

    ③ 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 서버 요구 캐쉬 엔트리를 상기 외부 통신 링크를 통해 상기 제 2 컴퓨터에 상주하는 상기 제 2 애플리케이션에 전송하는 컴퓨터에 의해 판독가능한 프로그램 코드 수단을 더 포함하는

    컴퓨터 프로그램 제품.
18. 제 17 항에 있어서,

    상기 제 1 컴퓨터가 상기 요구를 수신하기 전에 사전설정된 클라이언트 코히어런시 시간 구간 동안 상기 제 2 애플리케이션으로부터의 요구에 대응하는 서버 요구 캐쉬 엔트리가 생성되었는지를 판정하는 컴퓨터에 의해 판독가능한 프로그램 코드 수단을 더 포함하고,

    상기 전송을 수행하는 컴퓨터에 의해 판독가능한 프로그램 코드 수단은 상기 판정을 수행하는 컴퓨터에 의해 판독가능한 프로그램 코드 수단에 의해 상기 사전설정된 클라이언트 코히어런시 시간 구간 동안 상기 서버 요구 캐쉬 엔트리가 생성된 것으로 판정된 경우에 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 서버 요구 캐쉬 엔트리를 전송하는 컴퓨터에 의해 판독가능한 프로그램 코드 수단을 포함하는

    컴퓨터 프로그램 제품.
19. 제 17 항에 있어서,

    상기 요구에 대응하는 서버 캐쉬 엔트리와 동일한 상기 제 2 애플리케이션으로부터의 요구에 대응하는 클라이언트 캐쉬 엔트리가 존재하는지를 판정하는 컴퓨터에 의해 판독가능한 프로그램 코드 수단과,

    상기 컴퓨터가 상기 제 2 애플리케이션으로부터의 요구를 수신했을 때의 시간과 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 서버 요구 캐쉬 엔트리가 생성되었을 때의 시간 사이의 시간 구간을 계산하여 엔트리 수명 데이타를 제공하는 컴퓨터에 의해 판독가능한 프로그램 코드 수단과,

    상기 전송을 수행하는 컴퓨터에 의해 판독가능한 프로그램 코드 수단은 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 서버 캐쉬 엔트리에 대한 상기 엔트리 수명 데이타를 상기 제 2 컴퓨터에 상주하는 상기 제 2 애플리케이션에 전송하는 컴퓨터에 의해 판독가능한 프로그램 코드 수단을 포함하고,

    상기 제 2 컴퓨터의 현재의 시간에서 상기 제 1 컴퓨터로부터 수신된 상기 엔트리 수명 데이타를 감산하여, 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 클라이언트 캐쉬 엔트리 시간 기록을 갱신하는 컴퓨터에 의해 판독가능한 프로그램 코드 수단을 더 포함하는

    컴퓨터 프로그램 제품.
20. 제 15 항에 있어서,

    상기 제 2 애플리케이션은 웹 브라우저이고, 상기 제 1 애플리케이션은 웹서버인 컴퓨터 프로그램 제품.
21. 제 17 항에 있어서,

    상기 제 1 애플리케이션은 웹 서버이고, 상기 애플리케이션은 웹 브라우저이고, 상기 제 1 및 제 2 컴퓨터는 무선 통신 링크를 통해 통신하는 컴퓨터 프로그램 제품.