KR100295003B1 - 데이타캐싱방법및장치 - Google Patents

데이타캐싱방법및장치 Download PDF

Info

Publication number
KR100295003B1
KR100295003B1 KR1019970707263A KR19970707263A KR100295003B1 KR 100295003 B1 KR100295003 B1 KR 100295003B1 KR 1019970707263 A KR1019970707263 A KR 1019970707263A KR 19970707263 A KR19970707263 A KR 19970707263A KR 100295003 B1 KR100295003 B1 KR 100295003B1
Authority
KR
South Korea
Prior art keywords
application
server
request
client
cache entry
Prior art date
Application number
KR1019970707263A
Other languages
English (en)
Other versions
KR19980703863A (ko
Inventor
리드 리차드 비틴저
미셀 레비 프렌켈
배론 코넬리어스 호우셀
데이비드 브루스 린드퀴스트
Original Assignee
포만 제프리 엘
인터내셔널 비지네스 머신즈 코포레이션
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 포만 제프리 엘, 인터내셔널 비지네스 머신즈 코포레이션 filed Critical 포만 제프리 엘
Publication of KR19980703863A publication Critical patent/KR19980703863A/ko
Application granted granted Critical
Publication of KR100295003B1 publication Critical patent/KR100295003B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Radio Relay Systems (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Analysing Materials By The Use Of Radiation (AREA)

Abstract

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

Description

데이타 캐싱 방법 및 장치{TIME COHERENT CACHING SYSTEM}
최근 "정보 고속도로(information superhighway)"에 대한 출판 및 관심에 의해 인터넷(Internet)이 대중 통신 매체로서 인식되고 채택되게 되었다. 또한, 이러한 인터넷이 다수의 네트워크를 거쳐 통신 및 대화하기 위한 실행가능한 매체로서 광범위하게 인식됨에 따라, 컴퓨터 네트워크들간의 대화를 위한 인터넷 표준 프로토콜에 대한 광범위한 사용자 기반(a large established user base)이 생겨났다.
이러한 인터넷에 대한 전형으로서 인터넷 클라이언트(브라우저)가 인터넷 서버와 통신하는 클라이언트 서버 관계를 들 수 있다. 인터넷이 보다 폭넓게 액세스될 수 있도록 클라이언트 및 서버에 의해 사용되는 통신 프로토콜 및 언어는 표준화되었다. 이들 프로토콜은 클라이언트와 서버 사이를 통신하는데 사용되는 통신 프로토콜인 HTTP(Hyper-Text Transfer Protocol)와 TCP/IP를 포함하며, 이들 중 TCP 부분은 컴퓨터 또는 애플리케이션들 사이에서 통신하기 위한 전송 특정 프로토콜(transport specific protocol)이다. 클라이언트 및 서버가 통신하는 HTML(Hyper-Text Markup Language)로 일컬어지는 언어도 또한 표준화된다. 이들 프로토콜 및 언어는 머신(machine)과 독립적이고, 정보를 전송하는데 있어서 비접속인 최선 프로토콜(connectionless best efforts protocol)을 이용하기 때문에, 각각의 트랜잭션(transaction)은 완전히 자체 내포적(self-contained)이다. 따라서, 예를 들어, 클라이언트로부터의 각각의 메시지는 브라우저의 성능에 대한 정보를 포함하며, 이 통신이 수행되는데 있어서 임의의 다른 통신과는 독립적이다. 이와 같이 클라이언트와 서버간의 통신의 자체 내포적인 특징은 "스테이트리스(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 NavigatorTM, NCSA MosaicTM, WebExplorerTM또는 임의의 다른 웹 브라우저를 웹 브라우저로서 사용하더라도 통신 프로토콜 및 언어는 동일하다. 따라서, 인터넷의 접속성과 결합된 웹 브라우저에 대한 사용자 기반이 넓어짐과 동시에 HTTP에 의해 정의된 공통 게이트웨이 인터페이스(Common Gateway Interface: CGI)를 사용하여 웹 애플리케이션 서버를 작성함에 있어서의 용이함으로 인해 웹 기술이 많은 부류의 폼(form) 기반 애플리케이션에 대해 매력적으로 되었다.
최근 인터넷이 대중화되고 보편화됨과 동시에 이동 컴퓨터도 또한 크게 일반화되었다. 랩탑, 노트북, 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을 이용하며, 마찬가지로 HTTP 및 HTML을 사용하는 인터넷 웹 서버(20)와 통신한다. 동작 시, 웹 브라우저(10)는 HTTP 데이타 스트림을 출력하며, 이 HTTP 데이타 스트림은 클라이언트측 인터셉트 모듈(30)에 의해 인터셉트된다. 클라이언트측 인터셉트 모듈(30)에 의한 HTTP 데이타 스트림의 인터셉트는 클라이언트측 인터셉트 모듈(30)이 127.0.0.1과 같은127 네트워크 번호를 갖는 IP 어드레스에서 상주하는 경우 TCP/IP의 루프백 특성(loop-back feature)을 이용함으로써 달성될 수 있다. 이어서, 클라이언트측 인터셉트 모듈(30)은 HTTP 데이타 스트림을 클라이언트/서버 특정 프로토콜(client-server specific protocol)로 변경하거나 혹은 변환하고, 클라이언트/서버 특정 데이타 스트림을 외부 통신 링크(35)상으로 전송한다. 서버측의 인터셉트 모듈(40)은 클라이언트/서버 특정 데이타 스트림을 수신하고, 웹 브라우저가 발신한 통신(web browser originated communication)에 대응하는 원래의 HTTP 데이타 스트림을 재구성한다. 이어서, 재구성된 HTTP 데이타 스트림은 웹 서버(20)로 전송된다. 웹 서버(20)는 통상적인 인터넷 웹 서버의 방식으로 HTTP 데이타 스트림에 응답한다. 본 기술 분야에 통상의 지식을 가진 자라면 이해하듯이, 웹 서버(20)는 또한 다수의 브라우저가 인터넷에 접속하도록 하는 프락시일 수 있다.
예를 들어, 특정 URL 홈 페이지에 대한 브라우저 요구에 응답하여 웹 서버(20)가 웹 브라우저(10)에 전송하기 위한 정보를 수신하면, 웹 서버(20)는 통신에 대응하는 HTTP 데이타 스트림을 웹 브라우저(10)로 출력한다. 웹 서버가 발신한 이와 같은 통신은 서버측 인터셉트 모듈(40)에 의해 인터셉트되고, 클라이언트/서버 특정 데이타 스트림으로 변환된다. 이어서, 이 웹 서버가 발신한 통신에 대응하는 클라이언트/서버 특정 데이타 스트림은 제 2 컴퓨터로부터 외부 통신 링크(35)를 통해 제 1 컴퓨터로 전송된다. 클라이언트/서버 특정 데이타 스트림은 클라이언트측 인터셉트 모듈(30)에 의해 수신되고, 웹 서버가 발신한 통신에 대응하는 원래의 HTTP 데이타 스트림이 재구성되어 웹 브라우저(10)로 제공된다.
본 발명의 특정한 실시예에 있어서, 외부 통신 링크(35)는 무선 통신 링크이다. 이 경우, 사용자가 받아들일 수 있을 정도의 시스템 성능을 얻기 위해서는 통신 링크(35)상에서의 통신 빈도 및 정보의 크기면에서 모두 외부 통신 링크(35)상으로 전송되어야 하는 통신의 양을 줄이는 것이 바람직하다. 따라서, 본 발명은 캐쉬 기법, 차분 기법 및 프로토콜 감축 기법을 이용하여 외부 통신 링크(35)상에서 필요로 하는 통신의 크기를 최소화할 수 있다. 이러한 기법들은 스테이트리스 프로토콜(stateless protocol) 또는 확률 프로토콜(stochastic protocol)인 HTTP를 클라이언트/서버 특정 프로토콜로 변환함으로써 구현되며, 클라이언트/서버 특정 프로토콜은 클라이언트 및 서버에 대해 특정된 정보를 이용하여 통신의 양 및 빈도를 줄일 수 있다.
본 발명은 단일 웹 브라우저 애플리케이션 및 단일 웹 서버 애플리케이션에 대해 기술되지만, 본 기술 분야에 통상의 지식을 가진 자라면 이해하듯이, 본 발명의 이점 및 장점들은 단일 웹 서버와 관련된 다수의 웹 브라우저를 이용함으로써 또한 달성될 수 있다. 따라서, 본 발명의 방법, 장치 및 프로그램 제품은 클라이언트측 인터셉트 모듈 및 이들 클라이언트측 인터셉트 모듈과 각각 통신하는 다수의 브라우저와 함께 웹 서버 또는 웹 프락시의 서버측 인터셉트 모듈과 통신할 수 있다.
본 발명의 하나의 실시예에 있어서, 클라이언트측 인터셉트 모듈(30) 및 서버측 인터셉트 모듈(40)은 캐싱 능력을 갖는다. 제 1 컴퓨터에 상주하는 클라이언트 캐쉬는 웹 브라우저가 발신한 통신에 응답하여 웹 브라우저가 수신하는 HTTP 데이타 스트림을 저장한다. 제 2 컴퓨터에 상주하는 서버 캐쉬는 브라우저가 발신한 통신에 응답하여 웹 서버가 수신하는 HTTP 데이타 스트림을 저장한다.
본 발명의 통상의 지식을 가진 자라면 이해하듯이, 제 1 컴퓨터 또는 제 2 컴퓨터에 상주하는 캐쉬는 컴퓨터의 특정 하드웨어 구성을 기초로 하여 어떤 크기라도 가질 수 있다. 이들 캐쉬는 통신 URL과, 통신 데이타 CRC(cyclic redundancy check)와 캐쉬 엔트리가 생성 또는 재생된 시간을 나타내는 저장 일시(store date time: SDT) 등과 같이 통신 내용에 기초한 고유의 식별자 및 통신 데이타를 포함하는 각각의 통신 정보를 저장한다. 따라서, 캐쉬 내에 저장된 각각의 통신에 대해 캐쉬 엔트리의 디렉토리가 생성될 수 있다. 또한, 소정의 주어진 하드웨어 구성에서의 가용 자원이 한정되어 있기 때문에, 제 1 컴퓨터 및 제 2 컴퓨터에 상주하는 캐쉬를 관리함에 있어 본 기술 분야에 통상의 지식을 가진 자에게 잘 알려진 캐쉬 방안들 중 임의의 방안을 이용할 수 있다. 따라서, 예를 들어, 캐쉬는 새로운 엔트리를 추가할 때 사용자 정의 캐쉬 사이즈를 초과하는 경우 가장 오래된 디렉토리 엔트리를 무효화(invalidate)하고, 무효화된 엔트리대신 새로운 엔트리를 추가할 수 있다. 또한, 복수 인스탄스(instances)의 웹 브라우저 또는 웹 서버 애플리케이션에 걸쳐 캐쉬 엔트리를 관리할 수 있거나 혹은 제 1 또는 제 2 컴퓨터의 파워온 사이클에 걸쳐 지속적 캐쉬(persistent cache)를 관리할 수도 있다.
이하, 클라이언트측 인터셉트 모듈(30) 및 서버측 인터셉트 모듈(40)의 동작을 기술한 흐름도인 도 3 내지 도 6을 참조하여 본 발명의 하나의 특징에 따른 캐쉬 구조의 동작이 기술될 것이다.
도 3을 참조하면, 블럭(100)은 클라이언트측 인터셉트 모듈(30)이 웹 브라우저(10)로부터 요구를 수신하는 것을 나타낸다. 이러한 요구는 HTTP 데이타 스트림의 형태를 취할 수 있다. 블럭(105)에서 클라이언트측 인터셉트 모듈(30)은 인입(incoming) 요구의 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에 대응하는 클라이언트 캐쉬 내용의 고유 표시자(indicia)를 외부 통신 링크(35)를 거쳐 서버측 인터셉트 모듈(40)에 제공함으로써 달성된다. 바람직한 실시예에 있어서, 이러한 고유 표시자는 캐쉬 엔트리에 대한 CRC 결과이다.
도 5를 참조하면, 외부 통신 링크(35)를 통해 클라이언트측 인터셉트 모듈(30)로부터 수신된 정보에 응답하여 수행되는 서버측 인터셉트 모듈의 동작이 도시되어 있다. 서버측 인터셉트 모듈(40)이 클라이언트측 인터셉트 모듈로부터 요구를 수신할 때, 서버측 인터셉트 모듈(40)은 사전설정된 클라이언트 코히어런시 시간 인터벌, 클라이언트 캐쉬 엔트리에 대한 CRC 값 및 웹 브라우저가 발신한 HTTP 요구를 수신한다. 이러한 정보의 수신은 도 5의 블럭(120)에 도시되어 있다.
클라이언트측 인터셉트 모듈(30)로부터 정보를 수신한 후, 서버측 인터셉트 모듈(40)은 제 2 컴퓨터에 상주하는 서버 캐쉬를 검사하여, 웹 브라우저가 발신한 HTTP 요구의 URL에 대응하는 서버 캐쉬 엔트리가 존재하는지를 판정한다. 블럭(125)에 도시된 바와 같이, 웹 브라우저가 발신한 통신에 대해 질의한 후, 웹 브라우저가 발신한 통신에 의해 요구된 정보에 대응하는 캐쉬 엔트리가 존재하는 것으로 서버측 인터셉트 모듈(40)이 판정하면, 블럭(125)의 "긍정" 경로가 선택된다. 이어서, 서버측 인터셉트 모듈(40)은 SSI 모듈(40)의 현재의 날짜 및 시간을 웹 브라우저가 발신한 통신에 의해 요구된 정보에 대응하는 서버 캐쉬 엔트리의 SDT와 클라이언트측 인터셉트 모듈로부터 수신된 사전설정된 클라이언트 코히어런시 시간 인터벌의 합과 비교한다.
현재의 날짜 및 시간이 서버 캐쉬 엔트리에 대한 SDT 및 코히어런시 인터벌의 합보다 작으면, 도 5의 블럭(130)의 "긍정" 경로가 선택된다. 이어서, 서버측인터셉트 모듈(40)은 서버 캐쉬 엔트리의 CRC를 클라이언트 캐쉬 엔트리의 CRC와 비교하여, 두개의 캐쉬 엔트리가 동일한지를 판정한다. 두개의 캐쉬 엔트리가 동일하면 블럭(135)의 "긍정" 경로가 선택되고, 블럭(136)에 도시된 바와 같이 "코히어런트" 응답이 클라이언트측 인터셉트 모듈(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를 저장한다.
그러나, 어느 블럭(166, 172 또는 173)의 동작에 의해 클라이언트 캐쉬 엔트리가 생성되더라도, 클라이언트측 인터셉트 모듈은 이 클라이언트 캐쉬 엔트리를 HTTP 데이타 스트림으로서 웹 브라우저(10)로 전송하거나 제공한다. 이들 동작은 도 4의 블럭(174)에 도시되어 있다.
본 기술 분야에 통상의 지식을 가진 자라면 이해하듯이, 클라이언트 캐쉬 및 서버 캐쉬는 메모리로 구현되거나 혹은 하드 디스크, 판독/기록 CD-ROM, 광 디스크 또는 다른 저장 기술과 같은 대량 저장장치로 구현될 수 있다. 또한, 본 기술 분야에 통상의 지식을 가진 자라면 이해하듯이, 클라이언트측 인터셉트 모듈과 서버측 인터셉트 모듈은 소프트웨어, 하드웨어 또는 이들을 조합하여 구현될 수 있다.
본 발명은 특정한 제 1 또는 제 2 컴퓨터에 상주하는 캐쉬를 참조하여 기술하였지만, 본 기술 분야에 통상의 지식을 가진 자라면 이해하듯이, 캐쉬를 제 1 컴퓨터에 상주시키지 않고 단순히 컴퓨터로서 외부 통신 링크의 동일한 곳에 위치시켜도 본 발명을 구현할 수 있다. 따라서, 하드웨어 캐쉬는 클라이언트 캐쉬로서 동작하는 제 1 컴퓨터 외부에서 구현되고 고속 통신에 의해 제 1 컴퓨터에 접속될 수 있으며, 캐쉬를 제 1 컴퓨터와 동일한 외부 통신 링크측에 위치시키면 본 발명의 장점들이 구현될 수 있다.
본 발명의 또 다른 실시예에 있어서, 서버측 인터셉트 모듈(40)은 웹 서버(20)로부터 수신된 HTTP 데이타 스트림의 사본을 보관하지 않고, 단순히 통신에 대한 디렉토리 엔트리만을 보관한다. 디렉토리 엔트리는 통신 URL과, HTTP 데이타 스트림에 대해 계산된 CRC, HTTP 데이타 스트림이 웹 서버로부터 수신된 시간과, CRC가 계산될 때의 시간으로 세트된 통신 SDT를 포함할 수 있다. 이 경우, 클라이언트측 인터셉트 모듈(30)에 의해 서버측 인터셉트 모듈이 CRC 및 SDT를 보유하는 URL에 대응하는 요구가 전송되면, 서버측 인터셉트 모듈은 클라이언트측 인터셉트 모듈(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)로 제공되는 첫 번째 HTTP 데이타 스트림을 저장함으로써 초기화될 수 있다. 다수의 인스탄스 또는 세션의 웹 브라우저(10)에 걸쳐 이러한 클라이언트 기본 캐쉬 엔트리를 보관할 수 있다. 클라이언트 기본 캐쉬 엔트리는 도 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 요구와, CRC 요구를 전송하며, 이때 CRC는 CGI 요구의 URL에 대한 클라이언트 기본 캐쉬 엔트리가 존재하지 않는 경우 널로 세트되고 엔트리가 존재하는 경우 클라이언트 기본 캐쉬 엔트리의 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 요구에 대한 응답을 처음으로 수신할 때 서버 기본 캐쉬 엔트리가 생성될 수 있다. 이 경우, 블럭(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와, CGI 요구에 대한 응답이 클라이언트 기본 캐쉬 엔트리와 동일함을 나타내도록, 널로 된 HTTP 데이타 스트림 데이타와 널로 된 차분 데이타를 전송함으로써 서버측 인터셉트 모듈(40)은 웹 서버(20)로부터 수신된 HTTP 데이타 스트림을 클라이언트/서버 특정 통신 프로토콜로변환한다.
블럭(245)으로 돌아가서, CGI 요구에 대응하는 서버 기본 캐쉬 엔트리에 대한 CRC가 웹 브라우저가 발신한 CGI 요구에 응답하여 웹 서버로부터 수신된 응답에 대한 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가 서버 기본 캐쉬 엔트리의 CRC와 동일한지 혹은 서버 CGI 기본 폼이 웹 브라우저가 발신한 통신의 특정한 CGI 요구에 대응하는 서버 및 클라이언트의 기본 캐쉬 엔트리인 클라이언트 CGI 기본 폼과 동일한지를 판정한다. 이들 기본 폼이 동일하면, 블럭(251)에 도시된 바와 같이 클라이언트는 기본 캐쉬를 재설정할 필요가 없으며, HTTP 데이타 스트림 정보는 널로 된다. 이어서, 서버측 인터셉트 모듈(40)은 CGI 요구에 대응하는 서버 기본 캐쉬 엔트리의 CRC(즉, 서버 CGI 기본 폼의 CRC)를 전송하고, 기본 데이타에 대응하는 널로 된 HTTP 데이타 스트림을 전송하고, 블럭(246)에서 결정된 차분 데이타를 전송함으로써, 차분 응답을 클라이언트측 인터셉트 모듈(30)에 전송한다. 이러한 동작은 도 10의 블럭(252)에 도시되어 있다.
서버측 인터셉트 모듈(40)에 의해 클라이언트 CGI 기본 폼 및 서버 CGI 기본 폼에 대한 이들 CRC가 동일하지 않은 것으로 판정되면, 클라이언트는 기본 캐쉬가재설정될 필요가 없다. 클라이언트의 기본 캐쉬 재설정 동작에서는 서버 CGI 기본 폼을 클라이언트측 인터셉트 모듈(30)에 전송하는 단계를 포함한다. 이러한 동작을 수행하기 위해 서버측 인터셉트 모듈은 클라이언트측 인터셉트 모듈(30)에 전송될 HTTP 데이타 스트림 데이타를 서버 CGI의 기본 폼으로 세트시킨다. 이러한 동작은 블럭(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)에서, 클라이언트측 인터셉트 모듈(30)은 클라이언트 CGI 기본 폼을 외부 통신 링크(35)를 통해 수신된 CGI 차분 데이타와 조합함으로써 외부 통신 링크(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에 도시된 바와 같이, 제 1 컴퓨터(5)와 제 2 컴퓨터(6)는 외부 통신 링크(35)를 통해 접속된다. 웹 브라우저(10)는 웹 브라우저(10)와 클라이언트측 인터셉트 모듈(30)을 접속하는 다수의 실제 소켓을 포함한다. 도 11에 도시된 바와 같이, 참조부호(65A)로 도시된 제 1 실제 소켓은 웹 브라우저(10)상에 위치되고, 참조부호(65B)로 도시된 대응하는 소켓은 클라이언트측 인터셉트 모듈(30)상에 위치되어 있다. 제 1 실제 소켓은 TCP 소켓으로서, 웹 브라우저(10)는 이 소켓을 통해 클라이언트측 인터셉트 모듈(30)로부터의 후속적인 접속을 요구한다.
웹 브라우저(10)가 새로운 TCP 접속을 요구하면, 실제 소켓(65A)을 통해 통신이 발생하여 실제 소켓(65B)에서 수신된다. 이어서, 클라이언트측 인터셉트 모듈(30)은 웹 브라우저(10)와의 통신을 위해 또 다른 실제 소켓을 생성할 것이다.도 11에 도시된 바와 같이, 웹 브라우저(10)상에는 다수의 실제 소켓이 생성되고, 클라이언트측 인터셉트 모듈(30)상에는 또한 대응하는 실제 소켓이 생성된다. 이들 실제 소켓은 웹 브라우저(10)상에서 참조부호(60A∼64A)로 도시되고, 클라이언트측 인터셉트 모듈(30)상에서 참조부호(60B∼64B)로 도시되어 있다. 이들 실제 소켓을 통해 웹 브라우저(10)는 클라이언트측 인터셉트 모듈(30)과의 통신을 수행한다. 실제 소켓(60A∼64A 및 60B∼64B)을 생성한 후, 이들 소켓을 통해 이루어지는 통신은 실제 소켓(36A)상에서 멀티플렉싱되며, 실제 소켓(36A)은 클라이언트측 인터셉트 모듈(30)을 외부 통신 링크(35)에 액세스시킨다. 실제 소켓(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)에 도시된 바와 같이, 실제 소켓 관리자는 단방향(simplex) 가상 소켓을 생성한다. 도 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)에 도시된 바와 같이 이벤트를 검사한다. 만일 이벤트가 가상 소켓 종료(virtual socket close)이면, 클라이언트측 인터셉트 함수(80)는 블럭(349)에 도시된 바와 같이 단방향 가상 소켓(70)을 삭제하고 도 14의 블럭(350)에서 종료한다.
만일 이벤트가 "데이타 수신(receipt of data)"이면, 블럭(330)에서 블럭(331)으로 진행되는 경로가 선택되고, 클라이언트측 인터셉트 함수(80)는 도 16-3을 참조하여 본 명세서에서 기술된 가상 수신 동작을 실행함으로써 단방향 가상 소켓(70)으로부터 브라우저가 발신한 통신을 수신한다. 이어서, 블럭(332)에 도시된 바와 같이 클라이언트측 인터셉트 함수는 전술한 바와 같이(예를 들어 도 3 및 도 7을 참조) 클라이언트측 인터셉트 모듈의 함수를 수행한다. 이어서, 클라이언트측 인터셉트 함수(80)는 클라이언트측 인터셉트 모듈(30)의 실제 소켓(36A)에 접속된 다중 가상 소켓(90)을 생성한다. 실제 소켓(36a)은 서버측 인터셉트 모듈(40)상의 실제 소켓(36b)과 접속된다. 다중 가상 소켓의 생성은 도 14의 블럭(333)에 도시되어 있으며, 도 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 실제 소켓을 생성하는 경우, 서버측 인터셉트 모듈(40)은 클라이언트측 인터셉트 모듈(30)로부터 서버측 인터셉트 모듈(40)과 관련된 소켓에 대한 요구를 수신하기 위해 "기지(旣知)의 포트"(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)에 큐잉되고, 가상 이벤트가 신호(signal)된다.
블럭(323)에 도시된 바와 같은 서버측 인터셉트 함수의 생성은 도 15의 블럭(360)에 도시되어 있다. 서버측 인터셉트 함수(85)를 생성한 후, 함수는 클라이언트측 인터셉트 모듈(30)로부터 제공되고 웹 브라우저가 발신한 통신에 대응하는 다중 가상 소켓(95)으로부터 데이타를 수신한다. 이러한 동작은 도 15의 블럭(361)에 도시되어 있다. 클라이언트측 인터셉트 모듈로부터 데이타를 수신한 후, 서버측 인터셉트 함수(85)는 서버측 인터셉트 모듈에 대해 전술한 바와 같이 데이타를 처리한다. 블럭(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)에 도시되어 있다. 대기 동작은 도 16-4에 기술된 가상 선택 함수를 수행함으로써 실행될 수 있다. 서버측 인터셉트 함수(85)가 단방향 가상 소켓(75)을 생성하면, 이에 대응하는 실제 소켓(60C)도 또한 생성된다. 웹 브라우저가 발신한 통신을 단방향 가상 소켓(75)에 전송함으로써, 서버측 인터셉트 함수(85)는 웹 브라우저가 발신한 통신을 웹 서버에 전송한다.
서버측 인터셉트 모듈(40)이 실제 소켓(60C)상에서 웹 서버로부터 응답을 수신하면, 실제 이벤트가 발생되고, 서버 소켓 관리자(69)는 도 13의 블럭(302)을 빠져나와 진행하여 블럭(305)에 도시된 바와 같이 실제 소켓(60C)상에서 발생된 이벤트를 조사한다. 여기에서는 이벤트가 기존의 가상 소켓에 대한 데이타이고, 도 13의 블럭(320)에서 블럭(324)으로 진행되는 경로가 선택된다. 실제 소켓(60C)상에서 수신된 데이타는 가상 소켓(75)에 큐잉되고 가상 이벤트가 신호된다. 가상 이벤트가 신호되면, 가상측 인터셉트 함수(85)는 도 15의 블럭(366)을 빠져나와 블럭(370)에서 이벤트를 조사한다. 이벤트가 소켓 폐쇄(socket closed)이면, 에러상태가 발생되고, 도 15의 블럭(375)에 도시된 바와 같이 에러 메시지가 응답으로서 구축된다. 그러나, 이벤트가 데이타의 수신(receipt of data)이면, 블럭(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)에 도시된 바와 같이 이벤트를 조사할 것이다.
만일 이벤트 소켓 폐쇄(socket closed) 응답이면, 도 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 및 346) 또는 도 15의 블럭(364 및 376)에 도시된 가상 전송 동작을 수행하기 위해, 도 16-2의 블럭(420)으로부터 개시되는 동작이 수행된다. 데이타는 블럭(427)에 도시된 바와 같이 가상 소켓 큐에 추가되고, 이러한 추가 동작이 완료되면 블럭(428)에 도시된 바와 같이 전송 동작을 종료한다.
도 14의 블럭(331 및 341) 및 도 15의 블럭(361 및 371)에 도시된 가상 수신동작은 도 16-3의 블럭(430)에서 개시되는 동작을 수행함으로써 행해진다. 블럭(435)에 도시된 바와 같이, 가상 소켓 큐를 평가하여, 가상 소켓 큐에 소정의 데이타가 존재하는지를 판정한다. 만일 가상 소켓 큐 상에 데이타가 존재하면, 블럭(435)의 "긍정" 경로가 선택되고, 블럭(436)에 도시된 바와 같이 데이타는 수신 동작을 호출하는 함수에 반환된다. 만일 가상 소켓 큐 상에 데이타가 존재하지 않고 소켓이 폐쇄로 표시되지 않으면, 판단 블럭(440)의 "부정" 경로가 선택되고, 블럭(441)에 도시된 바와 같이 아무것도 반환하지 않는다. 그러나, 데이타가 큐 상에 존재하지 않고 소켓이 폐쇄로 표시되면, 블럭(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)한다.
블럭(490)에서 가상 폐쇄가 단방향 가상 소켓이면, 블럭(491)에 도시된 바와 같이 이벤트 리스트로부터 대응하는 실제 소켓이 삭제되고, 블럭(492)에 도시된 바와 같이 실제 소켓이 폐쇄되고 삭제된다. 이러한 소켓이 단방향 또는 다중 가상 소켓이든지 간에 가상 소켓은 블럭(497)에서 폐쇄된 것으로 표시되고, 블럭(498)에서 폐쇄 동작을 종료한다.
이하, 도 16-1 내지 도 16-4 및 도 17-1 및 도 17-2와 관련하여 도 13을 기술할 것이다. 실제 이벤트가 발생되면, 도 13의 블럭(302)을 빠져나오고, 소켓 관리자는 이벤트가 생성된 방식에 기초하여 이벤트를 조사한다. 만일 이벤트가 도 17-2의 블럭(496)에서 세트된 다중 소켓 활성 타이머의 타이밍 아웃(timing out)이면, 도 13의 블럭(305)에서 블럭(312)으로 진행되는 경로가 선택된다. 이어서, 도 13에 도시된 바와 같이 블럭(312 및 313)의 동작이 소켓 관리자에 의해 수행되어, 다중 실제 소켓을 폐쇄하고, 클라이언트측 인터셉트 모듈을 서버측 인터셉트 모듈에 접속하는 소켓에 대응하는 다중 실제 소켓을 삭제한다. 이어서, 소켓 관리자는 후속 실제 이벤트를 대기한다. 이러한 다중 이벤트 타이머는 블럭(322)에 도시된 바와 같이 다중 가상 소켓을 생성함으로써 리셋된다.
실제 소켓 상에서 발생되는 이벤트가 웹 서버와 서버측 인터셉트 모듈 사이의 소켓 접속 상에서 폐쇄 동작을 수행하는 웹 서버와 같은 실제 소켓 폐쇄이면, 도 13의 블럭(305)에서 블럭(309)으로 진행되는 경로가 선택된다. 소켓 관리자는 블럭(309)에 도시된 바와 같이 실제 이벤트 리스트로부터 실제 소켓을 삭제하고, 블럭(310)에 도시된 바와 같이 실제 소켓(들)로부터의 다수의 다중 소켓인 경우 가상 소켓(들)을 접속 해제한다. 이어서, 소켓 관리자는 가상 소켓을 폐쇄로서 표시하고 가상 이벤트를 신호한다. 이러한 동작은 블럭(311)에 도시되어 있으며, 가상 소켓 큐로부터 모든 데이타가 삭제되면, 가상 소켓은 폐쇄될 것이다. 가상 소켓을 폐쇄된 것으로 표시한 후, 판단 블럭(315)에 도시된 바와 같이 소켓 관리자는 폐쇄되는 실제 소켓이 단방향 소켓인지를 판정한다. 실제 소켓 폐쇄가 단방향소켓인 경우, 블럭(316)에 도시된 바와 같이 실제 소켓이 폐쇄되고 삭제된다. 이어서, 블럭(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 (14)

  1. 제 1 애플리케이션(a first application)으로부터 수신되고, 제 2 애플리케이션(a second application)으로부터의 요구에 응답하여 상기 제 2 애플리케이션으로 제공되는 데이타를 캐싱(cache)하는 방법에 있어서,
    ① 상기 제 1 애플리케이션으로부터 수신되고 상기 제 2 애플리케이션으로 제공되는 데이타 스트림(a data stream)을 제 1 캐쉬에 저장하여, 상기 제 2 애플리케이션으로부터의 요구에 대응하는 클라이언트 캐쉬 엔트리(a client cache entry)를 생성하는 단계와,
    ② 상기 클라이언트 캐쉬 엔트리가 생성된 시간을 저장하여 클라이언트 캐쉬 엔트리의 시간 기록(a client cache entry time record)을 생성하는 단계와,
    ③ 상기 제 2 캐쉬로부터의 요구에 응답하여 상기 제 1 애플리케이션으로부터의 상기 데이타 스트림을 저장하여 서버 요구 캐쉬 엔트리(a server request cache entry)를 생성하는 단계와,
    ④ 상기 제 2 애플리케이션이 발신하고 상기 제 1 애플리케이션이 수신한 요구를 질의(interrogate)하여, 상기 요구에 대응하는 서버 요구 캐쉬 엔트리가 상기 캐쉬 내에 이전에 저장되었는지를 판정하는 단계와,
    ⑤ 상기 요구에 대응하는 서버 캐쉬 엔트리와 동일한, 상기 제 2 애플리케이션으로부터의 요구에 대응하는 클라이언트 캐쉬 엔트리가 존재하는지를 판정하는 단계와,
    ⑥ 상기 클라이언트 캐쉬 엔트리가 상기 서버 캐쉬 엔트리와 동일한 경우, 상기 제 2 애플리케이션으로부터의 요구를 수신했을 때의 시간과 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 서버 요구 캐쉬 엔트리가 생성되었을 때의 시간 사이의 시간 구간을 계산(calculate)하여 엔트리 연령 데이타(entry age data)를 제공하는 단계와,
    ⑦ 상기 클라이언트 캐쉬 엔트리가 상기 서버 캐쉬 엔트리와 동일한 경우, 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 서버 요구 캐쉬 엔트리를 상기 제 2 애플리케이션에 전송(send)하는 단계와,
    ⑧ 상기 서버 캐쉬 엔트리가 상기 클라이언트 캐쉬 엔트리와 동일한 경우, 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 서버 캐쉬 엔트리에 대한 상기 엔트리 연령 데이터를 상기 제 2 애플리케이션으로 송신(transmit)하는 단계
    를 포함하는 데이터 캐싱 방법.
  2. 제 1 항에 있어서,
    상기 제 2 애플리케이션의 다수의 인스탄스(multiple instances)에 걸쳐 클라이언트 캐쉬 엔트리를 보유하는 단계를 더 포함하는 데이타 캐싱 방법.
  3. 제 1 항에 있어서,
    ⑨ 상기 제 2 애플리케이션으로부터의 요구를 질의(interrogate)하여 상기 요구에 대응하는 클라이언트 캐쉬 엔트리가 존재하는지를 판정하는 단계와,
    ⑩ 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 클라이언트 캐쉬 엔트리에 대한 상기 클라이언트 캐쉬 엔트리의 시간 기록을 평가(evaluate)하여, 상기 제 2 애플리케이션이 정보를 요구하기 전에 사전설정된 클라이언트 코히어런시 시간 구간(a predetermined client coherency time interval) 동안 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 클라이언트 캐쉬 엔트리가 생성되었는지를 판정하는 단계와,
    ⑪ 상기 평가 단계에서 상기 제 2 애플리케이션이 정보를 요구하기 전에 사전설정된 클라이언트 코히어런시 시간 구간 동안 상기 제 2 애플리케이션에 대한 클라이언트 캐쉬 엔트리가 생성된 것으로 판정되면, 상기 클라이언트 캐쉬 엔트리를 상기 요구에 응답하여 상기 제 2 애플리케이션에 제공하는 단계
    를 더 포함하는 데이터 캐싱 방법.
  4. 제 1 항에 있어서,
    상기 제 1 애플리케이션이 상기 요구를 수신하기 전에 사전설정된 클라이언트 코히어런시 시간 구간 동안 상기 제 2 애플리케이션으로부터의 요구에 대응하는 서버 요구 캐쉬 엔트리가 생성되었는지를 판정(determine)하는 단계를 더 포함하되,
    상기 전송 단계는 상기 판정 단계에 의해 상기 사전설정된 클라이언트 코히어런시 시간 구간 동안 상기 서버 요구 캐쉬 엔트리가 생성된 것으로 판정된 경우에 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 서버 요구 캐쉬 엔트리를 전송하는 단계를 포함하는
    데이타 캐싱 방법.
  5. 제 1 항에 있어서
    ⑫ 상기 제 2 애플리케이션의 현재의 시간에서 상기 제 1 애플리케이션로부터 수신된 상기 엔트리 연령 데이타를 감산하여, 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 클라이언트 캐쉬 엔트리 시간 기록을 갱신하는 단계를 더 포함하는
    데이타 캐싱 방법.
  6. 제 1 항에 있어서,
    상기 제 2 애플리케이션은 웹 브라우저(a web browser)이고, 상기 제 1 애플리케이션은 웹서버(a web server)인 데이타 캐싱 방법.
  7. 제 1 항에 있어서,
    상기 제 1 애플리케이션은 웹 서버이고, 상기 제 2 애플리케이션은 웹 브라우저이고, 상기 제 1 및 제 2 애플리케이션은 무선 통신 링크를 통해 통신하는
    데이타 캐싱 방법.
  8. 제 1 애플리케이션으로부터 수신되고, 제 2 애플리케이션으로부터의 요구에 응답하여 상기 제 2 애플리케이션으로 제공되는 데이타를 캐싱하는 장치에 있어서,
    ① 상기 제 1 애플리케이션으로부터 수신되고 상기 제 2 애플리케이션으로 제공되는 데이타 스트림을 제 1 캐쉬에 저장하여, 상기 제 2 애플리케이션으로부터의 요구에 대응하는 클라이언트 캐쉬 엔트리를 생성하는 수단과,
    ② 상기 클라이언트 캐쉬 엔트리가 생성된 시간을 저장하여 클라이언트 캐쉬 엔트리의 시간 기록을 생성하는 수단과,
    ③ 상기 제 2 캐쉬로부터의 요구에 응답하여 상기 제 1 애플리케이션으로부터의 상기 데이타 스트림을 저장하여 서버 요구 캐쉬 엔트리를 생성하는 수단과,
    ④ 상기 제 2 애플리케이션이 발신하고 상기 제 1 애플리케이션이 수신한 요구를 질의하여, 상기 요구에 대응하는 서버 요구 캐쉬 엔트리가 상기 캐쉬 내에 이전에 저장되었는지를 판정하는 수단과,
    ⑤ 상기 요구에 대응하는 서버 캐쉬 엔트리와 동일한, 상기 제 2 애플리케이션으로부터의 요구에 대응하는 클라이언트 캐쉬 엔트리가 존재하는지를 판정하는 수단과,
    ⑥ 상기 클라이언트 캐쉬 엔트리가 상기 서버 캐쉬 엔트리와 동일한 경우, 상기 제 2 애플리케이션으로부터의 요구를 수신했을 때의 시간과 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 서버 요구 캐쉬 엔트리가 생성되었을 때의 시간 사이의 시간 구간을 계산하여 엔트리 연령 데이타를 제공하는 수단과,
    ⑦ 상기 클라이언트 캐쉬 엔트리가 상기 서버 캐쉬 엔트리와 동일한 경우, 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 서버 요구 캐쉬 엔트리를 상기 제 2 애플리케이션에 전송하는 수단과,
    ⑧ 상기 서버 캐쉬 엔트리가 상기 클라이언트 캐쉬 엔트리와 동일한 경우, 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 서버 캐쉬 엔트리에 대한 상기 엔트리 연령 데이터를 상기 제 2 애플리케이션으로 송신하는 수단
    을 포함하는 데이타 캐싱 장치.
  9. 제 8 항에 있어서,
    상기 제 2 애플리케이션의 다수의 인스탄스에 걸쳐 클라이언트 캐쉬 엔트리를 보유하는 단계를 더 포함하는 데이타 캐싱 장치.
  10. 제 8 항에 있어서,
    ⑨ 상기 제 2 애플리케이션으로부터의 요구를 질의(interrogate)하여 상기 요구에 대응하는 클라이언트 캐쉬 엔트리가 존재하는지를 판정하는 수단과,
    ⑩ 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 클라이언트 캐쉬 엔트리에 대한 상기 클라이언트 캐쉬 엔트리의 시간 기록을 평가(evaluate)하여, 상기 제 2 애플리케이션이 정보를 요구하기 전에 사전설정된 클라이언트 코히어런시 시간 구간(a predetermined client coherency time interval) 동안 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 클라이언트 캐쉬 엔트리가 생성되었는지를 판정하는 수단과,
    ⑪ 상기 평가 단계에서 상기 제 2 애플리케이션이 정보를 요구하기 전에 사전설정된 클라이언트 코히어런시 시간 구간 동안 상기 제 2 애플리케이션에 대한 클라이언트 캐쉬 엔트리가 생성된 것으로 판정되면, 상기 클라이언트 캐쉬 엔트리를 상기 요구에 응답하여 상기 제 2 애플리케이션에 제공하는 수단
    을 더 포함하는 데이타 캐싱 장치.
  11. 제 8 항에 있어서,
    상기 제 1 애플리케이션이 상기 요구를 수신하기 전에 사전설정된 클라이언트 코히어런시 시간 구간 동안 상기 제 2 애플리케이션으로부터의 요구에 대응하는서버 요구 캐쉬 엔트리가 생성되었는지를 판정하는 수단을 더 포함하되,
    상기 전송 수단은 상기 판정 수단에 의해 상기 사전설정된 클라이언트 코히어런시 시간 구간 동안 상기 서버 요구 캐쉬 엔트리가 생성된 것으로 판정된 경우에 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 서버 요구 캐쉬 엔트리를 전송하는 수단을 포함하는
    데이타 캐싱 장치.
  12. 제 8 항에 있어서,
    상기 제 2 애플리케이션의 현재의 시간에서 상기 제 1 애플리케이션로부터 수신된 상기 엔트리 연령 데이타를 감산하여, 상기 제 2 애플리케이션으로부터의 요구에 대응하는 상기 클라이언트 캐쉬 엔트리 시간 기록을 갱신하는 수단을 더 포함하는
    데이타 캐싱 장치.
  13. 제 8 항에 있어서,
    상기 제 2 애플리케이션은 웹 브라우저이고, 상기 제 1 애플리케이션은 웹서버인 데이타 캐싱 장치.
  14. 제 8 항에 있어서,
    상기 제 1 애플리케이션은 웹 서버이고, 상기 제 2 애플리케이션은 웹 브라우저이고, 상기 제 1 및 제 2 애플리케이션은 무선 통신 링크를 통해 통신하는
    데이타 캐싱 장치.
KR1019970707263A 1996-02-15 1996-07-11 데이타캐싱방법및장치 KR100295003B1 (ko)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US8/601,753 1996-02-15
US08/601753 1996-02-15
US08/601,753 US5878213A (en) 1996-02-15 1996-02-15 Methods, systems and computer program products for the synchronization of time coherent caching system
PCT/US1996/011552 WO1997030403A1 (en) 1996-02-15 1996-07-11 Time coherent caching system

Publications (2)

Publication Number Publication Date
KR19980703863A KR19980703863A (ko) 1998-12-05
KR100295003B1 true KR100295003B1 (ko) 2001-09-07

Family

ID=24408638

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1019970707263A KR100295003B1 (ko) 1996-02-15 1996-07-11 데이타캐싱방법및장치

Country Status (15)

Country Link
US (1) US5878213A (ko)
EP (1) EP0823093B1 (ko)
JP (2) JP3506179B2 (ko)
KR (1) KR100295003B1 (ko)
CN (1) CN1096646C (ko)
AT (1) ATE185008T1 (ko)
CA (1) CA2218155C (ko)
DE (1) DE69604391T2 (ko)
ES (1) ES2137712T3 (ko)
HK (1) HK1009860A1 (ko)
HU (1) HUP9802092A3 (ko)
MY (1) MY120297A (ko)
PL (1) PL182978B1 (ko)
TW (1) TW295760B (ko)
WO (1) WO1997030403A1 (ko)

Families Citing this family (59)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6249795B1 (en) * 1995-10-27 2001-06-19 At&T Corp. Personalizing the display of changes to records in an on-line repository
US5754774A (en) * 1996-02-15 1998-05-19 International Business Machine Corp. Client/server communication system
US5931904A (en) * 1996-10-11 1999-08-03 At&T Corp. Method for reducing the delay between the time a data page is requested and the time the data page is displayed
US5948066A (en) * 1997-03-13 1999-09-07 Motorola, Inc. System and method for delivery of information over narrow-band communications links
BR9811896A (pt) * 1997-08-11 2002-01-02 Thomas C Amon Processo e aparelho para fornecer informação através de uma rede de computadores
US8700734B2 (en) 1997-08-11 2014-04-15 Foley and Lardner LLP Apparatus and method for providing a provider-selected message in response to a user request for user-selected information
US6035324A (en) * 1997-08-28 2000-03-07 International Business Machines Corporation Client-side asynchronous form management
US6070184A (en) * 1997-08-28 2000-05-30 International Business Machines Corporation Server-side asynchronous form management
US6411998B1 (en) * 1997-09-08 2002-06-25 International Business Machines Corporation World wide web internet delay monitor
US6148340A (en) * 1998-04-30 2000-11-14 International Business Machines Corporation Method and system for differencing container files
US6591288B1 (en) 1998-05-19 2003-07-08 Nortel Networks Limited Data network accelerated access system
US6745243B2 (en) * 1998-06-30 2004-06-01 Nortel Networks Limited Method and apparatus for network caching and load balancing
US6757705B1 (en) * 1998-08-14 2004-06-29 Microsoft Corporation Method and system for client-side caching
US6279041B1 (en) * 1998-11-13 2001-08-21 International Business Machines Corporation Methods, systems and computer program products for differencing data communications using a message queue
US6219676B1 (en) 1999-03-29 2001-04-17 Novell, Inc. Methodology for cache coherency of web server data
US6665704B1 (en) * 1999-06-18 2003-12-16 Sun Microsystems, Inc. Bounding delays and reducing threading overheads in caching
US6510458B1 (en) 1999-07-15 2003-01-21 International Business Machines Corporation Blocking saves to web browser cache based on content rating
US6658462B1 (en) 1999-08-26 2003-12-02 International Business Machines Corporation System, method, and program for balancing cache space requirements with retrieval access time for large documents on the internet
US6757717B1 (en) * 1999-09-16 2004-06-29 Proxyconn, Inc. System and method for data access
US6877036B1 (en) * 1999-09-24 2005-04-05 Akamba Corporation System and method for managing connections between a client and a server
US7934251B2 (en) 1999-12-02 2011-04-26 Western Digital Technologies, Inc. Managed peer-to-peer applications, systems and methods for distributed data access and storage
US8793374B2 (en) * 1999-12-02 2014-07-29 Western Digital Technologies, Inc. Managed peer-to-peer applications, systems and methods for distributed data access and storage
EP1309901B1 (en) 1999-12-02 2008-05-21 Western Digital Technologies, Inc. System for remote recording of television programs
US7120692B2 (en) 1999-12-02 2006-10-10 Senvid, Inc. Access and control system for network-enabled devices
US7917628B2 (en) * 1999-12-02 2011-03-29 Western Digital Technologies, Inc. Managed peer-to-peer applications, systems and methods for distributed data access and storage
US9191443B2 (en) * 1999-12-02 2015-11-17 Western Digital Technologies, Inc. Managed peer-to-peer applications, systems and methods for distributed data access and storage
US7587467B2 (en) * 1999-12-02 2009-09-08 Western Digital Technologies, Inc. Managed peer-to-peer applications, systems and methods for distributed data access and storage
US8688797B2 (en) * 1999-12-02 2014-04-01 Western Digital Technologies, Inc. Managed peer-to-peer applications, systems and methods for distributed data access and storage
ATE522036T1 (de) * 2000-01-12 2011-09-15 Jupiter Media Metrix Inc System und verfahren zur schätzung der verbreitung digitalem inhalts im world-wide-web
US6983315B1 (en) * 2000-01-18 2006-01-03 Wrq, Inc. Applet embedded cross-platform caching
US20010032257A1 (en) * 2000-04-12 2001-10-18 Wells Ronald B. Method and system for managing information on a network
WO2001080054A1 (en) * 2000-04-13 2001-10-25 N-Tier Financial Services, Llc Business objects process development framework for data reconciliation
EP1161048A3 (en) * 2000-05-19 2005-02-16 Attachmate Corporation System and method for secure duplex browser communication over disparate networks
US6990526B1 (en) * 2000-05-22 2006-01-24 Pointred Technologies, Inc. Method and apparatus for web caching
US6742033B1 (en) 2000-06-12 2004-05-25 Gateway, Inc. System, method and computer program product that pre-caches content to provide timely information to a user
US20050055426A1 (en) * 2000-06-12 2005-03-10 Kim Smith System, method and computer program product that pre-caches content to provide timely information to a user
JP3879402B2 (ja) * 2000-12-28 2007-02-14 ヤマハ株式会社 歌唱合成方法と装置及び記録媒体
WO2002067541A2 (en) * 2001-01-09 2002-08-29 T-Telematik Venture Beteiligungsgesellschaft Mbh Method and apparatus for coded exchange of information
JP3990115B2 (ja) 2001-03-12 2007-10-10 株式会社東芝 サーバ側プロキシ装置及びプログラム
US6973623B2 (en) * 2001-06-14 2005-12-06 International Business Machines Corporation System and method for client refresh mode selection
US7020684B2 (en) * 2002-01-18 2006-03-28 Bea Systems, Inc. System and method for optimistic caching
US20040139089A1 (en) * 2002-03-29 2004-07-15 Wells Ronald B. Method and system for managing information on a network
US8028077B1 (en) * 2002-07-12 2011-09-27 Apple Inc. Managing distributed computers
US7496607B2 (en) 2003-08-29 2009-02-24 Yahoo! Inc. Method and system for maintaining synchronization between a local data cache and a data store
US7890961B2 (en) * 2003-08-29 2011-02-15 Yahoo! Inc. Method and apparatus for providing desktop application functionality in a client/server architecture
US7395500B2 (en) 2003-08-29 2008-07-01 Yahoo! Inc. Space-optimizing content display
US7441011B2 (en) * 2003-10-23 2008-10-21 Microsoft Corporation Truth on client persistent caching
US20050091226A1 (en) * 2003-10-23 2005-04-28 Yun Lin Persistent caching directory level support
EP1751745B1 (en) * 2003-11-14 2019-07-10 Western Digital Technologies, Inc. Managed peer-to-peer applications, systems and methods for distributed data access and storage
US8010670B2 (en) 2003-12-23 2011-08-30 Slipstream Data Inc. Meta-data based method for local cache utilization
US20060010173A1 (en) * 2004-06-30 2006-01-12 Kilday Roger W Methods and systems for client-side, on-disk caching
US7844961B2 (en) * 2004-12-22 2010-11-30 Sap Ag Automatic field linking
US8677280B2 (en) * 2006-05-18 2014-03-18 Ubiquity Broadcasting Corporation Sprocket shaped user interface for navigating a dynamic collection of information
US9930099B2 (en) * 2007-05-08 2018-03-27 Riverbed Technology, Inc. Hybrid segment-oriented file server and WAN accelerator
US8321557B2 (en) * 2007-10-10 2012-11-27 Sony Mobile Communications Ab Web feeds over SIP
US8190820B2 (en) * 2008-06-13 2012-05-29 Intel Corporation Optimizing concurrent accesses in a directory-based coherency protocol
US10142157B2 (en) 2010-06-10 2018-11-27 Blackberry Limited Method and system for reducing transmission of redundant data
CN102779128A (zh) * 2011-05-10 2012-11-14 北京磊友信息科技有限公司 一种移动终端中的html5应用程序离线运行的方法及设备
JP6088853B2 (ja) * 2013-02-27 2017-03-01 株式会社東芝 通信装置、通信方法および通信プログラム

Also Published As

Publication number Publication date
EP0823093A1 (en) 1998-02-11
EP0823093B1 (en) 1999-09-22
CN1184540A (zh) 1998-06-10
HUP9802092A3 (en) 2002-11-28
CN1096646C (zh) 2002-12-18
ATE185008T1 (de) 1999-10-15
JP2004342069A (ja) 2004-12-02
DE69604391D1 (de) 1999-10-28
JP3506179B2 (ja) 2004-03-15
MY120297A (en) 2005-10-31
KR19980703863A (ko) 1998-12-05
WO1997030403A1 (en) 1997-08-21
CA2218155A1 (en) 1997-08-21
PL322782A1 (en) 1998-02-16
US5878213A (en) 1999-03-02
ES2137712T3 (es) 1999-12-16
TW295760B (en) 1997-01-11
CA2218155C (en) 2004-09-07
JPH11502047A (ja) 1999-02-16
DE69604391T2 (de) 2000-04-20
HK1009860A1 (en) 1999-09-10
JP4608195B2 (ja) 2011-01-05
HUP9802092A2 (hu) 1998-12-28
PL182978B1 (pl) 2002-05-31

Similar Documents

Publication Publication Date Title
KR100295003B1 (ko) 데이타캐싱방법및장치
KR100289520B1 (ko) 웹브라우저애플리케이션의성능향상방법및장치,클라이언트/서버시스템의성능향상방법및장치
KR100289521B1 (ko) 통신링크를통해전송되는데이타를감소시키는방법및장치
KR100295730B1 (ko) 통신링크를통해전송되는데이타의감소방법및장치
CZ287679B6 (cs) Způsob zachycování dat přijatých od druhé aplikace, zařízení a počítačový programový produkt k jeho provádění

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20100405

Year of fee payment: 10

LAPS Lapse due to unpaid annual fee