CZ354097A3 - Způsob redukce dat, zařízení a počítačový programový produkt k jeho provádění - Google Patents
Způsob redukce dat, zařízení a počítačový programový produkt k jeho provádění Download PDFInfo
- Publication number
- CZ354097A3 CZ354097A3 CZ973540A CZ354097A CZ354097A3 CZ 354097 A3 CZ354097 A3 CZ 354097A3 CZ 973540 A CZ973540 A CZ 973540A CZ 354097 A CZ354097 A CZ 354097A CZ 354097 A3 CZ354097 A3 CZ 354097A3
- Authority
- CZ
- Czechia
- Prior art keywords
- server
- application
- response
- client
- data
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/957—Browsing optimisation, e.g. caching or content distillation
- G06F16/9574—Browsing optimisation, e.g. caching or content distillation of access to content, e.g. by caching
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/2876—Pairs of inter-processing entities at each side of the network, e.g. split proxies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/565—Conversion or adaptation of application format or content
- H04L67/5651—Reducing the amount or size of exchanged application data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/142—Managing session states for stateless protocols; Signalling session states; State transitions; Keeping-state mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
- H04L67/5682—Policies or rules for updating, deleting or replacing the stored data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Computer Security & Cryptography (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
- Synchronisation In Digital Transmission Systems (AREA)
- Optical Communication System (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Stored Programmes (AREA)
Description
pv -36W-W ♦· ···· . . . .··. .: ··· ·· + ···· • · « # # « · · · · · · · ··· # · · · · · ·« * #φ ··· ·· ·· Z η Λ s o b redukce dat. zařízení k jeho p r· o v á : i ě n í Op 1 a st t. ech n i k v ά ρ ο c ί t a čový ο r ο t> r a. m o v ý P r o d 11 k t V v η á I < · x s e t v k á z p ú s o b u , z a říze n í a počítačového pro? r a ni o v é h o produktu pro redukci dat při. komunikaci mezi ap.l ikacemi re7. ide n i.n í m i na různých poč í tací ch , .jako .jsou web browser a wcb s c r v n r . K o n k r é t ti ě s e v v η ά 1 e z týká způsobu d i f e r e n c ován í komunikace nře,s externí komunikační spoj mezi dvěma počítači.
Dosa vadn í ...stav techn i kv N o i i á v η á o u b .1 i o i. i, a a n ii r a z n a " i nf ormační super d á 1 n i c i " mě 1 y za následek zvýšení povědomí o Internetu a jeho přijetí jako m a s o v e li o k o m u n i. k a č n í. h o m é d i a . Toto široce založené poznání ®'1 £ n o;: t í 1 n t. e r n e t u j a k o ž i v o t a s c hopného média pro komun i k a c i a .i. nt onako i mezi mnoha různými sítěmi rovněž vytvořilo rozsáhlou u z i. v a 1: e i s k o u b á z :i v y h u d ován o u n a i nter n etov ý ch s t a n d a r d i z a č n í c h pro I. o kol ecn pro interakci mezi počítačovými sítěmi , - ^ P ' c k<:' P r o I r 11 e r n e í j e to, že .i e z d e v z t a h t y p u k I. ien t-server , kde internetový klient (browser) komunikuje 1 111 !: r n (í t o v v m s <» r v e rem . V z á j m u d o sazení .1 epší ho p ř í s t u p u n a i " i. e r ri c ( . d«ou postupně komunikační protokoly a jazyky používané k 1 · '· n ř· V a s e r v e r y s t a n d a v d i z o v A n v . Tyto protok o i y z a h r n u j í 1 !l v!'Ci--'iext. Transfer Protocol (HTTP), který .je komunikačním ni o i, ok o.lem používaným nro komunikaci mezi klienty a servery, '' '1 ‘ * 1 ‘: ' '·’a ! 1!'! 1 e r 0on i r o 1 P r o t oco 1 / I n t e r n e t Pr o t oco 1 (TCP/1P ) , kd e e < i s !. n r o t; o k o I n 'f C P n ř e d s t a v u .j e μ ř e n osově spe c i f ický proto k o ]. p r o K °11,1,11 1 hac i m o z i. 11 o č i t. a č i n e b o a p 1 i k a cemi . Stand a rdi zova n ý .i e 1 °1 n * •i0·55 y k » v k i, e r é m k i i e n í i a ser v e r y v z á jemně ko m u n i k u i í a který '·· nazvvá lly por-Text Markuo Laneuage (HTML). Protože jsou ° ' ° 1 'l 11 ! i t t o r m a c í. n r o t o k o i. vě nezávislé a protože používají 3 min i m a 1 i. z a c í p r o p o j e n í - 2 ·· ···· ·· · Μ ·· * · · ·»·· ···· • · · · · · ···· '» · · I · · · · ···· · • · · ··· · · · *· · ·· ··· ·· ·· a nejlepším výkonem, je každá transakce plně samostatná. To znamená, například, že každé hlášení od klienta obsahuje informace o schopnostech browseru (prohlížeče) a je nezávislé z pohledu komunikace, která má být dokončena, na jakýchkoliv dalších komunikacích. Tato samostatnost komunikace mezi klientem a serverem může být označovaná za "nestavovou" komunikaci, která zvyšuje u dané komunikace množství dat, jež musí být přenášeno mezi klientem a serverem. V kontextu World Wide Web aplikací typu klient/server může býl klientem web browser, který vytváří uživatelské rozhraní. Tento web browser odesílá požadavky uživatele na příslušný web server a formátuje a zobrazuje data HTML vracená z web serveru. Web browser rovněž vyhodnocuje tato data HTML s cílem určit, zda se zde nachází mnoho vložených hyper-link příkazů, které by vyžadovaly následné požadavky browseru, jež by pak byly browserem iniciovány. Web server pracuje jako server pro klienta a zpracovává požadavky web browserů a odpovídá jim na požadavky ve formě části dat HTML v datovém toku HTTP. Příkladem typické komunikace world wide web je případ, kdy web browser iniciuje požadavek na "home page" (domovskou stránku) z web serveru, neboř to ilustruje základní vztah mezi HTTP, HTML, TCP a web browserem a serverem. Když uživatel web browseru požaduje informace ze specifického místa web, iniciuje web browser komunikaci s web serverem odesláním požadavku typu "získat" na web server se specifikací Universal Resource Locator (URL) požadovaného místa web, např. na již zmíněnou domovskou stránku. URL přestavuje adresu místa web a je jedinečný v celé síti Internet. Web server potom získá a pošle web browseru data HTML odpovídající domovské stránce specifikované URL. Tato operace může zahrnovat další komunikace na Internetu ze strany web serveru Internetu, anebo URL může specifikovat server v lokální síti, k němuž je browser připojen. Web browser potom vyhodnotí přijatá data HTML jako datový tok HTTP od web serveru, 3
·· ·· • · · · • · ·· ·· • · aby z j i í-; 1 i 1 , zda se zde nevyskytují vložené spoje typu hyper-link, jako jsou ikony a obrázky, a pokud se vyskytují, iniciuje požadavky specifikující pro URL hyper-link, jak získat potřebná data. Takto obdržená data jsou pak začleněna do domovské stránky a zobrazena uživateli. Jak je z tohoto přikladu zřejmé, jednoduchý uživatelský vstupní požadavek od web browseru může mít za následek mnohonásobné dodatečné požadavky, které provádí web browser automaticky v reakci na přijatá data HTML odpovídající vstupnímu požadavku uživatele.
Popularita web browseru/web serveru a jejich společných informačních a přenosových protokolů, HTML a HTTP, vedla k rychlému při j etí technologie web jako univerzálního stykového rozhraní pro přístup k informacím na síti. Dále v důsledku standardizace protokolů a jazyka pro komunikaci mezi web browsery a web servery budou komunikační protokoly a jazyk stejné nezávisle na tom, zda uživatel pracuje s programem Netscape Navigátor, NCSA Mosaic, WebExplorer nebo jakýmkoli jiným web browserem, který mu umožňuje přístup k sítovým informacím. To znamená, že velká instalovaná uživatelská báze pro web browsery zkombinovaná s připojením na Internet a snadnost zapisování na aplikační web servery pomocí definovaného HTTP rozhraní Common Gateway Interface (CG I ) vytváří. z technologie web velmi atraktivní prostředek pro velkou třídu aplikací založených na formulářích. V době, kdy rostla popularita Internetu a rozšiřovala se jeho dostupnost, rostla rovněž i popularita mobilního výpočetnictví. Používání laptopů, notebooků, prostředků Personál Dj. g i tal/Commun i cat i on Assistants (PDA/PCA) a dalších přenosných zařízení vedlo ke zvýšení požadavků na bezdrátovou komunikaci. Dálkové bezdrátové komunikační sítě, celulární komunikace a paketové radiospojení však trpí společnými omezeními v situacích, kdy se používají v kontextu web. Vysoké náklady na komunikaci při přepočtení na jeden byte, pomalá časová odezva, ·· 4444
♦ · ♦♦ · · · i ♦ · · · 4 44 4 4 4 4 4 4 · 4 4 · ♦ · 4 4 4 # ·» 444 4# ·# malá šířka pásma a nespolehlivost - to vše brání použití bezdrátové technologie pro nestavový komunikační protokol World Wide Web. Protože je protokol web nestavový, je i množství dat na jeden požadavek a také počet požadavků přenášených po bezdrátových spojeních větší, než by to bylo nezbytné, kdyby • komunikace nebyla samostatná. Takže kombinace bezdrátové technologie nebo jiné pomalé komunikační technologie * s technologií web se zdá být nepraktická, protože síla technologie web je v její univerzální povaze, a ta obnažuje slabosti bezdrátové technologie.
Podstata vynálezu
Ve světle výše uvedených omezení je jedním z cílů s vynálezu vytvořit komunikační systém, který redukuje objem dat, jenž má být přenášen mezi aplikacemi.
Dalším cílem vynálezu je vytvořit komunikační systém, který může být použit v prostředí web browser/server. M e z i. další cíle vynálezu také patří kompat i b i lita s existujícími komunikačními protokoly a jazyky u pomalých nebo bezdrátových komunikačních systémů, bez nutnosti úpravy ap1 ikací weli browser nebo web server. * <» K da 1 š í.m cílům vynálezu patří vytvořit komunikační systém, který redukuje objem nezbytné komunikace mezi web browserem a web serverem, a tedy zvýšení výkonnosti komunikačního systému. Z pohledu těchto a dalších cílů vynález vytváří způsob redukce dat, přenášených přes komunikační spoj z první aplikace rezidentní, na prvním počítači na druhou aplikaci rezidentní na druhém počítači, přičemž tato data jsou přenášena přes externí komunikační spoj od prvního počítače na druhý počítač.
• · · · · · • · · ·· Μ • · · · • · Μ • ·
Jedno provedení vynálezu obsahuje uložení datového toku z první aplikace, který má být poskytnut druhé aplikaci v odpovědi na požadavek od druhé aplikace, do cache paměti rezidentní na druhém počítači tak, aby se vytvořil serverový bázový cache zápis. Datový tok, který má být poskytnut druhé aplikaci v odpovědi na požadavek od druhé aplikace, je také uložen do cache paměti rezidentní na druhém počítači tak, aby se vytvořil klientův bázový cache zápis. Požadavky od druhé aplikace se vyhodnotí s cílem stanovit, zda existuje klientův bázový cache zápis, odpovídající zachycenému požadavku, pro poskytnutí klientovy bázové formy. Požadavky od druhé aplikace se rovněž zachytí, přičemž se stanoví, zda existuje pro poskytnutí serverové bázové formy serverový bázový cache zápis, odpovídající zachycenému požadavku. Datový tok, odpovídající odpovědi, vytvořené první aplikací, v odpovědi na zachycený požadavek od druhé aplikace, se zachytí před přenosem odpovědi po externím komunikačním spoji a porovná se serverovou bázovou Formou tak, aby se poskytla rozdílová data, odpovídající rozdílu mezi zachycenou odpovědí a serverovou bázovou formou. Rozdílová data jsou odeslána na druhý počítač přes externí komunikační spoj a tato rozdílová data, přenášená prvním počítačem přes externí komunikační spoj, se z tohoto externího komunikačního spoje pak získají. Datový tok odpovědi, odpovídající komunikaci od prvního počítače, se rekonstruuje ze specifického datového toku klient/server, přijatého přes externí komunikační spoj sloučením klientovy bázové formy s rozdílovými daty, přijatými přes externí komunikační spoj tak, že se vytvoří datový tok odpovědi, odpovídající zachycené odpovědi. Rekonstruovaný datový tok, odpovídající zachycené odpovědi, se poskytne druhé aplikaci. V dalším provedení vynálezu druhý počítač stanoví, zda je serverová bázová forma identická klientově bázové formě, a tato i serverová bázová forma a rozdílová data se přenesou na druhý počítač přes externí komunikační spoj v případě, že uvedená bázová forma není identická klientově bázové formě. Zachycený - 6 44 ♦··· 44 4 4 4 4 4 • 4 4 4 4 • 4 · 4 4 4 • · ♦ 4 4 t* 4 44 * ·♦ ·· 44 4 4· « • 4 4 4 4 • 4 4444 4 • · 4 4 4 4 4 4 4 4 4 datový tok odpovědi, odpovídající odpovědi z první aplikace, se potom rekonstruuje sloučením serverové bázové formy přijaté přes externí komunikační spoj s rozdílovými daty přijatými přes externí komunikační spoj tak, že se vytvoří datový tok, odpovídající zachycené odpovědi. Klientova bázová forma, odpovídající zachycenému požadavku, se rovněž aktualizuje, a to uložením přijaté serverové bázové formy jako klientova bázového cache zápisu, odpovídajícího zachycenému požadavku. Z hlediska obnovy serveru u stávajícího vynálezu první počítač určuje, zda rozdíl mezi serverovou bázovou formou a zachycenou odpovědí je větší než předem definovaný rozdílový práh. Serverová bázová forma, odpovídající zachycenému požadavku, je aktualizována uložením zachyceného datového toku odpovědi, přijatého z první aplikace jako s e r v e r o v é h o bázového cache zápisu, odpovídajícího zachycenému požadavku, v případě, že roždí] mezi serverovou bázovou formou a zachycenou odpovědí je větší než předem definovaný rozdílový práh. Při porovnání se pak využívá aktualizovaná serverová bázová forma. V alternativním provedení vynálezu je udržována pluralita serverových bázových cache zápisů, které odpovídají požadavku od druhé aplikace. Požadavek od druhé aplikace je zachycen s cílem stanovit, zda existuje pluralita serverových bázových cache zápisů, odpovídající požadavku od druhé aplikace tak, aby se poskytla pluralita serverových bázový forem. První počítač stanoví, zda je jedna z plurality serverových bázových forem identická klientově bázové formě, a tuto pluralitu serverových bázových forem využívá v případě, že je jedna z plurality serverových bázových forem identická klientově bázové formě.
Další provedení vynálezu zahrnuje aktualizaci serverového cache zápisu datovým tokem od první aplikace v odpovědi na požadavek od druhé aplikace. Pluralita rozdílových datových sad, které odpovídají požadavku od druhé aplikace a které představují - 7 ·» ···« »· ♦ · # · ·
• ♦ · · I • · * · · « • · * t · f · · · * • M · # • · · · · · • « · · · • · IM · · • · · ♦
• · · · · M rozdíly mezi následnými serverovými cache zápisy, se udržuje za účelem poskytnout archivační rozdílová data. Udržuje se rovněž pluralita CRC zápisu, přičemž každý z této plurality CRC zápisu se přiřadí jedné pluralitě rozdílových datových sad, která jednoznačně identifikuje serverovou bázovou formu, z níž se rozdělila sada rozdílových dat. Jestliže existuje pluralita sad rozdílových dat a více CRC, odpovídajících požadavku od druhé aplikace, a jestliže jedna z této plurality CRC odpovídá serverové bázové formě, která je identická klientově bázové formě, přičemž archivační rozdílová data odpovídají CRC, jenž odpovídá klientově bázové formě, potom se následné sady rozdílových dat a rozdílová data, vypočtená z aktuální serverové bázové formy, a odpověď od první aplikace odesílají na druhý počítač přes externí komunikační spoj. Datový tok odpovědi, odpovídající komunikaci od první aplikace, se následně rekonstruuje z datového toku přijatého přes externí komunikační spoj, a to sloučením klientovy bázové formy s rozdílovými daty přijatými, přes externí komunikační spoj tak, že se vytvoří datový tok odpovědi, odpovídající zachycené odpovědi. Klientův cache zápis, odpovídající požadavku od druhé aplikace, se rovněž aktualizuje rekonstruovaným datovým tokem. V alternativním provedení vynálezu první aplikace zahrnuje web server a druhá aplikace web browser. Podobně externí komunikační spoj zahrnuje bezdrátový komunikační spoj. V alternativním začlenění dále zahrnuje požadavek od web browseru, obsahující požadavek CGI. Výše popsaná provedení vynálezu mohou být podle potřeb poskytnuta rovněž i v jiné formě, např. jako počítačový program {t j. soubor, který lze číst na počítači). Přehled obrázku na výkresech
Vynález je dále podrobněji popsán s pomocí výkresů, na nichž - 8 ·· ···· ·· · ·· ·· ♦ ♦ · · · · · · «» » • « · * · · ···· • · · · * · · · ···· · • · · ♦ · ♦ ··· ·· * · · ··♦ ·« ·· jsou znázorněna přednostní provedení vynálezu. Tento vynález však může být proveden v mnoha různých podobách a jeho konstrukce není omezena jako zde uváděnými provedeními. Tato provedení jsou uváděna s úplným a kompletním popisem. Na výkresech znázorňuje: obr. 1 blokový diagram typického systému web browser/web server, obr. 2 blokový diagram systému web browser/ web server podle provedení vynálezu, využívajícího zachycení klienta a zachycení serveru, obr. 3 vývojový diagram znázorňující operace, prováděné zachycovacím modulem na straně klienta v přednostním provedení podle vynálezu pro implementaci koherentního vyrovnávacího systému cache , obr. 4 vývojový diagram, znázorňující operace prováděné zachycovacím modulem na straně klienta v přednostním provedení podle vynálezu, implementujícím koherentní vyrovnávací systém cache, obr. 5 vývojový diagram, znázorňující operace prováděné zachycovacím modulem na straně serveru v přednostním provedení podle vynálezu, implementujícím koherentní vyrovnávací systém cache, obr. 6 vývojový diagram, znázorňující operace prováděné zachycovacím modulem na straně serveru v přednostním provedení podle vynálezu, implementujícím koherentní vyrovnávací systém cache, obr. 7 vývojový diagram znázorňující, operace prováděné zachycovacím modulem na straně klienta v přednostním provedení podle vynálezu, implementujícím přenosový systém rozdílových dat, obr , obr . obr . obr. obr. obr. o b r . obr . • · ♦ ··· #♦ • ·· ·· ♦ * • « · «« • · • · • * • • · • ♦ · • « • · « « • ♦ • • ·· · • · • · • « · • • • ♦ ♦ · • • · • · · • · « · (I í' | ^ o vývojový diagram, znázorňující operace prováděné zachycováním modulem na straně klienta v přednostním provedení podle vynálezu, implementujícím přenosový systém rozdílových dat, 9 vývojový diagram, znázorňující operace prováděné zachynovacím modulem na straně serveru v přednostním provedení podle vynálezu, implementujícím přenosový systém rozdílových d a t, 10 a, b vývojový diagram, znázorňující operace prováděné zaehycovacím modulem na straně serveru v přednos t ním provedení podle vynálezu, implementujícím přenosový systém rozdílových dat, 11 blokový diagram provedení vynálezu, využívajícího virtuální sokety, 12 blokový diagram zachycovacího modulu na straně klienta a zachycovacího modulu na straně serveru v provedení podle vynálezu, využívajícím virtuální sokety, 13 vývojový diagram, popisující operace, prováděné manažerem soketů u zachycovacího modulu na straně klienta, anebo zachycovacího modulu na straně serveru v provedení podle v y n á1e z u, využívajícím virtuální sokety,14 vývojový diagram, popisující operace, prováděné zachycovací funkcí na straně klienta v provedení podle vynálezu, využívajícím virtuální sokety,15 vývojový diagram, popisující operace, prováděné zachycovac í funkcí na straně serveru v provedení podle vynálezu, využívajícím virtuální sokety, ·· ···♦ 09 ·· ·· - 10 * · 0 φ m 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 0 00 # «·· • · t · • · ·· 00 0 0 0 0 0 0 00 00 obr . 16-1 vývojový diagram, popisující v i r t u á1 ní operaci v y t v á ř e n í v provedení podle vynálezu, využí vaj í c ím virtuální sokety, obr. 16-2 vývojový diagram, popisující v i r t u á1 ní operac i odesílání v provedení podle vynálezu, využívajícím vir t u á1n í sokety, obr . 16-3 vývojový diagram, popisující virtuální operaci příjmu v provedení podle vynálezu, využívajícím virtuální soke 1,y , obr. 16-4 vývojový diagram, popisující virtuální operaci výběru v provedení podle vynálezu, využívajícím virtuální s o k e t y , obr. 17-1 vývojový diagram, popisující virtuální operaci vyrovnání v provedení podle vynálezu, využívajícím virtuální sokety, obr. 17-2 vývojový diagram, popisující. virtuální operaci zavření v provedení podle vynálezu, využívajícím virtuální sokety. Př.í klady provedení vynálezu Základní komunikační struktura pro systém založený na síti Internet je znázorněna na obr. 1. Na obr. 1 komunikuje web browser .JL_0 s web serverem 20 po komunikačním spoji 1J>. Tento komunikační spoj _15_ je obvykle spoj LAN, WAN s využitím telefonních linek nebo kombinace propojovacích metod. Web browser 10 komunikuje s web serverem 20 pomocí TCP/IP. Většina komunikací po Internetu je taková, že web browser JJ3 komunikuje s web serverem _2_0_ prostřednictvím generického komunikačního protokolu· HTTP, který je přenášen mezi web browserem 1.0 a web serverem 2_0 - 11 - 11 ·· ·· ··♦♦ • · ♦ • · · • · · « « · · ·· ·
♦ ·♦ ·· ·· • » · ψ 4 · ·· ♦ ·· ♦ · * · · ·* «« po spoji TCP/IP, vytvořeném mezi web browserem 1_0. a web serverem 20.· Skutečná data přenášená mezi web browserem 10 a web serverem 20. jsou tvořena objekty HTTP ( např. data HTML), jak bylo výše popsáno. Web server 20 může být i zprostředkovatelem, který přijímá web browserové komunikace od více web browserů 1,0 a směrovačů-routerů a předává je na příslušný server 20.
Obr. 3 až 10 a 13 až 17-2 jsou vývojové diagramy metod a systémů podle vynálezu. Je jasné, že každý blok vývojových diagramů a také kombinace těchto bloků mohou být implementovány pomocí instrukcí počítačového programu. Tyto instrukce počítačového programu mohou být zaváděny na počítač nebo mohou být tvořeny jinými programovatelnými zařízeními s cílem zhotovit stroj tak, aby Instrukce, které bude počítač nebo jiné programovatelné zařízení provádět, vytvořily prostředky pro implementování funkcí specifikovaných v bloku nebo v blocích vývojového diagramu. Tyto počítačové programové instrukce mohou být uloženy v počítačem čitelné paměti, která může řídit, počítač nebo jiné programovatelné zařízení, aby pracovalo určitým způsobem, tak jak instrukce uložené v počítačem čitelné paměti vytvářejí výrobní článek včetně instrukčních prostředků, které implementují funkci specifikovanou v bloku nebo v blocích vývojového diagramu. Počítačové programové instrukce mohou být rovněž zaváděny do počítače nebo jiného programovatelného zařízení tak, že způsobí řadu funkčních kroků prováděných na počítači nebo jiném programovatelném zařízení s cílem vytvořit počítačem implementovaný proces, tak jako instrukce, které prová.dějí na počítači nebo jiném programovatelném zařízení kroky pro implementaci funkcí specifikovaných v bloku nebo v blocích vývojového diagramu.
Podobně bloky vývojových diagramů podporují kombinace prostředků i kroků pro provádění specifických funkcí. Každý blok na ilustraci vývojového diagramu, popřípadě kombinace bloků, může být implementován speciálním jednoúčelovým hardwarově založeným - 12 - 12 «· ··«· « · Φ * · · • · · I · · ·· t ♦ · · ·· ·· • · ·· · · » Φ • · · i I ΦΦ • t φ φ ···· φ • · · φ φ φ ·· φφφ ΦΦ ΦΦ počítačovým systémem, který provádí specifikované funkce nebo kroky, anebo kombinací speciálního účelového hardware a počítačových instrukcí.
Obr. 2 ilustruje jedno provedení vynálezu. Jak je zřejmé z obr. 2, web browser i_0 komunikuje se zachycovacím modulem _3_0 na straně klienta. Web server 20 komunikuje se zachycovacím modulem 40 na serverové straně. Zachycovaní modul 3_0 na klientově straně pak komunikuje se zachycovacím modulem 40. na straně serveru přes externí komunikační spoj 3_5. Web browser Π) a zachycovaní modul 3_0 na klientově straně se mohou nacházet v prvním počítači .5. Zachy novací modul 4_0 na serverové straně a web server 2J) se mohou nacházet ve druhém počítači 6. První počítač 5 a druhý počítač 6. spolu komunikují přes externí komunikační spoj 35. Přednostně je web browser 10 internetový web browser využívající hypertext transfer protocol (HTTP) a hypertext markup language (HTML) pro komunikaci s internetovým web serverem 20, který rovněž používá HTTP a HTML. V provozu dává web browser 10. na výstupu datový tok HTTP, který je zachycován modulem .30 na straně klienta. Zachycení datového toku HTTP zachycovacím modulem 30 na straně klienta může být prováděno použitím funkce zpětnovazební smyčky TCP/IP, kde zachycovací modul 30. na straně klienta je rezidentní na adrese IP a má síťové číslo 127, např. 127.0.0.1. Zachycovací modul 3j) na straně klienta potom konvertuje nebo transformuje datový tok HTTP do specifického protokolu klient/server a odešle specifický datový tok kl i ent/server na externí, komunikační spoj 3_5. Zachycovací modul 40 na straně serveru přijme specifický datový tok a rekonstruuje původní. datový tok HTTP odpovídající komunikaci vytvářené web browserem 10.. Tento rekonstruovaný datový tok HTTP je potom odeslán na web server 20. Web server 20 odpoví na datový tok HTTP obvyklým způsobem pro internetový web server 20., Z pohledu hodnocení vynálezu je nutné říci, že web server 2j) může být rovněž nahrazen tak, aby bylo dosaženo připojení na Internet pro 13 13 ·· • · · • · · ♦ · · • · · ♦ · ·
• ···· · • · · ·+ ♦· ·· #♦♦♦ ♦ « · více browserů 1_0 .
Jakmile je přijata web serverem 20 informace pro odeslání na web browser 1.0, například jako odpověď na požadavek browserů 1_0 pro specifickou domovskou stránku URL, odešle web server 20 výstupní datový tok HTTP odpovídající komunikaci, která má být odeslána na web browser 1,0. Tato komunikace vytvářená web .serverem .20 je zachycena zachycovacím modulem 40 na straně serveru a transformována na specifický datový tok lcl i ent/server. Tento specifický datový tok klient/server odpovídající komunikaci vytvářeně web serverem 20 je potom odeslán druhým počítačem 6 přes externí komunikační spoj 3_5 do prvního počítače 5_. Specifický datový tok klient/server je přijat zachycovacím modulem _30 na straně klienta, který rekonstruuje původní datový tok HTTP, odpovídající komunikaci vytvářené web serverem 20 a poskytne jej web browserů 10. V konkrétním zapojení podle vynálezu je externí komunikační spoj 3.5 bezdrátovým komunikačním spojem. V takovém případě, aby bylo dosaženo systémové výkonnosti přijatelné pro uživatele, je zapotřebí snížit objem komunikace přes externí komunikační spoj 35, a to jak co do četnosti komunikace, tak do objemu informací, k t e r 6 musí být přenášeny přes komunikační s p o j 35.. Podobně vynález využívá techniky vyrovnávání, vytváření, rozdílů a redukce protokolů s cílem minimalizovat potřebný objem komunikace přes externí komunikační spoj 35. Tyto techniky jsou prováděny konvertováním nestavových nebo stochastických protokolů HTTP na specifický protokol klient/server, který využívá informace spec if ické pro klienta a pro server tak, aby minimalizoval objem a četnost komun:i.kace .
Zatímco stávající vynález je a bude popisován s ohledem na jednu aplikaci web browser Π) a jednu aplikaci web server .20 je nutné předeslat pro hodnocení tohoto vynálezu, že přednosti a výhody tohoto vynálezu mohou být rovněž dosahovány násobnými 14 ♦· ··«· ♦ · · ♦ · · ♦ · · • « · ♦ · ♦ ♦ * ·
web browsery .10 přiřazenými jednomu web serveru 20.. Vynález se bědy vztahuje i na metody, zařízení a programové produkty ve spojení s násobnými browsery, kde každý z nich komunikuje pomocí zachycovacího modulu na straně klienta a kde tyto zachycovací moduly na straně klienta komunikují se zachycovacím modulem na straně serveru u web serveru nebo jiného obdobného web zařízení. V jednom provedení vynálezu se jak u zachycovacího modulu 30. na straně klienta, tak u zachycovacího modulu 4J) na straně serveru využívá možnosti ukládání do vyrovnávací paměti. Klientova vyrovnávací cache paměť se nachází na prvním počítači 5. a ukládá datové toky HTTP, které mají být přijaty web browserem 1.0 v odpovědi na komunikaci vytvářenou web browserem 20 . Serverová vyrovnávací cache paměť je rezidentní na druhém počítači 6 a ukládá datové toky HTTP, které jsou přijaty z web serveru 20_ v odpovědi na komunikaci vytvářenou browserem 10. Z pohledu hodnocení tohoto vynálezu cache paměť rezidentní na prvním počítači 5. nebo na druhém počítači 6 může být libovolné velikosti a libovolného specifického hardware či konfigurace počítače. Tyto vyrovnávací cache paměti uchovávají informace pro j e d n o 11 ivé komunikace včetně URL komunikace, jednoznačného identifikátoru založeného na komunikacích obsahujícího například cyklickou kontrolu redundance (CRC), dat komunikace, data a času uložení (S D T) indikujících dobu, kdy byl vytvořen nebo obnoven cache zápis, a komunikačních dat. Pro každou komunikaci ukládanou do paměti cache může být tedy vytvořen adresář cache zápisů. Dále může být Libovolný, v důsledku omezených zdrojů dostupných pro danou hardwarovou konfiguraci, počet technik ukládání do vyrovnávací paměti a rovněž udržování rezidentních cache pamětí na prvním i na druhém počítači 5.,6.. Na to vše se vztahuje tento vynález. To znamená, že například cache paměť může zrušit platnost nejstaršího adresáře zápisů v případě, že uživatelem definovaná cache velikost je překročená v důsledku přidání nového zápisu. Cache zápisy mohou být dále udržovány prostřednictvím - 15 ·· ···· ♦ · · • · · • · · · • · · ·· · ♦ · • · ♦ * • · • · ·· ·· • · · • ♦ ·♦· · • · ·· ·· ·· ·· násobηých entit aplikací web browseru JjO nebo web serveru 2.0 nebo dokonce cyklů spouštěných po zapnutí na prvním nebo na druhém počítači 5,, 6. pro vytvoření stálé cache paměti. Činnost struktury vyrovnávání bude podle jednoho provedení vynálezu popsána s odvoláním na obr. 3 až 6, což jsou vývojové diagramy popisující činnost zachycovacího modulu 3J1 na straně klienta a zacliycovacího modulu 4.0 na straně serveru. Konkrétně u obr. 3, blok .1,00 označuje, že zachycovací modul 3j) na straně k1 ienta přijal požadavek od web browseru U). Tento požadavek může být ve formě datového toku HTTP. Zachycovací modul 30. na. straně k 1 i enta kontroluje Un i f orm Resource Loc:ator (URL) příchozího požadavku, jak je znázorněno v druhém bloku 105. Zachycovací modul 30. na straně klienta určí z URL, jestli byla informace, odpovídající. požadavku, vytvořeného web browserem 10. dříve uložená v klientově cache, rezidentní v prvním počítači 5.·
Jestliže informace odpovídající URL nebyla předtím uložená v klientově cache paměti, potom se uskuteční zachycovacím modulem 30 na straně klienta činnosti znázorněné v třetím bloku 106. Zachycovací modul 30 na straně klienta odešle požadavek přes externí komunikační spoj 35 na zachycovací modul 4_0 na straně serve r u.
Jestliže však po prozkoumání komunikace vytvořené web browserem 10., jak je znázorněno ve druhém bloku 105. se zjistí, že existuje zápis klientovy cache, který odpovídá komunikaci vytvořené web browserem _10., potom v nejjednodušším provedení bude tato informace poskytnuta web browseru 1_0 jako datový tok HTTP. Avšak, jak je znázorněno na obr. 3, provádí přednostní provedení podlt; vynálezu to, co je označováno jako koherentní intervalová kontrola na cache. zápisu odpovídající komunikaci vytvořené web browserem 10. Tato operace je znázorněna ve čtvrtém bloku 110 na obr. 3 . 16 16
• φ φ · • φ φ · ·· · φ · • φ #
Koherentní interval pro zachycovací modul 3J) na straně klienta může být uživatelem definovaný a je dán časovou délkou, po kterou může existovat cache zápis předtím, než se stane zastaralým, a musí být obnoven položením dotazu na informaci odpovídající komunikaci vytvořené web browser em 1_0 , a to web serveru 20. Koherentní intervalová kontrola, znázorněné ve čtvrtém bloku J10, může být prováděna porovnáním aktuálního data a času se sumou SDT cache zápisu, odpovídající komunikaci vytvořené w e b browserem 1_0 a koherentnímu intervalu specifikovanému uživatelem. Jestliže aktuální datum a čas je větší než tato suma, potom bude informace uložená v cache paměti odpovídající komunikaci vytvářené web browserem 10. zastaralá a uplatní se větev "No" bloku 110. Jestliže však aktuální datum a čas je. menší než suma SDT plus uživatelem definovaný koherentní interval, potom platí větev "Yes" bloku 110 a jak je dále znázorněno v pátém bloku 111, je cache zápis předán browseru 10 jako datový tok HTTP. Komunikace vytvářená browserem 1_0 bude potom přijata zachycovacím modulem 30 na straně klienta v bloku .100, viz. obr. 3.
Jestliže kontrola koherentního intervalu znázorněná ve čtvrtém bloku 110 určí, že cache zápis, rezidentní na prvním počítači. 5, je zastaralý, vygeneruje požadavek na zachycovací modul 4J) na straně serveru, aby zkontroloval koherentnost cache zápisu rezidentního na druhém počítači 6.. Tato operace je znázorněna pomocí šestého bloku 112 na obr. 3. Je prováděna pomocí externího komunikačního spoje 3J5 použitého k předání koherentní ho intervalu na zachycovací modul 4J3 na straně serveru pro konkrétní zachycovací modul 30. na straně klienta, který odpovídá web browseru 1_0, jenž vytvořil dotaz, a dále je předána jednoznačná indicie o obsahu klientovy cache, odpovídající. URL komunikaci vytvářené web browserem 1J3. V přednostním provedení je tato jednoznačná indicie výsledkem cyklické redundanční kontroly nebo CRC pro daný cache zápis. - 17 • · • · ···· ·« • · ·« • ·· Μ ·· · · · · • · · ·· • · · · t · · • · · · Μ· ·· ·· Věnujme nyní pozornost obr. 5, který znázorňuje činnost zachycovaní ho modulu 4_0 na straně serveru v odpovědi na informaci přijatou přes externí komunikační spoj íy> od zachycovacího modulu 10 na straně klienta. Když zachycovací modul 40. na straně serveru Přijme požadavek od zachycovac í ho modulu 3J3 na straně k 1 i enta , z ac h y c o v a c í modu 1. 40 na straně serveru přijme předem definovaný klientův koherentní, časový interval, CRC hodnotu pro klientův cache zápis a HTTP dotaz, vytvořený web browserem 1_0. Potvrzení této informace je znázorněno v sedmém bloku 120 na obr. 5.
Po př i jetí informace od zachycovac í ho modulu 30. na straně klienta zkontroluje zachycovací modul 40. na straně serveru svou serverovou cache rezidentní na druhém počítači .6 , aby určil, zda existuje serverový cache zápis odpovídající URL požadavku HTTP vytvořeného web browserem 1.0. Jestliže po prozkoumání komunikace vytvořené web browserem .10., jak je naznačeno v osmém bloku 12 5, určí zachycovací modul 40 na straně serveru, že existuje cache zápis odpovídající informaci, která byla vyžádána komunikací vytvořenou web browserem 10, uplatní se větev "Yes" bloku 125. Zachycovací modul .40 straně serveru potom porovná aktuální datum a čas modulu 40 SSL se sumou SDT serverového cache zápisu odpovídajícího informaci, která byla vyžádána komunikací vytvořenou web browserem 10, a s předem definovaným klientovým koherentním časovým intervalem přijatým od zachycovacího modulu 30 na straně klienta.
Jestliže je aktuální datum a čas menší než suma SDT pro s e r v c r o v ý cache zápis a koherentní interval, poto m s e u p i. atní větev "Yes" desátém bloku 13.0. na obr. 5. Zachycovací modul 4.0. na straně serveru potom porovná CRC serverového cache zápisu s CRC k I ie n io v a ca che zápisu, aby určil, zda jsou tyto cache zápisy identické. Pokud jsou tyto dva cache zápisy identické, uplatní se větev "Yes" jedenáctého bloku 135 a jak je znázorněno pomocí dvanáctého bloku 136, odešle se "koherentní" odezva na zachycovací modul .3 0. na straně klienta. ·· ···· ·» » <1 *» ·· · ···· ···· ··· ··· ···· ··· ··· ·· *··· · ·*· ··· ··· ·· · ·· «*· ·· ·· - 1.8 - V případě, že podmínkový blok 135 určí, že CRC nejsou identické, potom nejsou identické ani informace obsažené v klientově caclie paměti a v serverové cache paměti a jak je znázorněno ve třináctém bloku 137, zachycovací modul na straně serveru odešle serverový cache zápis na první počítač 5. přes externí komunikačn í spoj 35. Při odesíláni serverového cache zápisu na zachycovací modul 3.0. na klientově straně konvertuje zachycovací modul 4.0 na straně serveru zápis na klientův specifický komunikační protokol, který obsahuje CRC, data a stáří serverového cache zápisu. Stáří serverového cache zápisu je vypočítáváno odečtením SDT cache zápisu od aktuálního data a čas u. A pokud, jak je konečně znázorněno na obr. 5, je buď suma SDT plus předem stanovený klientův koherentní časový interval menší než aktuální datum a čas, nebo neexistuje žádný cache zápis odpovídající URL komunikaci, vytvořené web browserem 1_0, potom se uplatní větev "No" desátého bloku 130. popřípadě větev "No” osmého bloku 1.25. Tak se provedou operace devátého bloku 12 6 a zachycovací modu1 4 0 straně serveru odešle na server komunikaci vy tv o ř e n o u w eb browse r e m 1.0. jako datový tok HTTP. .Jestliže zachycovací modul 40 na straně serveru musí odeslat komunikaci vytvořenou web browserem JJ) na server 2_0. jako datový tok HTTP, potom zachycovací modul 4.0. na straně serveru bude provádět o p era ce popsané obr. 6 . .lak je patrno ze čtrnáctého bloku 140 na obr. 6, v odpovědi, na komunikaci vytvořenou web browserem 1_0 bude zachycovací modul 40. na straně serveru 2.0. přijímat datový tok HTTP z web serveru 2 0. Po přijetí datového toku HTTP vypočte zachycovací modul .40 na straně serveru .2.0 CRC pro datový tok HTTP a dočasně uloží tento datový tok ΗTTP. Potom podle patnáctého bloku 145 , zachycovací modul 40 na straně serveru prozkoumá datový tok HTTP a určí, zda existuje serverový cache zápis odpovídající URL datového toku HTTP. Jestliže takovýto zápis existuje, uplatní se cesta "Yes" bloku 145. Zachycovat: í modul 40. na straně serveru potom porovná nedávno vypočtený CRC datového toku HTTP přijatého od web serveru 20. s CRC serverového cache zápisu odpovídajícího URL komunikaci v odpovědi vytvářené web serverem 20. podle šestnáctého bloku .15.0.. Jestliže jsou CRC identické, uplatní se větev "Yes" v bloku 1.5Q ♦ Zachycovaní modul 40 na straně serveru aktualizuje zápis SDT pro serverový cache zápis podle sedmnáctého bloku 151 a smaže dočasně uložený datový tok HTTP při jatý web serverem 2.0 podle omsnáctého bloku 152.
Jestliže výsledky porovnání CRC indikují, že serverový cache zápis je jiný než datový tok HTTP přijatý od web serveru 2.0, potom se uplatní větev "No" bloku 150. Zachycovací modul 40. na straně serveru odstraní ze serverové cache paměti stávající data podle devatenáctého bloku 1.5.3. a potom podle dvacátého bloku .154 aktualizuje serverovou cache novějšími informacemi. Z bloku 154 je dále patrné, že tato aktualizace zahrnuje uložení CRC komunikace web serveru 210. do serverové cache, uložení aktuálního data a času ve formě SDT jako součásti cache zápisu a uložení datového toku HTTP. Vždy při aktualizaci serverového cache zápisu n eho při zjištění, že serverový cache zápis je i d e n t ic k ý s přijatým datovým tokem HTTP od serveru 20., zachycovací modul 4 0. na straně serveru určí, zda serverový cache zápis se shoduje a klientovým cache zápisem odpovídajícím komunikaci, která je vytvářena web browseren 10. Tato operace se provádí v dvacátém P r v η í. ir. bloku .1.5.5 .
Jestliže zachycovací modul 4.0 na straně serveru určí, že neex i stuje cache zápis odpovídající odezvě přijaté od web serveru 20 , uplatní, se větev "No" bloku 145. Serverový cache zápis je vytvářen pomocí dvacátého druhého bloku 146 uložením URL odpovědi od web serveru 20, uložením CRC odpovědi od web serveru 20., uložením datového toku HTTP a uložením aktuálního data a času jako SDT. Po vytvoření cache zápisu odpovídajícího komunikaci vytvořené web serverem 20 zachycovací modul 40 na straně serveru -20 -20 ·· ···· ·· ·· · · < • · ··
··· · I • · ·· /.novu porovná (IRC tohoto ser vorového cache zápisu s CRC o d p o v í d a jícím klientově cache zápisu v b 1 o k u _1 5_5 ,
Jestliže výsledky porovnání serverového cache zápisu a klientova cache zápisu indikují, že cache zápisy jsou identické, uplatní se větev "Yes" bloku 155 a provedou se operace v dvacátém třetím bloku 156. Z bloku 156 je zřejmé, že zachycovací modul 40 na straně serveru odesílá koherentní odezvu na zachycovací modul 30 na straně klienta. Zachycovací modul 4J0 na straně serveru transformuje serverový požadavek o cache zápisu na specifický datový tok klient/server tak, že odešle koherentní odezvu a také nulové stáří na zachycovací modul 3_0 na straně k 1 i e n t a .
Pokud zachycovací modul 40 na straně serveru určí, že klientův cache zápis není identický se serverovým cache zápisem odpovídajícím komunikaci vytvářené web browserem JJ), uplatní se větev "No" bloku 155 a provedou se operace v dvacátém čtvrtém bloku 1.57. Přitom zachycovací modul .40 na straně serveru k o nv e r t u j e nebo transformuje serverový cache zápis do specifického datového toku klient/server. Tento datový tok
zahrnuje CRC serverového cache zápisu, datový tok HTTP serverového cache zápisu a stáří cache zápisu, které je nastaveno na nulu. Tato specifická komunikace klient/server je potom odeslána přes externí komunikační spoj 3JL na zachycovací modul 3 0 n a s 1: raně k I i e n t a .
Funkce zachycovacího modulu 30 na straně klienta po přijetí komunikace od zachycovacího modulu .40 na straně serveru je popsána s ohledem na obr. 4. Ve dvacátém pátém bloku 160, zachycovací modul 3.0 na straně klienta přijímá nebo vyžaduje s P e o i f i <; k ý d a t o v ý tok kl i ent/server , který je přenášen p ř e s externí komunikační spoj .35 · Zachycovací modul 30 na straně klienta potom určí, jaký typ odezvy byl přijat od zachycovacího modulu 4.0 na straně serveru v dvacátém šestém bloku 16 5. Jestliže 21
·· ·· * · · · • · ·· ··· · · • · · ·· ·· ··· zachycovaeí modul 40 na straně serveru indikuje, že klientův oache zápis je koherentní, t j . že jsou identické cache zápisy serveru a klienta, potom se provedou operace ve dvacátém sedmém bloku 166. Pomocí bloku 166 aktualizuje zachycovaeí modul .30 na straně klienta SDT klientova cache zápisu odpovídajícího komunikaci vytvořené web browserem 10. o rozdíly aktuálního data a času a stáří, které byly přijaty od zachycovaeího modulu 40 na straně serveru. Takže bez synchronizace hodin prvního počítače 5 a druhého počítače 6. umožňuje vynález zrevidovat koherentní čas cache zápisu prvního počítače 5, přičemž v něm zohlední novější data z druhého počítače Po aktualizaci SDT klientova cache zápisu odpovídajícího komunikaci vytvořené web browserem _10 odešle zachycovaeí modul .30. na straně klienta klientův cache zápis do web browseru 1.0 jako datový tok HTTP. Tato činnost se provádí dvacátým osmým blokem 174.
Jestliže však zachycovaeí modul 30 na straně klienta určí, že typem odpovědi jsou data nebo datový tok, uplatní se větev "stream" bloku 165 a provedou se operace v dvacátém devátém bloku .16 7 . Zachycovaeí modul 3_0 na straně klienta přijme datový tok HTTP a dočasně tato data uloží. Potom pomocí třicátého bloku 170 zachycovaní modul 3J) na straně klienta určí, zda existuje cache zápis odpovídající komunikaci vytvořené web browserem 10. Jestliže tento cache zápis existuje, uplatní se cesta "Yes" bloku IIP. a v třicátém prvním bloku 171 se regeneruje se stávající cache zápis. Zachycovaeí modul .30 na straně klienta potom aktualizuje cache zápis odpovídající komunikaci vytvořené web browserem 10. a to uložením CRC datového toku HTTP přijatého od zachycovaní ho modulu 4.0 na straně serveru, uložením jako SDT rozdílu mezi aktuálním datem, časem a stářím přijatými od zachycovat: í ho modulu 40 na straně serveru a uložením datového toku HTTP. Tato operace je provedena v třicátém druhém bloku 172.
Jestliže neexistuje cache zápis odpovídající komunikaci vytvořené web browserem 1J), uplatní se cesta "No" bloku 17 0. Je i 22 22 • · ·· • · ··· ·
• · · • · · · • · • · · • · 9 9 • · · · · • · · Μ Μ v y t v oř en k 1 i e ntův cache z á p :i s , a to provedením operací v třicátéin třet ím b 1 oku 1.7_3 . Pomocí bloku JJ7.3 vytvoří zachycovací modul 3.0, na straně klienta klientův cache zápis uložením URL datového toku HTTP, přijatého od zachycovacího modulu 40 na straně serveru, uložením CRC datového toku HTTP přijatého od zachycovacího modulu 4-Q na straně serveru a uložením datového toku HTTP. Zachycovací modul 30 na straně klienta rovněž aktualizuje SDT nebo uloží SDT odečtením stáří od aktuálního data a času, které bylo přijato přes externí komunikační spoj 3_5 od zachycovacího modulu 40. na straně server u.
Avšak klientův cache zápis se vytváří při každém průchodu bloky .1.6 6.., 17 2 nebo 17 3. V tom případě zachycovací modul 3J3 na straně klienta předá nebo poskytne klientův cache zápis w e b browseru 1.0 jako datový tok HTTP. Tyto operace se provádí v bloku 174 . Z pohledu hodnocení tohoto vynálezu je nutné podotknout, že klientova a serve rová cache paměť mohou být implementovány s jinou pamětí nebo s hromadnou pamětí, například s pevnými, disky, CD-ROM, optickými disky nebo jinými technologiemi ukládání. Dále je nutné v souvislosti s tímto vynálezem zmínit, že za c h y c o v a c í modul 30. na straně klienta a zachycovací modul 4_0 na straně serveru mohou být implementovány prostřednictvím softwaru, hardwaru nebo jejich kombinací.
Zatímco reference o vytvoření cache pamětí jsou rezidentní na konkrétním prvním 5. nebo druhém počítači 6., je nutné z pohledu posuzování tohoto vynálezu uvést, že přednosti z něj vyplývající mohou být získány i v případě, že cache paměti nebudou rezidentní na prvním počítači 5, ale jsou pouze na stejné straně externího komunikačního spoje 3.5 jako počítač. Hardwarová cache paměť může být implementována externě na první počítač 5, kde slouží jako klientova cache paměť, a může být připojena k prvnímu počítači 5 vysokorychlostní komunikací a i přesto, pokud je cache na
• · ·· ··· • 9 • ♦· • ·
• ♦ · · · · • · · 2 3 stejné straně komunikačního spoje jako první počítač „5, bude dosaženo výhod podle vynálezu. V alternativním zapojení podle vynálezu zachycovací modul 40 na straně s er v eru neuohovává kopii datového toku HTTP př i jatého od web serveru 2 0, ale pouze zápis adresáře pro komunikaci. Zápis adresáře pak obsahuje URL komunikace, CRC vypočtený pro datový tok HTTP a čas, kdy byl datový tok HTTP přijat od web serveru 20, a SDT pro .komunikaci, který může být nastaven na čas, kdy byl CRC vypočten. V takovém případě, když zachycovací modul 30. straně klienta odešle požadavek zachycovacímu modulu 40 na straně serveru na komunikaci odpovídající URL, pro kterou udržuje zachycovací modul. 40. na straně serveru CRC a SDT, tak zachycovací modul 40 na straně serveru zkontroluje CRC přijatý od zachycovací ho modulu 30. na straně klienta, aby určil, zda odpovídá CRC nejnovějáímu datového toku HTTP pro specifikovaný URL. Pokud odpovídá, potom je odeslána koherentní odpověď na zachycovací modul 30 na straně klienta. Neodpovídá-1i, odešle zachycovací modul 4J) na straně serveru datový tok HTTP přijatý od zachycovací ho modulu 30 na straně klienta na web server 20. a vrátí na zachycovací modul 3L0 na straně klienta odpověď přijatou od web serveru 20.
Obr. 7, 8, 9 a 10 znázorňují operace prováděné zachycovacím modulem 3.0 na straně klienta a zachycovacím modulem 4j) na straně serveru v jiném provedení podle vynálezu, které využívá stanovení rozdílu, t.j. diferencování, k tomu, aby se snížilo množství dat přenášených přes externí komunikační. spoj 35. Jak je zřejmé z obr. 7 třicátý čtvrtý blok 200 zajišťuje potvrzení zachycovacího modulu 30. na straně klienta na požadavek HTTP od web browseru lj). Třicátý pátý blok 205 zajišťuje, že zachycovací modul 30 na straně klienta prozkoumá zachycený požadavek HTTP od web browseru ljO, aby určil, zda je tento požadavek Common Gateway Interface (CGI). V případě, že tento požadavek je Common Gateway Interface, postoupí ho zachycovací modul 30. na straně klienta - 24 - ·· ···· ·* « • · · · · ·· • · · · · · • · · * · · · • · · · · · ·· * ·· · · » • · • · ► · · » · • · · * • · • · ·· • · • · zachycovaoímu modulu 40 na straně serveru, jak je znázorněno na obr. 3 až 6 a což probíhá ve třicátém šestém bloku 206 na obr. 7.
Pokud však komunikace vytvořená web browserem IjO odpovídá požadavku CG I , uplatní se větev "Yes“ bloku 2 0 5.. A pomocí třicátého sedmého bloku 210, zachycovací modul 30 na straně klienta stanoví, zda existuje klientův bázový cache zápis odpovídající datovému toku HTTP, který byl předtím poskytnut na web browser 10 v odpovědi na jemu odpovídající požadavek CGI. Toto zachycení požadavku CGI může být prováděno porovnáním URL komunikace vytvořené web browserem 1J) s URL uloženými v klientově bázové cache paměti.
Klientova bázová cache může být inicializována uložením prvního datového toku HTTP přijatého zachycováním modulem na straně 30 klienta, který by měl být poskytnut na web browser 10 pro daný URL. Tento bázový cache zápis může být udržován pomocí množství entit nebo relací web browseru 10. Klientovy bázové cache zápisy mohou být aktualizované způsobem znázorněným na obr. 7, 8,9 a 10. Jestliže existuje klientův bázový cache zápis odpovídající URL pro komunikaci vytvořenou web browserem 10, potom CRC , který má být odeslán na zachycovací modu 1 4_0 na straně serveru přes externí komunikační spoj 3_5 , je nastaven v třicátém osmém b 1 oku 2.11 stejně jako CRC pro klientův bázový cache zápis. Jestliže takový klientův bázový cache zápis existuje, potom se up1 atπ í větev "No" b1 oku 210 a CRC pro požadavek, který má být odeslán přes externí komunikační spoj 35. na zachycovací modu] 40. na straně server, je nulován. Tato operace je prováděna v třicátém devátém bloku 212 na obr. 7. Čtyřicátý blok 213 zajišťuje operace odesílání, požadavku CGI n a z a c hycova c í mod u1 40 na straně serveru přes externí komunikační spoj 35. Pomocí bloku 2.13 zachycovací. modul 30 na. straně klienta odešle požadavek HTTP a požadavek CRC, který má být buď nastaven na nulu, pokud neexistuje klientův bázový cache - 25 - - 25 - ·· ·· • · · • ·· • · · · · • · · ·· ·· ·· ···· ·· • · · · · • · · · · • · · · · ♦ • · · · « ·· ♦ ·· zápis pro URL požadavku CGI, nebo má být nastaven na CRC k .1 i entova bázového o a c h e zápisu, pokud takový zápis exist u j e . Z a c h ycov a c í modu] 3j) na straně klienta tedy konvertoval p o ž a d a v e k C GI na specifický protokol kl .ient/server přenášený spéci f i c k o u komunikací kli ent/server přes externí komunikační spoj 35. který má být přijat zachycovaní· modu1em 40 straně serveru. Činnosti prováděné zachycovacím modulem na straně serveru v době, kdy je přijat požadavek CGI, jsou znázorněny na obr. 9. Potvrzení požadavku CGI zachycovacím modulem 4J3 na straně serveru je provedeno ve čtyřicátém prvním bloku 220. Když zachycovací modul 4.0 na straně serveru přijme požadavek CGI, uloží kopii hodnoty CRC a požadavek HTTP. Pomocí čtyřicátého druhého bloku 221 zachycovací modul 40 na straně serveru předá požadavek HTTP na web server 20 .
Když zachycovací modul 40 na straně serveru přijme odpověď na požadavek HTTP odpovídající komunikaci vytvořené web browserem j,0 nebo požadavek CGI, bude tato odpověď zachycovacím modulem 40 na straně serveru přijata ve čtyřicátém druhém bloku 230 jako datový tok HTTP. Pomocí bloku 2.30, zachycovací modul 40. na straně serveru uloží datový tok HTTP a vypočte hodnotu CRC pro datový tok HTTP přijatý od web serveru 20. Zachycovací modul 4_0 na straně serveru rovněž vynuluje rozdílovou (diferenční) hodnotu, a to na inicializační rozdílová data. Zachycovací modul 4.0 na straně servěru potom pomocí čtyřicátého třetího bloku 235 stanoví, zda odpověď přijatá jako komunikace vytvořená web serverem 2 0 je odpověď na požadavek CGI. Jestliže je odpověď ne, uplatní se cesta "No" bloku 235 na obr. 10 a provedou se operace čtytř i eátého čtvrtého bloku 236 pro odeslání datového toku HTTP n a z a o h y o o v a c í m o d u 1 30 na straně klienta. Operace na blok u 236 může zahrnovat operace zachycení popsané na obr. 3 až 6. Jestliže odpověď přijatá blokem 230 je odpověď na požadavek CGI, potom se uplatní cesta "Yes" bloku 235 a zachycovací modul 30 na straně serveru pomocí čtyřicátého pátého bloku 240 dále stanoví, jestli 26 ·· ·«·« • «
• · • · ·· ·· • · · · • ♦ ·· • ··♦· ♦ • · · existuje serverový bázový cache zápis pro odpověď CGI.
Serverový bázový cache zápis může být vytvořen, když zachycovací modul 40 na straně serveru poprvé přijme odpověď na. požadavek CGI. V tomto případě bude výsledkem podmínky provedení cesty "No" blokem 240. Zachycovací modul 40 na straně serveru potom vytvoří serverový bázový cache zápis odpovídající požadavku CGI, a to uložením URL pro CGI, datového toku HTTP odpovědi na požadavek CGI a CRC pro datový tok HTTP. Tato operace je provedena ve čtyřicátém šestém bloku 241. Má-1 i být dosaženo kompatibi1nosti s koherentním cache systémem popsaným obr. 3 až 6, může serverový bázový cache zápis také obsahovat SDT. Podobně, jak je zde použito, označuje termín forma serverové CGI báze serverový bázový cache zápis odpovídající požadavku CGI přijatému od wob browseru 10..
Jestliže existuje serverový bázový cache zápis odpovídající požadavku CGI, uplatní se cesta "Yes" bloku 240. Zachycovací modul 40 na straně serveru porovná CRC serverového bázového cache zápisu s CRC odpovědi přijaté od web serveru 20.. Tyto operace jsou provedeny ve Čtyřicátém sedmém bloku 245 na obr. 10. V případě, že jsou CRC shodné, stanoví zachycovací modul 40 na straně serveru, zda CRC pro serverový bázový cache zápis odpovídá C RC p ro klientův bázový cache zápis. Jestliže jsou tyto dvě hodnoty CRC stejné, potom klientův bázový cache zápis, serverový bázový cache zápis a odezva přijatá z web serveru 2_0 budou obsahovat stejný datový tok HTTP. Porovnání serverového bázového cache zápisu s klientovým bázovým cache zápisem je provedeno ve či,yř i cátém osmém b 1 oku 250 .
Jestliže jsou tyto dva zápisy shodné, potom zachycovací modul 40 na straně serveru nemusí odesílat bázový cache zápis na zachycovací modul 30 na straně klienta a tedy pomocí čtyřicátého dovátého bloku 2.5.1. je tok HTTP dat, která mají být přenesena na zachycovací modul 3.0 na straně klienta, vynulován. Zachycovací Μ ···# ·· • · · · · • · · · · • · · · · · • * · · · ·♦ · ·· • ·· ·· ·· · »· « • · · · · • · · · · · · • · · · ··· ·· ·· ~ 2 7 -m o d u 1 4 0 ti a s i :r a ně server u p o t cm konver t u je datový to k Η TTP přijatý od web serveru 20 na specifický komunikační protokol klient/server odesláním GRC datového toku HTTP uloženého v serverové bázové cacbe paměti odpovídajícího požadavku CG I , vynulovaný datový tok HTTP dat a vynulovaná rozdílová (diferenční) data s cílem indikovat, že odpověď na požadavek CG I byla identická klientovu bázovému cache zápisu, což je provedeno p a desátý m blokem 252 .
Jestliže je CRC pro serverový bázový cache zápis odpovídající požadavku CGI odlišný od CRC pro odpověď přijatou od web server 20 v odpovědi na požadavek CGI vytvořený web browserem 10., potom se uplatní větev "No" bloku 245. Zachycovací modul 40 na straně serveru potom provede operace pomocí padesátého prvního blokem 2_46· Zachycovací modul 40. na straně serveru porovná zachycenou odpověď CGI se serverovým bázovým cache zápisem odpovídajícím zachycenému požadavku CGI nebo s bázovou formou CGI. Toto porovnání zachycené odpovědi CGI se serverovou bázovou formou CGI poskytne rozdílová (diferenční) data CGI, která odpovídají rozdílu mezi zachycenou odpovědí CGI a serverovou bázovou formou CGI .
Stanovení rozdílu (diferencování) může být, z pohledu hodnocení stávajícího vynálezu, provedeno libovolnou známou metodou pro stanovení rozdílu mezi bázovou formou a upravenou (modifikovanou) formou. Jedna metoda vhodná pro použití ve stávajícím vynálezu je popsána v "Cross-Platform Binary Diff" publikované v Dr. Dobb’s Journal, květen 1995, str. 32-36. Její popis je zde zapracován, a rovněž je zde uvedena reference pro plnou citaci. Dalšími metodami, které mohou být použity pro stanovení rozdílových dat, jsou metody popsané v IBM Tec:hni ca 1 Disclosure Bulletin, sv. 22, č. 8A, leden 1980, které jsou zde rovněž zapracovány a pro plnou citaci uvedeny referenční odkazy. Zachycovací modul. .40 na straně serveru potom stanoví, jak je znázorněno v padesátém druhém bloku 247, zda serverová bázová - 28 - - 28 - φφ φφφφ • Φ φ φφ φφ • · φ φφφφ Φ·ΦΦ • · · φφφ φφφφ • · · φφφ φ φ φφφ φ φ • · φ φφφ φφφ φφ · φφ φφφ φφ φφ forma CGI vyžaduje aktualizaci. Toto stanovení může být provedeno určením, zda průměrná rozdílová data mezi zachycenou odpovědí GGI a serverovou bázovou formou CGI překračují stanovený práh. Další metody pro stanovení, zda s e r v e r o v ý bázový c a c h e zápis odpovídající požadavku GGI by měl být aktualizován, mohou zahrnovat časovou koherenci, tak jak je popsáno obr. 3 až 6, nebo to mohou být i jiné známé metody vhodné ke stanovení, zda se rozdílová data změnila natolik, že je zapotřebí vytvořit nový bázový cache zápis ke zlepšení systémové výkonnosti.
Jestliže vytvoření nového bázového cache zápisu není zapotřebí, uplatní se větev "No" bloku 247 a zachycovací modul .40 na straně serveru provede operace popsané blokem 250 ke stanovení, zda CRC klientova bázového cache zápisu je shodný se servorovým bázovým cache zápisem nebo zda je serverová bázová forma GGI identická s klientovou bázovou formou CGI, což jsou v podstatě bázové cache zápisy serveru a klienta, jež odpovídaly konkrétnímu požadavku CGI komunikace vytvořené web browserem 10. Jestliže jsou tyto bázové formy shodné, není nutné obnovovat klienta a informace o datovém toku HTTP mohou být vynulovány, jak je znázorněno ve čtyřicátém devádém bloku 251. Zachycovací modul .40 na straně serveru potom odešle rozdílovou odpověď na zachycovací modul 30 na straně klienta, a to odesláním CRC serverového bázového cache zápisu odpovídajícího požadavku CGI (tj, CRC serverové bázové formy CGI), odesláním vynulovaného datového toku HTTP, který by korespondoval s bázovými daty, a odesláním rozdílových (diferenčních) dat stanovených v padesátém prvním bloku 246. Tyto operace jsou se opět provádí v padesá tém h 1 oku 2.5 2 na obr . 10.
Jestliže zachycovací modul 40. na straně serveru stanoví, že porovnávané CRC nejsou shodné (pro klientovou bázovou formu CGI a serverovou bázovou formu CGI), potom je nutné obnovit klienta. Operace obnovení klienta zahrnuje odeslání serverové bázové formy 0 G1 n a z a o h ycovací m o d u 1 30. na straně klienta. Při provedení této - 29 - ·· • · • · • · • · • · ·♦ · • · ·· ♦ · φ t · · • # « ·· ··· • · • · · « • · ·· ·· · · · • · · ·» ·· • · operace zachycovací modul 4.0 na straně serveru nastaví data datového toku HTTP pro odeslání na zachycovací modul 3_0 na straně klienta shodně se serverovou bázovou formou CGI. Tato operace se provádí v padesátém třetím bloku 253 . Zachycovací modul 4_0 a straně serveru potom konvertuje datový tok HTTP přijatý od web serveru 10 na specifický protokol klient/server odesláním CRC serverové bázové formy CGI, dat datového toku HTTP odpovídajícímu se rve rove. bázové formě CGI a odesláním rozdílových (diferenčních) dat bázové formy CGI a odezvy přijaté od web serveru 2j), což se provádí v padesátém bloku 25_2. Tato informace je pak předána přes externí komunikační spoj 3J5 na zachycovací modul .30. na straně kli enta.
Zpět k padesátému druhému bloku 247. Jestliže je zapotřebí obnova, uplatní se cesta "Yes" bloku 247. Jak je znázorněno padesátým čtvrtým blokem 248, zachycovací modul 4.0 na serverové straně aktualizuje serverový bázový cache zápis odpovídající komunikaci vytvořené browserem 10 o datový tok HTTP přijatý od web serveru 20. Aktualizován je rovněž CRC odpovědi a rozdílová (diferenční) data CGI jsou vynulována. Zachycovací modul 40 na straně serveru pak porovná CRC nového cache zápisu serverové strany, jak je znázorněno ve čtyřicátém osmém bloku 250, a dokončí se přenos výše popsaným způsobem.
Operace zachycovací ho modulu 4.0 na straně klienta o přijetí odpovědi od zachycovacího modulu na straně serveru jsou znázorněny na obr. 8. Přijetí odpovědi od zachycovacího modulu 40. na straně serveru zachycovacím modulem ,30. na straně klienta se provádí v padesátém pátém bloku 260. Jak je zřejmé z padesátého šestého bloku 26 5 , zachycovací modul 30. na straně klienta stanoví, zda odpověď je odpovědí na požadavek CGI. Pokud to není odpověď na požadavek CGI, potom zachycovací modul 3_0 na straně klienta provede operace podle padesátého sedmého bloku 267, které mohou zahrnovat operace cache znázorněné obr. 3 až 6. Jestliže však odpověď je odpovědí na požadavek CGI, uplatní se větev "Yes" 30
• · • · • · • · · ·· *· • I · · • · ·· • ··· · » • · · ·· ·· bloku 265. Zachycovací modul 3J) na straně klienta uloží data datového toku HTTP, rozdílová data a CRC vyžádaný od specifického datového toku kJ i ent/server přenášeného přes externí komuni kační, spoj 35. Tyto operace se provádí v padesátém osmém bloku 266 na obr. 8
Zachycovací modul 30 na straně klienta potom stanoví, zda existuje klientův bázový cache zápis odpovídající zachycenému požadavku CGI, který by obsahoval klientovu bázovou formu CGI. Toto zkoumání se zaznamenává v padesátém devátem bloku 270 a může být prováděno prověřením URL požadavku HTTP nebo odpovědi HTTP. Jestliže klientova bázová forma CGI existuje, uplatní se větev "Yes" bloku 270. Zachycovací modul 30 na straně klienta potom porovná CRC přijatý přes externí komunikační spoj s CRC klientovy bázové formy CGI, což se provádí v šedesátém bloku 275. Pokud jsou odlišné, uplatní se cesta "No" bloku 275 a provede se obnova klienta aktualizací bázové formy CGI, a to výměnou klientova bázového cache zápisu odpovídajícího URL požadavku CGI komunikace vytvořené web browserem IQ za data datového toku HTTP přijatá přes externí komunikační spoj 35 od zachycovacího modulu 4J) na straně serveru. Klientův bázový cache zápis je rovněž ak t ua1 i z o v án s ohledem na CRC pro datový tok HTTP. Tyto operace se provádí v šedesátém prvním bloku 276 na obr. 8.
Jestliže CRC přijatý přes externí komunikační spoj 3J5 je stejný jako CRC bázové formy CGI, potom serverová bázová forma CGI na zachycovacím modulu .40 na straně serveru je shodná s klientovou bázovou formou CGI na zachycovacím modulu na straně klienta, a uplatní se větev "Yes" šedesátého bloku 275.
Jsou-li bázové formy stejné nebo klient byl obnoven, provedou se operace uvedené v šedesátém druhém bloku 277. a to zachycovacím modulem 30 na straně klienta. Blok 277 odráží, jak zachycovací modul 30 na straně klienta rekonstruuje datový tok HTTP odpovídající komunikaci od web serveru .20 ze specifického - 31 - - 31 - ·« • ♦ · • « • » • m · ·· • • #·· • 9 • • • · ·· *» «*·« • · · • · · • · ♦ 9 ·· · datového toku klient/server přijatého přes externí komunikační «Poj .3.5, a to sloučením klientově bázové formy CGI s rozdílovými daty CGI přijatými přes externí komunikační spoj 3_5 tak, aby se vytvoři 1 datový tok HTTP odpovídající zachycené odpovědi. CGI. Jak je zřejmé ze sto šedesátého šestého bloku 278 . bude tato odpověď poskytnuta web browseru 10 jako datový tok HTTP.
Pokud u klienta neexistuje žádná bázová forma CGI odpovídající URL požadavku CGI, potom, se uplatní větev "No" bloku 270 na obr. 8. Jak je zřejmé z bloku 271. zachycovací modul 30 na straně klienta vytvoří klientův bázový cache zápis odpovídající URL požadavku CGI, a to uložením URL, CRC datového toku HTTP přijatého přes externí komunikační spoj 3J> od zachycovacího modulu 4_0 na straně serveru a skutečných dat datového toku HTTP. Uložení těchto informací vytvoří klientův bázový cache zápis odpovídající zachycenému požadavku CGI, a tedy vytvoří klientovu bázovou formu CGI. Zachycovací modul 30. na straně klienta může pak provést operace podle šedesátého druhého bloku .277 , a to rekonstruováním datového toku HTTP pomocí s 1 ouoení nebo vnoření klientovy bázové formy CGI a rozdílových dat CGI, které mohly být vynulovány.
Stávající techniky vytváření diferencování mohou být uplatněny rovněž u. dat jiných než CGI. V takovém případě by z a c h y c o vací m o d u 1 4 0. na straně serveru potřeboval uchovávat násobné generace serverových bázových cache zápisů, které by mu umožnily, aby zachycovací moduly 3.0 na straně klienta od připojených web browserů 10 na web server 2 0. mohly mít různé bázové formy. Zachycovací modul 40. na straně serveru by potom mohl porovnávat CRC přijatý od zachycovacího modulu 30. na straně klienta s CRC jednotlivých předchozích generací serverových bázových forem až do doby, kdy by byla nalezena shoda. Zachycovací modul 40 na straně serveru může potom volitelně obnovit zachycovací modul .30. na straně klienta nebo prostě předat diferenční data na zachycovací modul 30 na straně klienta. * · · · · · • · • · · · · ·· · ···· ···· • · · ·· · ···· • · · · · · · · ···· · • · · ··· ··· ·· · · · ··· · · «· - 3 2 -
Di ťeren6ní metodiky zde popisované by se tedy pak uplatnily s ohledem na požadavek CGI stejným způsobem, jako u každého j i n ého požadavku HTTP a odpovědi.
Zatímco výše uvedený systém udržování násobných generací bázových forem může dovolovat použití diferencování i u jiných požadavků než CGI, je tato metodika paměťově neboli kapacitně náročnější a nevyužívá plně výše popsaných zachycovacích schopností. V zájmu snížení nároků na paměť či kapacitu a využití výše popisovaných zachycovacích metod je upřednostněna možnost použití následující metody diferencování u jiných než CGI požadavkii. U této přednostní implementace vypočítává zachycovací modul 4.0 na straně serveru rozdíl mezi serverovou bázovou formou odpovídající požadavku a datovým tokem HTTP odpovědi od web serveru 20. Tato diferenční data jsou pak uložena zachycovacím modulem 40 na straně serveru. Serverová bázová forma je potom aktualizována výměnou bázové formy za novou odpověď od web serveru 2.0, a to včetně aktualizace CRC této bázové formy. Avšak spíše než zlikvidováním starého CRC, jsou jednotlivé CRC pro dřívější bázové formy uloženy jako rozdílová data. Předchozí generace rozdílových dat a jednotlivých CRC jsou pak selektivně přenášeny na zachycovací modul 3J3 na straně klienta, a to na základě CRC klientovy bázové formy odpovídající požadavku jinému než CGI. Příklad metody diferencování u jiných požadavků než CGI - jestliže zachycovací modul 40. na straně serveru přijme jiný požadavek než CGI, byl by tento požadavek rovněž doprovázen. CRC bázové formy rezidentní na zachycovacím modulu 3_0 na straně klienta odpovídající URL non-CGI požadavku. Když by zachycovací modul 40 na straně serveru přijal odpověď od web serveru 20, vypočítal by CRC odpovědi. Zachycovací modul 40 na straně serveru by potom vypočetl rozdíl mezi odpovědí a serverovou bázovou formou pro URL a tato rozdílová data by uložil. Zachycovací modul 4.0 na straně serveru by dále aktualizoval serverovou bázovou ·· ···· ·· ♦ ·· ·· ·· · · ♦ ·· ···· * · * · · · ···« • ·· ·· · · · «··· · ··· ··· « · · • · « · ♦ ··· ·« · · 3 3 formu o data odpovědi a archivoval CRC dřívější bázové formy i rozdílová data mezi odpovědí a starou bázovou formou. Zachycovací modul 4_0 na straně serveru by potom porovnal CRC klientovy bázové formy s CRC s e r v e r o v é bázové formy a se všemi uloženými nebo archivovanými CRC tak, aby určil, zda je nalezena shoda. Pokud shoda není nalezena, bude odpověď jednoduše odeslána, na zachycovací modul .30. na straně klienta.
Jestliže je nalezena shoda, jsou odeslána rozdílová data odpovídající shodnému CRC a všechna následná rozdílová data včetně aktuálních rozdílových dat na zachycovací modul 3_0 na straně klienta. Zachycovací modul 3.0 na straně klienta pak rozdílová data použije v klientově bázové formě k rekonstrukci odpovědi. Potom, vyskytne-li se napf. shoda CRC s CRC pro bázovou formu, která byla tři generace stará, budou odeslány tři sady rozdílových dat na zachycovací modul 3_0 na straně klienta a konstrukce odpovědi bude provedena uplatněním těchto tří následných rozdílových datových sad v klientově bázové formě. Jes11 iže však jsou počet sad rozdílových dat nebo velikost sad ro zdílových dat potřebných pro rekonstrukci odpovědi tak značné, že odeslání skutečné odpovědi by vyžadovalo přenášení méně dat, potom může být odeslána zachycovacím modulem 40. na straně serveru vlastní odpověď. V každém případě by po rekonstrukci nebo po při jetí odpovědi zachycovací modul 30, na straně klienta aktualizoval klientovu bázovou formu pro URL požadavku o data odpovědi a také aktualizoval CRC' o CRC pro odpověď. Protože je klientova bázová forma aktualizována při každém přijetí odpovědi pro konkrétní URL, může být využito výše popsané klientovy cache paměti jako cache pro klientovu bázovou formu, a tak dosaženo eliminace potřeby mít samostatnou cache paměť klientových bázových forem za situace, kdy je diferencování využíváno pro jiné požadavky než CGI.
Uplatněním dalšího znaku vynálezu může nastat další úspora komunikace, a to na základě omezení redundance nestavového ♦ · · · · 1« * * « · • · · ·· • · ··♦♦ · • · ♦ · ··· ·· ·· ·· · · ·· · * • · « · · • · · * · • · · · · · • · · · · ·· · ·· - 34 - komunikačního protokolu, jako např. HTTP. U tohoto protokolu klient odesílá informace o sobě na server pokaždé, když je iniciována komunikace. Podobně server poskytuje specifické informace o sobě vždy, když iniciuje svoji odpověď na klienta. V jednom z alternativních začlenění stávajícího vynálezu první počítač 5 komunikuje s druhým počítačem 6, kde mu předává počítačově specifické informace související s předem definovanými charakteristikami prvního počítače 5.. Druhý počítač 6. tuto počítačově specifickou informaci uloží. První počítač 5. potom odstraní počítačově specifickou informaci z následných komunikací vytvářených web browserem 1_0 před odesláním přes externí komunikační spoj 35. Druhý počítač 6 potom rekonstruuje originální komunikaci vytvořenou web browserem H), a to sloučením uložené počítačově specifické informace a následné komunikace přijaté přes externí komunikační spoj 3_5 tak, aby vytvořila datový t o k ΗT T P .
Kromě odstranění počítačově specifických informací z komunikací vytvářených web browserem 1_0 je možné tyto počítačově specifické informace odstranit i z komunikací vytvářených web serverem 2_0. V tomto případě druhý počítač 6., viz obr. 2, poskytne prvnímu počítači 5 přes externí komunikační spoj 115 počítačově specifické informace v souladu s předem definovanými, charakteristikami druhého počítače ,6. První počítač 5. uloží tyto počítačově specifické informace tak, aby dokázal vytvořit serverové záhlaví. U následné komunikace potom druhý počítač 6 odstraní počítačově specifické informace komunikace vytvořené web serverem 20 a odešle zbývající část komunikace vytvořená web serverem 20 na externí komunikační spoj 35♦ První počítač tuto komunikaci _5. přijme přes externí komunikační spoj >15. a rekonstruuje původní komunikaci vytvořenou web serverem _20., a to sloučením informace serverového záhlaví a specifického datového toku klient/server přijatého přes externí komunikační sPo.'i .35 tak, aby vytvořil datový tok HTTP. V obou případech jsou ·· ···· ·· · ·· ··
• · * · · ·♦ · · » I • » » ··· # · ·« • · · · · # · · ·Μ | · • Φ * · Φ # · · t ·· · ΦΦ ··· Φ· ·· - 3 5 operace odstranění počítačově specifických informací a uložení těchto informací pro vytvoření buď informace serverového záhlaví, nebo informace klientova záhlaví prováděny zachycovacím modulem 3.0 na straně k 1 ient.a či zachycovací» modulem 4J) na straně serveru, v závislosti na tom, zda se operace provádějí na prvním po č í ta č i 5 n e bo n a druhém počítá č i 6. V provedení podle vynálezu komunikuje web browser Η) se zachycovacím modulem 30. na straně klienta s využitím protokolu nazvaného Transrn i ss i on Contro 1 Protocol/lnternet Protocol (TCP/IP). TCP může být rovněž použit pro komunikaci mezi zachycovacím modu1em 30 na straně klienta a. zachycovací» modulem 40 na straně serveru přes externí komunikační spoj 3.5.· Konečně, TCP může být použit pro komunikaci mezi zachycovacím modulem 40. na straně serveru a web serverem 20. Zatímco TCP může být použit pro komunikace mezi různými komponenty, .které vytvářejí systém stávajícího vynálezu, protokol HTTP neposkytuje nejefektivnější prostředky pro komunikaci přes externí komunikační spoj 35♦ Ke zvýšení výkonnosti externího komunikačního spoje 35. vytváří jedno z provedení vynálezu to, co se zde označuje pod pojmem "virtuální sokety", které se využívají při spojení mezi web browserem 10. a zachycovacím modulem 30 na straně klienta a mezi zachycovacím modulem 10 na straně serveru a web serverem 2L0. Činnost těchto virtuálních soketů bude nyní popsána s odvoláním na obr. 11 až 17 .
Obr. li je blokové schéma jedné z možných implementací vynálezu využívající koncepci virtuálních soketů. Jak je zřejmé z obr. II, první počítač 5 a druhý počítač 6 jsou v z á j e m n ě propojeny přes externí komunikační spoj 35. Web browser 10. má p i.ui·a 1 i tu r eá 1 ných soketů, které propojují web browser 1_0. se z a chycovacím m o d u 1 e m 3.0 na straně klienta. Na obr. 11 je znázorněn první reálný soket 65a na web browseru 10 a jemu o d p o v í d a j í e í s o k e t 65b na zachycovacím modulu .30. na straně klienta. Tento první reálný soket 65a je soket TCP, přes který %f> ·Μ· • · • ·
• · * · • * · · · « • · · « » · · 3 6 web browser 10 vyžaduje další. spojení od zachycovacího modulu 30. na straně k.1 ienta.
Když web browser 10 vyžaduje nové spojení TCP, objeví se komunikace přes reálný soket 65a, která je přijata na reálný odpovídající soket 65b. Zachycovací modul 3.0. na straně klienta vytvoří potom další reálný soket pro komunikaci s web browserem 10. Jak je zřejmé z obr. 11, pluralita reálných soketů je vytvářena na web browseru 10. společně s odpovídajícím reálným soketem vytvářeným na zachycovacím modulu 3.0 na straně klienta. Tyto reá.lne sokety 6_0a až 64a jsou znázorněny na web browseru JjO a odpovídající sokety 60b až 64b na zachycovacím modulu 30 na straně klienta. Tyto reálné sokety tvoří prostředky, přes které web browser .10 komunikuje se zachycovacím modulem 30. na straně klienta. Po vytvorení reálných soketů 60a až 64a a odpovídajících soketů 60b až 64b jsou komunikace přes tyto sokety multiplexovány na reálný soket 3.6 a, který poskytuje přístup zachycovací mu modulu 3.0 na straně klienta na externí komunikační spoj 35. Reálné sokety 3.6a a 36b jsou vytvořeny v době, kdy je odeslán požadavek přes další reálný soket 3.7a. počítače 5 na další reálný odpovídající soket 37b počítače .6. Po potvrzení požadavku o spojení dalším reálným odpovídajícím soketem 37b se vytvoří r e á 1 n é s o k e t y 36a a .36b . Sokety 37 a a 37b pracují jako první reálné sokety pro potřeby komunikace mezi zachycovacím modulem 3 0 na straně klienta a zachycovacím modulem .40. na straně serveru a mohou být používány pouze pro ustanovení spojení mezi dvěma mod uly znázorněným i sokety 36a a 3 6b. Každý z těchto reálných soketů pracuje pod standardními protokoly TCP/IP. Když jsou druhým počítačem 6 přijímány komunikace přes externí komunikační, spoj 3 5. jsou přijmuty na reálný soket 36b. Zachycovací modul 40. na straně serveru potom demultiplexuje tyto komunikace na soketů 36b a poskytne je příslušnému soketů za účelem přenosu na web server 20. Tak může být například uskutečněna komunikace přes soket 60 a na soket 60b. za účelem požadavku informace od specifického URL, která by byla multiplexována na soketů 36a. - 3 7 ·· ···· ·· • · * · · · • · · » I • · · · · · • « · f · ·· * ·· · • * M • · · • ·· • · · · · • · · ·· · · přijata soketem 36b. demultipiexována zachycovacím modulem .40 na straně serveru a přenesena z dalšího prvního reálného soketu 60c na další první odpovídající soket 60d na web serveru .20. Podobně jsou i. komunikace vyskytující se přes soket 61a přijaty soketem 0 I b, multi plexovány zachycovacím modulem na straně klienta .30. a odeslány ze soketu 36a na soket 36b, kde zachycovací modul 4_0 na straně serveru tyto komunikace demultiplexuje a odešle přes soket 61c na soket 61d. Takže komunikace přes soket 60a a 60b, 61a a 61b, 62.a a 62b. 63a a 63b a 64a a 64b jsou přenášeny přes příslušné odpovídající sokety mezi zachycovacím modulem 40 na straně serveru a web serverem 20, tj. soket 60c a soket 6Od, soket 61c a .6Id, soket 62c a soket 62d., soket 63c a soket 63d a soket 6jtc a 64d..
Podobně pak odpovědi na otázky od web browseru 1_0 produkované web serverem .2.0 jsou rovněž přenášeny přes soketové spojení web serveru 20 na zachycovací modul 40 na straně serveru a přes externí komunikaěn í spoj .3.5. na zachycovací modul 30. na straně klienta, a potom dále na web browser 10. Potom například by odpověď vytvořená web serverem 2.0 byla odeslána přes soket 60d na soket 6.0c a muLtip1exována zachycovacím modulem 40 na straně serveru na soket .36b, která by byla odeslána přes externí komunikační spoj 3.5. na soket 36a. Zachycovací modul .30 na straně klienta potom demultiplexuje komunikaci a poskytne ji na soket 60b pro přenos na 60a na web browseru 10. Obdobná komunikační cesta je ustanovena pro každý soket, jenž je využíván web browserem IQ nebo web serverem 20. Z pohledu hodnocení tohoto vynálezu je nutné poznamenat, že zatímco byl stávající vynález popisován s ohledem na 4 soketová spojení mezi web browserem .1.0 a web serverem 20., může být otevřen libovolný počet soketů pro z a j i š t ě n í |< o m u n i k a č n í h o přístupu mezi web browserem Í..0. a web s e r v e r e m 2 0.
Obr. 12 představuje blokové schéma implementace virtuálního soketového systému v zachycovacím modulu .30 na straně klienta a zachycovacím modulu 40 na straně serveru. Externě k těmto modulům 30, 40 jsou reálné sokety mezi zachycovacím modulem 3_0 na straně klienta a web browserem ,1J) a zachycovacím modulem 40. na straně serveru a web serverem 20, které fungují jako normální TCP/IP sokety. To znamená, že použití virtuálních soketfi je transparentní vůči web browseru 1.0 i web serveru 20 .
Konkrétní začlenění stávajícího vynálezu bude popsáno s ohledem na blokové schéma uvedené na obr. 12 a vývojové diagramy na obr. 13 až 17. Obr. 13 je vývojový diagram soketového manažera znázorněného šesdesátým třetím blokem 68 na obr. 12. S odvoláním na obr. 13, šedesátý čtvrtý b1 ok 300 odráží vytváření manažera reálných soketů v bloku 68 zachycovacího modulu 30 na straně klienta. Poté, co byl vytvořen v bloku 6_8 manažer reálných soketů, vytvoří se první reá 1.n.ý soket znázorněný na obr. 1 2 jako prvn í od po v í da.j í c í soket 65b . Vytvoření tohoto prvního reálného soketů je reflektováno šedesátým pátým blokem 301 na obr. 13. Po vyt v oř ení prvního odpovídajícího soketů 65b počká šedesátý třetí blok 68 manažera reálných soketů rezidentní na zachycovacím modulu 30 na straně klienta, v tomto materiálu rovněž označovaný jako klientův manažer soketů, na událost na prvním odpovídajícím soketů 65b, jak je znázorněno v šedesátém šestém bloku 302 na obr. 13. Jakmile je přijata událost na prvním odpovídajícím soketů 6.5b, manažer reálných soketů ji prozkoumá a s ohledem na výsledek tohoto prozkoumání zvolí jednu z pěti možných cest, jak je znázorněno v šedesátém seiém bloku 305. V případě vytvoření reálného soketů v odpovědi na požadavek o komunikaci, přijatý na první odpovídjící soket 6 5b. přidá, jak je naznačeno v cestě od bloku .305 do šedesátého osmého bloku 3 06 n a o br. 13, m a na žer r e á1n ý ch soketů podle šedesátého t ře t í h o bloku 6 8 reálný soket, do seznamu reálných událostí. Manažer reálných soketů potom vytvoří simplexní virtuální soket, jak je naznačeno v šedesátém devátém bloku 307. V případě zachycovacího modulu 30 na straně klienta bude manažer reálných soketů 39
·♦ *· • « · · • · · · • ·«· · ♦ » · · • · · · i n d i ková t a p I i k a ční funkci, k. t erá zajistí p r ovedení f u n k c í z a chycovac í. ho m o d u I u 30 na straně klienta pro vytvořený virtuální so k e t, jak je znázorněno v sedmdesátém b i o k u 308 na obr. 13.
Jak je zde uvedeno, termín "simplexní soket" nebo "simplexní virtuální soket" odkazuje na soket, který spojuje přímo buď jednoduchý soket, nebo jednoduchou aplikaci. Zde je použit také "multipi exní soket.", který označuje soket pro spojení na pluralitu dalších soketů. Multiplexní soket tedy vykonává multiplexní nebo demultiplexní funkci a simplexní soket vykonává individuální spojení. To znamená například při provádění funkcí, bloků 306 až 308 na obr. 13, že manažer soketu klienta v odpovědi na požadavek o první spojení přijatý prvním odpovídajícím soketem 65 b vytvoří reálný šestý odpovídající soket 60b. simplexní virUiální soket 70 a označí zachycovací funkci na straně klienta v aplikaci 80. Podobně pro následné události, kde je vytvářen reálný soket, manažer reálných soketů vytvoří reálné sokety 61b, 6_2b, 63b nebo 6 4b a simplexní virtuální sokety 7_1 , 7_2, 7_3 nebo 74. a určí funkci OS 1 odpovídající vytvořeným reálným a virtuálním soketům, znázorněným jako aplikace 81 . 8 2 , 8 3 nebo 84. na obr. 12. Činnost zachycovací. funkce na straně klienta bude n y n í popsána s odvoláním na šestý odpovídající soket 60b , s imp1exní virtuální soket 70 a zachycovací funkci na straně klienta danou aplikací 80, znázorněnou na obr. 12. Sedmdesátý první blok 325 na obr. 14 odráží vytvoření zachycovací funkce na straně klienta dané aplikací 80. Po vytvoření čeká zachycovací funkce na straně klienta na událost na simplexním virtuálním soketu 70. jak je naznačeno v sedmdesátém druhém bloku 326. Tato operace čekání se vykonává prováděním virtuální funkce výběru, která je popsána obr. 16-4. Po potvrzení události je tato událost prozkoumána, jak je naznačeno v sedmdesátém třetím bloku 330. Jestliže událost je zavření virtuálního soketu, potom zachycovací funkce na straně klienta smaže simplexní virtuální soket 70, jak je naznačeno v sedmdesátém čtrtém bloku 349« a ukončí se, jak je naznačeno 40 - • · ···· • · ·
• · ♦ · * · • · * ·· « ·« ♦ ♦ · ♦ ··« ·♦ ·· * · · • · · ··♦ · ♦ ♦ · · ·· ·· v sedmdesát.cm pátém bloku 350 na obr, 14.
Jestliže událost je příjem dat, potom se uskuteční cesta od b lok u 3.3 0 k s e dmde s á t é m u š e s t ému bloku 331 a z a c h y c o v a c í f u n k c e na straně klienta při jme komunikaci vytvořenou browserem jJl od s i rn p 1 a x n í h o vir t u á 1 n í h o soket u 70 , a t o u s k u t ečněn í m v i r t u á 1 n í operace pří jmu popsánou v tomto mater χά1u s odvoláním na obr. 1 6-3. Zachycovací funkce na straně klienta potom provede výše p o p s a n o u 1' u n k o :i z a c h y c o v a c í b o m o d u 1 u na straně k 1 i enta , v i z n a p ř . obr. 3 a 7, která je znázorněna v sedmdesátém sedmém bloku 332 . Zaohyoovací funkce na straně klienta potom vytvoří mult ip.lexn í virtuální soket 90, který je spojen s reálným šolce tem 3 0 a z a c tiycova c í h o m o d u 1 u 3 0 n a straně klienta . Re á 1 n ý soket 36a j e spo j«n s reá.1 ným odpoví da j í c í m soketem 36b zachycovacího modulu 40 πa straně serveru . Vytvoření mu11ip1exního virtuá1ního soketu 90 je znázorněno v sedmesátém osmém bloku 333 na obr. 14 a je uk 11 i e č ň o v á n o p r o v á d ě n í m v i r t u ální operace vytvoření popsán ó v t o m 1 o rn a t e r i á In s odvoláním na obr . 16-1 . Sedmedesátý devátý blok 33.4 znázorňuje operaci odeslání informace přijaté od web browseru přes reálný šestý odpovídající soket 6Oba simplexní virtuální soket 70 po provedení zachycovací funkce na strano k 1 i e 111 a p r o k o m u n i k a c i v yt.vořen o u web browserem 1_0 . T a t o komunikace je řazena do fronty na multiplexní virtuální soket 90, a to provedením virtuální operace odeslání popisované v tomto materiálu s odvoláním na obr. 16-2. Zachycovací funkce na straně klienta po zařazení do fronty požadavku na multiplexní virtuální, soket 90 zarovná data ve frontě na multiplexním virtuálním soketu 90, jak je znázorněno v osmdesátém bloku 335 na obr. 14, a potom počká na událost na multiplexním virtuálním soketu, jak je n a z n a o o n o osm d e s á t ý m P r v n i m li 1 o k e m 336 · 1 u n k c e vir 1., u á 1 n i h o zarovnán í se uskutečňuje provedeπím virtu& 1ní f unkce zarovnání popsané v tomto materiálu vzhledem k obr. 17 7 i » která převezme data z inu I t i p.luxované virtuální soket o vé fronty a předá je na 1.6-4 r e á .1 n ý s o k e t 3 6 a . 0 P e a c e č e k ání m ů že bý t uskutečněna p r o v á d ě n í m virtuální funkce výběru popsané obr. 1.6-4. V tomto okamžiku - 41 - * · ···· • · • ·· • · • ♦ · ·· • · • • · • « · • « · »· • · • • · · • • ··· • • · • • · • • • • · • ♦ · • · · ♦ · • · zachytil zaohycovaoí modul 30 na straně klienta komunikaci vytvořenou web browserem 1.0 a tuto komunikaci přenesl na zachycovat;í modul 40. na straně serveru přes externí komunikační s po j 3 5.
Zpět k obr. 13, který znázorňuje vývojový diagram funkce manažeru soketu buď na zachycovacím modulu jtO na straně serveru, nebo na zachycovacím modulu 30 na straně klienta. Manažer reálných soket.ů v zachycovacím modulu 40 na straně serveru nebo manažer serverových soketů, znázorněný jako osmdesátý druhý blok 69 na obr. 12, provádí stejnou funkci jako manažer klientových soketů, znázorněný jako šedesátý třetí blok 68. vytváření prvního reálného soketu, znázorněného v šedesátém čtvrtém bloku 3 0 3. , zachycovat: í. modul 40 na straně serveru vytvoří "dobře známý port" pro příjem požadavků na sokety od zachycovacího modulu 30. na straně klienta spojeného se zachycovacím modulem .40. na straně serveru. Vyskyt.ne-1 j. se reálná událost na reálném odpovídajícím soketu 36b u zachycovacího modulu 40 na straně serveru, je tato událost prozkoumána, jak je naznačeno v bloku 305. V tomto případě je událostí příjem dat od reálného soketu 36a, proto se uplatní cesta od šedesátého šestého bloku 305 k osmdesátému třetímu bloku 320, znázorněná na obr. 13. Data přijatá na reálný odpovídající soket 36b jsou prozkoumána a v tomto konkrétním případě, protože se jedné o data vytvořená web browserem 10 odeslaná zachycovacím modulem 30. na straně klienta, musí být vytvořen nový virtuální soket v zachycovacím modulu 40 na straně serveru. To znamená, že se uplatní cesta od bloku 320 k bloku 321 na obr. 13. Manažer serverových soketů potom provede operace naznačené v blocích 321, 322. 323 a 324 na obr. 13. Manažer serverových soketů vytvoří další multiplexní virtuální soket 95, jak je naznačeno v osmdesátém čtvrtém bloku 321, zruší časovač aktivity tnu I t j plexní ho soketu, jak je naznačeno v osmdesátém pátém bloku 3 2.2, a iniciuje aplikaci zachycovací funkce na straně serveru, jak je naznačeno v bloku 322 na obr. 13 a znázorněno jako osmdesátý osmý blok 85. na obr. 12. Data přijatá na reálný 42 « t · • · ·· ···· • · • ·
• ·♦♦♦ t ♦ · · ·· ·· • ♦ · · ·· ·· soket jsou potom zařazena do fronty na dalš í mult iplexní v.i rtuální soket 95 a je signalizována virtuální událost.
Vytvoření zachycovací funkce na straně serveru, jak je znázorněno v osmdesátém šestém bloku 323, je označeno jako osmdesátý devátý blok 360 na obr. 15. Po vytvoření zachycovací funkce na straně serveru funkce přijme data z dalšího multiplexního virtuálního soketu 9.5, která byla odeslána od zachycovací ho modulu 30 na straně klienta a odpovídají, komunikaci vytvořené web browserem 10. Tato operace je označena jako devadeasátý blok 361 na obr. 15. Po přijetí dat od zachycovacího modulu 30 na straně klienta zpracuje zachycovací funkce na straně serveru data výše popsaným způsobem pro zachycovací modul .40 na s tra ně s e r v e ru . Provádění funkcí na straně server u je o z n a ceno v devadesátém prvním bloku 36.2 (viz příklad na obr. 5 a 9) . Po z pracován í i nf ormací vytvoř í zachycovací funkce na straně serveru pátý simplexní virtuální soket 75, a to prováděním virtuálního vytvoření, tj. operace, která je v tomto materiálu popisována vzhledem k obr. 16-1. Tato operace je naznačena devadesátým druhým blokem 363 na obr. 15. Zachycovací funkce na straně serveru potom odešle komunikaci vytvořenou web browserem 10 na pátý simp 1 exní virtuální soket 7_5 , jak je naznačeno v devadesátém třetím bloku 3.6.4 , uskutečněním virtuálního odeslání, tj. operace, která je v tomto materiálu popsána s odvoláním na obr. 16-2. Zachycovací funkce na straně serveru potom provede virtuální zarovnání dat ve frontě na dalším simplexním virtuálním soketu 75 pro další reálný soket 60c a počká na událost na pátém simplexním virtuálním soketu 75.. Operace virtuálního zarovnání je v tomto m a t e ri á1u popsána vzhledem k obr. 17-1. Operace odeslání a zarovnání jsou zobrazeny v blocích 364 a 365 na obr. 15. 0 p e r a c e ček á n í m ή že b ý t u s k uteč n ě na p r o v á d ě ním f u n k ce v i r i u á 1. n í h o vý 1)ěru popsaná na obr. 16-4. Jestliže zachycovací funkce na straně serveru vytvořila pátý simplexní virtuální soket 75. byl vytvořen rovněž odpovídající další reálný soket 60c. Odesláním komunikace vytvořené web browserem 1_0 na další simplexní -43 •t ···· • · · • · ♦ • t · • · · ·· ♦ • · « · • · • · • ·· ·· M · · · · • · · ·· • · ··· ♦ · • · ♦ · ··· ·· ·# virtuální soket .75. přenese zachycovací funkce na straně serveru komunikac i vytvořenou web browserem 10. na web server 20.
Když zachycovací modul 4j0 na straně serveru přijme odpověď od web serveru 20 na další reálný soket 60c, dojde k reálné události a manažer serverových soketň ukončí šedesátý šestý blok 30.2 na obr. 13 a prozkoumá událost, která nastala na dalším reálném soketu 60c. jak je naznačeno šedesátým sedmým blokem 305. V konkrétním případě se jedná o data pro existující virtuální soket a cestu od bloku 320 na blok 324 na obr. 13. Data přijatá na další reálný soket 60c jsou zařazena do fronty na pátém virtuálním soketu .7.5 a je signalizována virtuální událost. Je-li signalizována virtuální událost, ukončí zachycovací funkce na straně serveru devadesátý pátý blok 366 na obr. 15 a prozkoumá událost, jak je naznačeno devadeátým šestým blokem 370. Jestliže událostí je zavření soketu, nastane chybová podmínka a je jako odpověď zkonstruováno chybové hlášení, jak je naznačeno v devadesátém sedmém bloku 375 na obr. 15. Jestliže však je událostí příjem dat, uplatní se cesta od bloku 370 k devadesátému osmému bloku 371 a zachycovací funkce na straně serveru provede virtuální příjem, jak je v tomto materiálu popisováno s odvoláním na obr. 16-3, aby tak získala odpověď serveru z pátého simplexního virtuálního soketu 7j5, jak je zřejmé z bloku 371. Zachycovací funkce na straně serveru potom provede virtuální zavření dalšího simplexního virtuálního soketu 7.5, jak je naznačeno devadesátým devátým blokem 372 a v tomto materiálu popisováno s odvoláním na obr. 17-2, a zpracuje odpověď, jak je výše popisováno, pro zachycovací modul .40 na straně serveru, a jak je znázorněno ve stém bloku 373 (viz například obr. 6 a 10).
Je-li ukončovací cesta bloku 370 na obr. 15 chybovou cestou k devadesátému sedmému bloku 375 nebo datovou cestou k bloku 371. je ve sto prvním bloku 374 smazán pátý simplexní virtuální soket 75. Zachycovací funkce na straně serveru potom provede operaci 44 ·· ···· • · · • · · ·· ·
• · · ·« ··· ·· ·· ♦ · · · • · ·· • ♦♦·· · • · ♦ ·· «· virtuálního odeslání na další multiplexní virtuální soket 95 s cílem odeslat komunikaci vytvořenou web serverem na zachycovaní modul 3.0 na straně klienta, .jak je znázorněno ve sto třetím bloku 376. Zachycovaní funkce na straně serveru potom uskuteční operaci virtuálního zarovnání dat ve frontě v dalším multipiexním virtuálním soketu 95. Tyto operace jsou znázorněny ve sto čtvrtém bloku 377. Zachycovaní funkce na straně serveru potom provede operaci virtuálního zavření, při které zavře další multiplexní virtuální soket 95, jak je znázorněno ve sto pátém bloku 378 na obr. 155. Zachycovaní funkce na straně serveru nakonec smaže multiplexní virtuální soket a ukončí se, jak je znázorněno bloky 379 a 38 0..
Zachycovaní funkce na straně serveru provede operace virtuálního odeslání a zarovnání u dalšího multiplexního virtuálního soketu 95. Tímto se spustí události na reálném soketu 36a, přičemž manažer klientových soketu ukončí blok 302 a prozkoumá událost, jak je znázorněno v bloku 30 5 . a protože data by1a při jata na reá1ný soket 36a , bude použita cesta od bloku .3 0 5 k bloku .3 20 na obr. *13 a data budou zařazena do fronty na multiplexní virtuální soket 90.. Když tedy reálný soket 36a. přijme odpověď web serveru ,2.0 od reálného odpovídajícího soketu 36 b e x t e r n í k o m u n i k a č n í s p o j .3 5 , j s o u t a to data demultipl exová n a a poskytnuta na příslušný multiplexní virtuální soket. Příjem dat způsobí vznik virtuální události, která by měla být, jak je ukázáno osmdesátým sedmým blokem blokem 324 na obr. 13 a blokem 33 6 na obr. 14, ukončena a za»chycovací funkce na straně klienta b y m ě .1 a t u t o u d á 1 ost prozko u. mat, j a k j e z n á z o r n ě n o ve sto osm é m b i ok ii 3 4 0. na obr. 14. .Jestliže událost je odezva na uzavřený soket, uplatní se cesta od bloku .3.40 ke stode vátému bloku 345 na obr. 14 a za c hy oov ací ť u nk o e n a s t raně k1 i e nt a vytvoří o dpoveď chybové h o h1ášení a předá ji sto desátému bloku 344 na obr. 14. Pokud udá1ost jsou přijata data, což je právě uváděný pří k1ad, up latní -45 -45 • · · * · · • · • · · « · • · · · · • · · · · · • · · · · • · · Μ • Μ »· ·· « · · · • · · ·» • · ··· · · • · · · ··· ·· «* se cesta od bloku 340 ke sto jednáctému bloku 341 na obr. 14 a zachycovací funkce na straně klienta provede operaci virtuálního příjmu k přijetí odpovědi z multiplexního virtuálního soketu 90. Tato operace příjmu je znázorněna blokem 341 na obr. 14. Po přijetí dat z multiplexního virtuálního soketu 9.0 provede zachycovací funkce na straně klienta operaci virtuálního zavření a zavře multiplexní virtuální soket _90, jak je naznačeno sto dvanáctým blokem 342. Zachycovací funkce na straně klienta potom zpracuje odpověď výše popsaným způsobem pro zachycovací modul na straně klienta, jak je znázorněno ve sto třináctém bloku 343 (viz např. obr. 4 a 8).
Operace sto desátého bloku 344 jsou potom prováděny při použití kterékoli cesty k ukončení bloku 340. Zachycovací funkce na straně klienta smaže multiplexní virtuální soket, jak je naznačeno blokem 344, a potom provede operaci virtuálního odeslání. s cílem odeslat odpověď na browser 10 přes simplexní virtuální soket 7 0, jak je naznačeno sto patnáctým blokem 3_4_6. Po dokončení operace virtuálního odeslání provede zachycovací funkce na straně klienta operaci virtuálního zarovnání tak, aby zarovnala data ve frontě simplexního virtuálního soketu, jak je znázorněno sto šestnáctým blokem 347 pro reálný ěestý odpovídající soket 60jb, a potom provede operaci virtuálního zavření s cílem zavřít simplexní virtuální soket, jak je znázorněno v bloku sto sedmnáctým 348. Po zavření simplexního virtuálního soketu pro zachycovací funkci na straně klienta je smazán simplexní virtuální soket a zachycovací funkce na straně klienta se ukončí, jak je zřejmé z bloku 349 a 350 na obr. 14. Z poli ledu hodnocení stávajícího vynálezu, je tento popisován s ohledem na jeden konkrétní příklad vytvoření simplexního a multiplexního virtuálního soketu a zachycovacích funkcí na straně klienta a na straně serveru, avšak pluralita těchto funkcí může být vytvořena v rámci jednoho zachycovacího modulu 3.0 na straně klienta, respektive zachycovacího modulu 40 na straně 46 #· ···« ·«
»· ·· • · · · • · ·· • · · · · t ·· «· ··· s e ť v e r u . O b d o b n ě m ň ž e zachy c o v a o í m o d u 1 30. n a straně k I i e n t a a zaohycovaoí modu1 40 na straně serveru, podle vyná1ezu, vytvořit TCP/1P spojení mezi zachycovacím modulem .30. na straně k.1.j.enta a zachycovacím modu 1 em .40 na straně serveru a potom provádět mu J tiplex na pluralitě spojení TCP/IP komunikací vytvořených web browserem J O nebo web serverem 2.0, a to při u d r v. a η 1 s p o j e n í TCP/IP.
Zbývající funkce manažera klientových soketft a manažera serverových sokotů Lze nejlépe pochopit s použitím obr. 16-1 až 16-4 a obr. 17-1 a 17-2, které popisují operace prováděné zachycovacím modulem 30 na straně klienta a zachycovacím modulem 40 na straně serveru při uskutečnění operací. virtuálního vytváření, virtuálního odesílání, virtuálního příjmu, virtuálního výběru, virtuálního zarovnání nebo virtuálního zavření, jak je znázorněno vývojovými diagramy na obr. 14 a 15. Když se uskutečňu je ope race v irtuálního vy t; váření , jak je známo z b 1 oku 3 3 3 na obr·. 14 a b 1 oku 363. na obr. 15, začíná se od sto osmnáctého bloku 400 na obr. 16-1. Manažer soketů potom určí, zda je vyžadován reálný soket, .jak je znázorněno ve sto devanáctém bloku 405. Jestliže již reálný soket existuje, anebo při vytváření multiplexního virtuálního soketu, který má být připojen na stávající reálný soket, uplatní se cesta "No" bloku 405 a virtuální soket se spojí s reálným soketem, jak je zřejmé ze sto dvacátého bloku 409. Jestliže je však reálný soket zapotřebí, použije se potom cesta "Yes" bloku 405. Jak je zřejmé ze sto dvacátého prvního bloku 406, vytvoří se reálný soket. Reálný soket je potom přidán do seznamu událostí, jak je naznačeno ve sto dvacátém druhém bloku 408, pro potřeby monitorování, jak je reflektováno v bloku .302 na obr. 13. Po vytvoření reálného soketu a ustanovení spojení je virtuální soket připojen k reálnému soketu, jak je uvedeno v bloku 409, a dokončí se operace vyt v o ř o n í , j a k j e z ř e j mé ze s t o d v a c; á t é h o t ř e t í ho blok u 410 . Při P r o v á d ě n í ope ra c e virtuálního odeslání naznačené ·· ···· Μ ι • · · · · · · ♦ ♦ · · * · <· · · · · · ι • · · · · « *· · ·· «·· ·* * · · • · ··· · • · ·· ·· ·· ·· - 4 7 -ν blocích .134 a 34b na obr. 14 nebo blocích 364 a 376 na obr. 15 ?i3.čína;jí operace od sto dvacátého čtvrtého bloku 4 2 0 na obr. j 6-2. Do fronty virtuálního soketu jsou přidána data, jak je jjřejmé ze sto dvacátého pátého bloku 4.27, a potom se ukončí operace odesílání, jak je vidět ze sto dvaeátéhp šestého bloku
Operace virtuálního příjmu znázorněné v blocích 331 a 341 na obr. 14 a blocích 361 a 371 na obr. 15 jsou uskutečňovány prováděním operací začínajících od sto dvacátého sedmého bloku 430 na obr. 16-3. Jak je vidět ve sto dvacátém osmém bloku 435, je vyhodnocena virtuální soketová fronta, aby se stanovilo, zda jsou ve virtuální soketové frontě nějaká data. Jestliže se ve virtuální soketové frontě data vyskytují, uplatní se cesta “Yes" bloku 435 a tato data jsou vrácena na funkci nazvanou příjmová operace, jak je patrno ze sto dvacátého devátého bloku 436.
Jestliže ve virtuální soketové frontě nejsou žádná data, avšak soket není označen pro zavření, uplatní se cesta "No" rozhodovacího sto třicátého bloku 44.0 a nic se nevrátí, jak je zřejmé ze sto třicátého prvního bloku 4.41 . Jestliže však nejsou ve fron tě žádná data a soket je označen pro zavřeηí, p1atí cesta "Yes" bloku 440 a soket je označen jako zavřený, jak je zřejmé ze sto třicátého druhého bloku 44.2, a na operaci vyžadující příjem je vrácena informace, že je soket zavřený, jak je zřejmé ze sto t ř i o á t é h o t ř e t í h o b 1 o k u 4 4 3 . v, v o 1. e n é m
Operace virtuálního výběru vykonávaná v blocích 326 a 336 na obr. 14 a v bloku 3.66 na obr. 15 se uskutečňuje provedením operací, které začínají sto třicátým čtvrtým blokem 4 4 5 na obr. 16-4. Jak je zřejmé ze sto třicátého pátého b1 oku 446 , nejdříve je stanoveno, zda data nebo operace virtuálního zavření nejsou dosud na zvoleném virtuálním soketu vyřízená. V př í padě , že nejsou nevyřízená žádná data nebo virtuální zavření, uplatní se cesta 'No" bloku .446 a proces čeká na virtuální událost na virtuálním soketu, jak je znázorněno ve sto třicátém ·· ··«· • > • · • « • · • · ♦ · · • ♦ * • · · · • · · * ·· ·· ·· * 9 9 9 • · ·· * ··· · t • · · • ·· ·· 4 8 šok Lem bloku 447, a po přijetí takové událost i se ukončí, jak je znázorněno ve sto třicátém sedmém bloku 448. Jestliže však data a v i r 1. u á 1 n i z a v ř e n í j s o u d o s u d nevy ř í zená a čeká j í n a vy ř í zen í , č u k a j í n a z v o 1 e n é m v i r t u á 1 n 1 m soke t u , v i. r tuál n í událost s e j i ž vyskytla» a proto se uplatní cesta "Yes" bloku 446, proces se zakončí, jak je znázorněno v bloku 448.
Operace virtuálního zarovnání, jak je zřejmé z bloků 335 a 347 na obr. 14 a bloků 365 a 377 na obr. 15 se uskutečňuje provedením operací, které začínají sto třicátým osmým blokem 450 na obr . 17-1. Je-1 i operace v i rtuá1ního zar ovnání spuštěna, stanoví, zda jsou ve frontě virtuálního soketu nějaká data, která mají být zarovnána, jak je naznačeno v rozhodovacím sto třicátém devátém bloku 4.5 5. Jestliže ve virtuální soketové frontě nejsou žήdπá data, potom se operace zarovnání prostě ukoη6í a vrátí se do funkce, jež ji spustila, jak je zřejmé z větve "No" bloku 455. Jestliže však jsou ve frontě nějaká data, potom se uplatní cesta "Yes" bloku 45..5 a je určeno, zda virtuální soketová fronta jo pro muitiplexní soket, jak je patrno ze sto čtyřicátého bloku 460. Jedná-li se o muitiplexní soket, potom se soketové záhlaví, které se skládá ze tří byte dat odrážejících jednoznačný identifikátor pro soket a z objemu dat pro přenos, přidá do vyrovnávací paměti. (buf f eru) reálného soketu, jak je znázorněno ve sto čtyřicátém prvním bloku 4(651. V obou případech, jestliže se jedná o muitiplexní soket nebo simplexní soket, se data pro reálný soket potom přesunou do vyrovnávací paměti pro reálný soket, j a k j e ti azn a ceno v e s t o č t y řic á t ém dr u hém b 1 < > k u 462 . V případě, že vyrovnávací paměť reálného soketu je plná, uplatní se větev "Yes" sto čtyřicátého třetího bloku 465 a data se z vyrovnávací paměti pro reálný soket odešlou na tento reálný sok e t , , i ak j e n a zn a č en o ve s to č t y ř i c á t é m čtvrtém b1 o ku 466. Pokud však vyrovnávací paměť pro reálný soket není plná, platí cesta "No" b l oku 46 5. Virtuální zarovnávací funkce potom provede test s cílem určit, zda jsou ještě nějaká další data na případné další frontě inu 1.1 i p i exního vi rtuálního soketu, která by měla být ·· ···· • · ·· · ·· • · · ···· ···· • · · * · · ···· • · · · · i « ♦ ···« · • · · · · ♦ ··· ♦ · · ♦· ·»· ·· ·· - 49 -odeslána na reálný soket. Pokud odpověď zní ano, uplatní se cesta "Yes" sto čtyřicátého pátého bJoku 470 a data ve vyrovnávací paměti reálného soketu nejsou odeslána, dokud není operace virtuálního zarovnáváni znovu vyvolána, aby provedla zarovnání jedné z ostatních virtuálních soketových front. Pokud však nejsou již žádná další data nebo po přidání dat z ostatních mul t i p] exní ch virtuálních soketů, provede se operace bloku 466 a data ve vyrovnávací paměti reálného soketu jsou odeslána na reálný soket. Po tom všem se data ve virtuální soketové frontě odpovídající funkci, která volala operaci virtuálního zarovnávání, odešlou na reálný soket a operace virtuálního zarovnávání se ukončí, jak je znázorněno ve sto čtyřicátém šestém bloku 467.
Virtuální operace zavření znázorněná v blocích 342 a 348 na obr. 14 a blocích 372 a 378 na, obr. 15 se uskutečňuje provedením operací, které začínají sto čtyřicátým sedmým blokem 4.80 na obr. 17-2. Když je volána operace virtuálního zavření, nejdříve provede testy s cílem určit, zda se virtuální zavření týká mu 1 t.i plexního virtuálního soketu, jak je znázorněno ve sto čtyřicátém osmém bloku 485. Je-li to multiplexní virtuální soket, potom se uplatní cesta "Yes" bloku 485 a do virtuální soketové fronty se přidá indikátor operace "zavření". At’ již jde o virtuální zavření multiplexního virtuálního soketu či nikoli, operace virtuálního zavření zavolá operaci virtuálního zarovnávání, jak je znázorněno ve sto čtyřicátém devátém bloku 487 a potom provede odpojení od reálného soketu, jak je znázorněno ve sto padesátém bloku 488. Operace potom provede testy s cílem poznat, zda virtuální zavření se týká simplexního virtuálního soketu, jak je zřejmé ze sto padesátého prvního bloku .4.90; a pokud tomu tak není, uplatní se cesta "No" sto padesátého druhého bloku 495. Protože se zavření týká multip1exního virtuálního soketu, provedou se testy bloku 495 s cílem stanovit, zda se jedná o poslední multiplexní virtuální soket, a je-li tomu tak, nastaví se časovač multiplexní aktivity, jak je zřejmé zo - 50 ·· ···· • ♦ #♦ ·· - 50 ·· ···· • ♦ #♦ ·· » · » · a » ♦ ♦ » · · ·· · • · ♦ ι • · · · ··· a a • ♦ a • a ·· sto padesátého třetího bloku 496 Pokud se však nejedná 0 poslední multiplexní virtuální soket, potom se blok 496 přeskočí.
Zpět k bloku 49(). Jestliže se virtuální zavření týká simplexního virtuálního soketu, potom je příslušný reálný soket odstraněn ze seznamu událostí, jak je znázorněno ve sto padesátém čtvrtém bloku 49_1 a reálný soket je zavřen a smazán, jak je zřejmé ze sto padesátého pátého bloku 492. Ať již je soketem simplexní nebo multiplexní virtuální soket, je označen jako zavřený, v i z sto padesátý šestý blok 497 « a operace zavření se ukončí, viz sto padesátý sedmý b1 ok 498 .
Obr. 13 bude nyní popsán ve vztahu k obr. 16-1 až 16-4 a obr. 17—1 a 17-2. Když se vyskytne reálná událost, blok 302 na obr. 13 se ukončí a manažer soketů událost prozkoumá na základě toho, j a k byla tato událost generována. Jestliže byl u události překročen časový interval (timing) pro časovač aktivity mu 11iplexního soketu, který byl nastaven v bloku 496 na obr. 1 7-2, potom se uplatní cesta od bl oku 30 5 ke sto padesátému osmému bloku 3.12. na obr. 13. Jak je zřejmé z obr. 13, provede manažer soketů operace bloku 312. a sto padesátého devátého bloku .3.1.3. pro zavření multiplexního reálného soketu a smaže multiplexní reálný soket, který odpovídá soketu, jenž spojuje zachycovací modul 3.0 na straně klienta se zachycovacím modulem 40 na straně serveru. Manažer soketů potom vyčká na další reálnou událost. Tento časovač multip1exních událostí je resetován (nulován) vytvořením multiplexního virtuálního soketu, jak je vidět v bloku 3 2 2 .
Jest I i ž e událost vyskytující, se na reálném soketu je zavř ení reálného soketu, např. web server provádějící operaci zavření na sokolových spojeních mezi web serverem a zachycovacím modulem na straně serveru, potom se uplatní cesta od bloku 305 ke sto šesdesátému bloku 309 na obr. 13. Manažer soketů odstraní reálný • · ···· ♦ * ·· ·· ·» • · · · • ·
• · · • ♦ · • · ♦ ·· é soket ze seznamu reálných události, jak je zřejmé ze sto šedesátého prvního bloku 309 a odpojí virtuální soket nebo soke ty, v pří padě několika multi plexních soketů, od reálného šolce tu nebo soketů, jak je vidět z bloku 310. Manažer soketů potom označí virtuální soket pro uzavření a oznámí (signalizuje) virtuální událost. Tato operace je reflektována ve sto šedesátém druhém bloku 311 a jakmile jsou všechna data z virtuální soketové fronty odstraněna, bude virtuální soket zavřen. Po označení v irt u á1ní h o s o k e t u p r o zavření manažer soketů následně st a n o v í, zda jo nebo není reálný soket, který má být zavřen, simplexním soketem, jak je naznačeno v rozhodovacím sto šedesátém třetím bloku 315. Jestliže zavření reálného soketů se týká simplexního so k e t u, j e tento reálný soket zavřen a smazán, jak je z η ó z or něno ve sto šedestátóm čtvrtém bloku 31.6. Manažer soketů potom čeká na další reálnou událost, jak je patrné z bloku 302.
Není-li to simplexní reálný soket, jenž se má zavřít, potom se uplatní cest.a "No" bloku 315 a manažer soketů vyčká na následnou reálnou událost. MultIplexní reálný soket nebo soket spojůjící zachycovací modul 30. na straně klienta a zachycovací modul. 4 0 na straně serveru může být pouze zavřen s použitím časového hlídání ze strany časovače aktivity multiplexního soketů. To umožňuje údržbu spojení mezi zachycovacím modulem 30 na straně klienta a zachycovacím modulem 40. na straně serveru i poté, co proběhla poslední komunikace mezi moduly v rámci pro ij ži vat e1e speci f ikovaného předem stanovené ho času. V si tuaci 11 á s .1 o cl n 6 h o pož a d avku spojení od browser u 1.0. před vyp r š e n í m č a s o v é h o i n t e r v a .1 u u r 6 e n é ho časovačem aktiv! t y m u 11 i p 1 e x n í h o soketů by mohla být komunikace uskutečněna bez znovuustánovení s p o j e n í m e z i z a ohycovacím modulem 30. na straně klien t a a zachycovacím modulem 40. na straně serveru, a tak eliminována potfoba daí ších nároků v důsledku znovuustánovení takového s p o j o n í . 1'os I ed n í větev , kterou je nutné popsat u obr. 13, je v ě t c v, φφ φφφφ Φ · φφ φ φ Φ Φ ΦΦΦΦ ΦΦΦΦ ΦΦ φφφ φφφφ ΦΦ * Φ Φ Φ Φ Φφφφ φ φφ ΦΦΦ ΦΦΦ 5 2 φφ Φ ΦΦ ΦΦΦ ΦΦ ΦΦ k cl y η a s i a n o r e á I η ά u d a i o s t a t o u t o u d á 1 o s t í je příjem d a t n a, mu.11 i ].) 1 exn í r oá 1 ný soket nebo r eálné soke t y 36a nebo 3 6b na obr . 12. Jsou-li data přijata na mu 1tiplexní reálné sokety, jsou tato data prozkoumána a v případě, že zahrnují, indikátor operace zavření, podobně jako tomu bylo u virtuální fronty ve sto šedesátém pátém bloku 486 na obr. 17-2, potom se provede operace v i r I. u á 1 n í h o z a v ř e n i , a te d y p ouži je cesta od bio k u 320 k blok u 310. Manažer soketů odpojí od reálného soketu mult iplexní virtuální soket, označený v přijatých datech na reálný soket, viz blok 3.10, a potom označí virtuální soket pro "zavření" a signalizuje virtuální událost tak, jak je znázorněno v bloku 311. Protože zavření je vlastně zavření multiplexního virtuálního soketu, uplatní se cesta "No" bloku 315 a potom manažer soketů pooká na reá lnou udá1ost, jak je vidět v bioku 302.
Prostřednictvím provádění operací popsaných na obr. 13 až 17 konkrétní aspekt stávajícího vynálezu ustanovuje stálé spojení mezi prvním počítačem 5 a druhým počítačem .6 přes externí komunikační spoj 35. Toto stálé spojení je udržováno do doby, než vb o c h ny k orriun i kace vy t v oř ené web brows er em 1_0 j sou doko nč eny a p 111 r a i. i t a k o m u n i k a c í vy t vořenýoh web b r o w s e r e m JL 0. j e z a e h y o e n a a následně mult.ip.lexována na externí komunikační spoj 3j> v době. kdy je stá].6 spo jení udr žováno . Specif ický datový tok k i i e n i./se r v o r m ή ž e b ý t p a k d e m u 11 iplexován tak , aby se vytvoř i 1 a P1ura I ita dato v ý ch to k u ΗT TP a tato pluralita d a to v ý c h toků ΗT T P je předána na web server 2U. Stálé spojení je rovněž udržováno do d o k o n č o n í v šech komu n i k a c: í v y tvoř e ných web serverem 20 . P1 u r a i i t a k o m u n i. k a, c í v y 1, v o ř c n ý c h w e b serverem 2j0 j e zach y cen a a irm i t i p 1 exo vána na externí komunikační spoj 35. v době, kdy je s t á 1 o s p o j e n í u d r žováno . S p e o i f ický datový tok kli ent/server m ů š e b ý t p o t o m d e tn u 11 i p I. e x o v á n t a k , a b y s e v y tvoři 1 a p i u r a 1 i t a d a t o v ý c li t o k ů Η τ T P a t a t. o p 1 u ral ita datových tok ů HTTP se p ř e d a 1 a na web server 2(),
Ve výkresové dokumentaci i příkladech jsou ubvedena typická ♦ · · · · · • * • · «I · - 5 3 * · • · • + • * • · % » · · • · · · » · · • · · • t · · • · · · • · · · p ř <1 d :n o s t n í p r o vod e n í v y n á 1 e z u , a p ř e s 1; ože jso u p o u ž i ty spéci f i c k é t,erτο í ny , j sou použ i ty pouz e v generickém a popisném smys .1.υ slova a n i k o 1 i p r o l i č. o. 1 y u v o cl o n ý o h n á rok ů . o m e z o; n í li o z s a h v y n á 1 ezu vyp 1 ý v á z d á 1 e
JUDr. Petr KALENSKY advokát
SPOLEČNÁ ADVOKÁTNÍ KANCELÁŘ VŠETEČKA ZELtNV ŠVOPČÍK KALENSKÝ A PARTNEŘI 120 00 Praha 2, Hálkova2 Česká republika
Claims (7)
- • I ··· ·1>\J 3£ko- ψ - 5 4 P Λ ΐ E N T O V E NÁROKY Znásob redukce dat, přenášených přes komunikační spoj z první a p 1 .i k a o e r e z i d e n t η í n a p r v n í m počítači. ( 5 ) a také na dr u h o u aplikaci reziiientní na druhém počítači. ( 6 ) , přičemž se data P ř e n á š i p ř e s e x t. e r n í k omun i k a ční spoj (35) z p r v n í h o oočí. tače (5) na drn hý počítač (6), vyznačující se tím, že se ukládá datový tok z první aplikace, který se má p o s k v tno u t. d r 11 h é a p i i k a c i v o d p o v ědi na požad a v e k t é t o d r u h é a a p 1 i k a o o , d. o c a c h e p a m ě t i. rez i d e n t η í n a. p r v n í m p o 6 í t a č i ( 5 ) , p ř i čemž s e v y tvoří serverový bázový cache z á η i s , ukládá se datový tok, který se má být poskytnout druhé aplikaci v odpovědi na požadavek od této druhé aplikace, do cache pamč i; i. r e z i den tη í na druhém poč í tač i ( 6 ) , při. čem ž s e v ,v i-, v o ř í k .1 i e n t ň v b á z o v ý c aehe zápis, vyhodnotí se požadavky od druhé ap L ikace, přičemž se s t a n o v í , z d a e x i s t u ,i e k 1 i ent u v bázový cache zápis o d p o v í d a .i í e í z a c h y c e n o m u p o ž a <1 avku t a k , že s e n o s k y t n e k .1 i e n t o v a b á z o v á ť o r m a , zachytí se požadavky od druhé aplikace, přičemž se stanoví, zda ex istuje serverový bázový cache záp is o d. p o v í d a j í c í z a c h y o e n é m u pož a d a v k u t a k , že se p o s k v t n o s e r ver o v á b á. z o v á f o r m a , z a (.· h y t í. s e d a t o v ý t o k , odpovíd a j ící odpovědi vytvořené první aplikací, v odpovědi na zachycený požadavek od druhé aη I i k ace u řed o d es lánim o dpo vě d i n a externí komun i k a č ní s !> O .! { 3 Γ) ) , norovnaj í se zachycené odpovědi se serverovou bázovon f o řinou, p ř i č o tu ž se p o s k ytnou rozd í. 1 o v á data , odpo v í d a j í c í r o z d ί I. u m e z i za c h v o e n o u o dpověd í a s e r v e r o v o u b á zovou formou , odešlou se rozdílová data na druhý počítač (6) přes externí komunikační spoj (35), e x t e r n :í. vvžádají se rozdílová data, přenášená přes ······ ·♦ · ·« |· Φ · · · · Μ · I « · ··· · · · «··· • · · · · · · * ···· · ··» ··· · « « • V · *· ··· ·· »· komunikační spoj (35) a odesílaná prvním počítačem (5), rekonstruuje se datový tok odpovědi, odpovídající koinu n ikac i. od první aplikace, ze specifického datového t o ku k 1 i e n t / s e r v e r , p ř i ,j a, t ého přes externí koinun i k ačn í spoj (35), sloučí se klientovy bázové formy s rozdílovými da t y p ř i j a t ý m i př e s e x t e r n i k omu nikač n í s po j ( 3 5 ) , př í č e m ž s c. v y I; v o ř í d a t o v ý t o k o d p o v ě d i , od p o v í d a j í cí zachyce n é odpověd i, poskytuje se rekonstruovaný datový tok, odpovídající zaohy oené odpovědi , druhé ap1 ikao i. Způsob podle nároku 1, vyznačující se tím, že dále se stanoví, zda je serverová bázová forma identická klientově bázové formě, p ř i o d e s i ání se přenáší serverové bázové formy a r ozd í1 o v á data na druhý počítač (6) přes externí komunikační spoj (35) , a při. stanovení se určí, zda serverová bázová forma n en í i d ent i c k á k .1 i ent.ově bázové formě, p ři re k o n s t r u k ci se rek o nstruuj e zachyce ný d a t o v ý tok odpovědi, odpovídající odpovědi od první ap1 i kace, sloučením serverové bázové formy, přijaté přes externí komunikační spoj (35), s rozdílovými daty přijatými přes externí komunikační spoj (35) , přičemž se vytvoří datový tok, od poví da j í c í zachycené odpo v ěd i, aktu a1 i z π i í se k1 i e nt o v y bá z o vé formy, o d p o v íd a j í c í zachycenému požadavku , a uloží se přijaté serverové bázové formy jako klientův bázový cache zápis, odpovídající zachyconému požadavku. Způsob podle nároku 1, vyznačující se tím, že dále se stanoví, zda je rozdíl mezi serverovou bázovou formou a zachycenou odpovědí větší než předem definovaný rozdílový p r á h , aktualizuje se serverová bázová forma, odpovídající, zachycenému požadavku, a to uložením zachyceného datového • I Μ·· • * ♦ • · «· 5 6* t • · ·« « · • · · · • · «· • · ·toku odpovědi, přijatého přes první aplikaci, jako serverového bázového cache zápisu, odpovídajícího zachycenému požadavku v případě, že rozdíl mezi serverovou bázovou formou a zachycenou odpovědí je větší než předem d e f i n o v a ný ro z d í1 o v ý p r á h , přičemž porovnání a odesílání se týkají využití aktualizované serverové bázové formy. 1. Způsob podle nároku 1, vyznačující se tím, že dále se udržuje pluralita serverových bázových cache zápisů, které odpovídají požadavku od druhé aplikace, přičemž se při zachycení stanoví, zda existuje pluralita serverových bázových cache zápisů, odpovídající požadavku od druhé aplikace tak, že se poskytne pluralita s e r verových bázových forem, stanoví se, zda je jedna z plurality serverových bázových forem identická klientově bázové formě, při porovnání se využívá jedna z plurality serverových bázových forem, jež je identická klientově bázové formě, pokud se uvedeným stanovením určí, že jedna pluralita serverových bázových forem je identická klientově bázové f o r m ě .
- 5. Způsob podle nároku 1, vyznačující se tím, že dále se aktualizuje serverový cache zápis o datový tok od první ap1ikace v odpovědi na požadavek druhé aplikace, udržuje se pluralita sad rozdílových dat, které odpovídají p o ž a d a v k u o d druhé aplikace a které reprezentují rozdíly mezi následnými serverovými cache zápisy, přičemž se poskytují, archivační rozdílová data, úd r ž uj e se p1ura1 i ta CRC zápisů, přičemž každé u vάd ěné pluralitě CRC zápisů je přiřazena jedna, již uváděná pluralita sad rozdílových dat, a jednoznačná identifikace serverové bázové formy, z níž byla uvedená sada rozdílových dat odvozena, - 57 ·· ··♦· • · ♦ · ·· • · · ♦ ··· * · « ···« • · ♦ · · · 4 « ·♦·· ι ··· ··· · « « • Ψ 4 44 44« 44 44 při zachycení se stanoví, zda existuje pluralita sad rozdílových dat a CRC, které odpovídají požadavku od druhé a p 1 i k a c e , stanoví se, zda jedna ze zmíněných pluralit CRC odpovídá s e rverové bázové formě, kt e r á j e iden ti c k á kli e η t o v ě bázové formě, při odeslání se odesílají archivační rozdílová data, odpovídající CRC, který odpovídá klientově bázové formě, přičemž následné sady archivačních rozdílových dat a rozdílová data jsou vypočítávána uvedeným porovnáním s druhým počítačem (6) přes externí komunikační spoj (35), při rekonstrukce se rekonstruuje datový tok odpovědi, odpovídající komunikaci od první aplikace, z d a t o v é h o toku přijatého přes externí komunikační spoj pomocí následného slučování klientovy bázové formy a rozdílových dat, při jatých přes externí komunikační spoj, přičemž se vytvoří datový tok odpovědi, odpovídající zachycené od p o věd i, aktualizuje se klientův cache zápis, odpovídajícího požadavku od druhé aplikace, o rekonstruovaný datový tok.
- 6. Způsob podle nároku i, vyznačující se tím, že první aplikace zahrnuje web server (Z 0 ) a d r uhá aplikace z a h r n uj e we b b r owser (10).
- 7. Způsob podle nároku 1, vyznačující se tím, že externí komunikační spojem (35) zahrnuje bezdrátový komunikační spoj.
- 8. Způsob podle nároku 6, vyznačující se tím, že požadavek od web browseru (10) zahrnuje požadavek CGI.
- 9 . Zař í z en í pr o redukc i. objemu dat, přenášených z první ap I i kace r e z i d e n t n ;í n a. p r v n í rn počí t a č i ( 5 ) n a druhou apl ika c i a re z i den tη í na druhém počítači (6), v odpovědi na požadavek od d r u hé ap1 i kace, přičemž d at a jsou přenášena přes externí • · ···· ·· • • · ·· • · • • · ·· • 1 • · * · « • · • • · • · • ♦ ♦ • · ♦ • • ··· • · • · • • ♦ • • • · ·· • • · *♦ - 5 8 - komunikační spoj (35) z prvního počítače (5) na druhý počítač (6), vyznačující se tím, že sestává z prostředků pro uložení datového toku z první aplikace, který se má poskytnut druhé aplikaci v odpovědi na požadavek této druhé aplikace, do cache paměti rezidentní na prvním počítači (5) pro vytvoření serverového bázového c a c h e z á p i s u , prostředků pro uložení datového toku, který poskytnut druhé aplikaci v odpovědi na požadavek druhé aplikace, do cache paměti rezidentní na počítači (6) pro účelem vytvoření klientova bázového požadavků o d d ruh é k1 i e n t ů v bázový požadavku pro požadavků od druhé serverový bázový cache z á p i, s u , p r o s t ř e d k ή pro vyhodnocení s t a, n o v e n í , z d a e x i s t u, j e o d p o v í d a j í o í z a c ii y e e n é m u k1 ie nto v y b á z o v é formy, p r o s t f e d k ú p r o z a c h y c e n í s t a n o ven í , z da exi stu j e odpovídáj í cí zachycenému serverové bázové formy. má b ý t od této d r u h é m cache aplikace p ro cache zá pi s poskytnut í aplikace pro zápis požadavku pro poskytnutí prostředků pro zachycení datového toku, odpovídajícího odpovědi vytvořené první aplikací v odpovědi na zachycený požadavek od druhé aplikace, před odesláním odpovědi na e x terní komu n i kační spoj (35), prostředků pro porovnání zachycené odpovědi se serverovou bázovou formou pro poskytnotí rozdílových dat, odpovídajících rozdílu mezi zachycenou odpovědí a serverovou bázovou formou, prostředků pro odesláni rozdílových dat na druhý počítač (fi) p ř e s ex te rn í k o m un ik ač ní s p o j (3 5), prostředky pro vyžádání rozdílových dat, přenášených přes exter n í komυnikacní spo j (35) a odesílaných prvníra p o č í t a č e m ( 5 ) , prostředků pro rekonstrukci datového toku odpovědi, o dp o v íd a j í c í c h ko m un ikaci od p rvní a p1ikace , z e ·· ···♦ ·· ·♦ * ·· • 4 · · · f« · « I · t t « ··· ···· • ♦ ♦ · · · · · »··♦ · • « · · · · · ♦ ♦ ·· · ·· ··· ·· ·· 59 - speo i f i. ckého datového toku k J. ient/server , př i jatého přes externí komunikační spoj (35), sloučením klientovy bázové formy s rozdílovými daty přijatými přes externí komunikační spoj (35) pro vytvoření datového tok odpovědi, odpovídající zachycené odpovědi a prostředků pro poskytnutí rekonstruovaného datového toku, odpovídajícího zachycené odpovědi druhé aplikaci.
- 10. Počítačový programový produkt pro redukci objemu dat, přenášených z první aplikace rezidentní na prvním počítači (5) na druhou aplikaci rezidentní na druhém počítači (6) v odpovědi na požadavek od druhé ap1ikace, přičemž data jsou p ř e n á š e n a př e s e x t e rní komunikační spoj (35) z prvního počítače (5) na druhý počítač (6), vyznačující se tím, že zahrnuje počítačem čitelné paměťové médium, mající začleněny počítačem čitelné programové kódové prostředky v tomto médiu, přičemž tyto počítačem čitelné programové kódové prostředky z a h r n u j í : počítačem čitelné programové kódové prostředky pro uložení datového toku z první aplikace, který má být poskytnut, druhé aplikaci v odpovědi na požadavek této druhé aplikace, do cache paměti rezidentní na prvním počítači (5) pro vytvoření serverového bázového cache zápisu, počítačem čitelné programové kódové prostředky pro uložení datového toku, který má být poskytnut druhé aplikaci v a odpovědi na požadavek od této druhé aplikace, do cache paměti rezidentní na druhém počítači (6) pro vytvořeni k1 i e nt o v a bázového cache zápisu, počítačem čitelné programové kódové prostředky pro vyhodnocen í požadavků od druhé aplikace pro stanovéní, zda o. x i s t ii j e klientův b á z o v ý cache zápis, odpovídá j í c í z achycenému požadavku pro poskytnutí klientovy bázové f o r m y , počítačem čitelné programové kódové prostředky pro zachycení požadavků od druhé aplikace pro stanovení, zda e x í s t u j e serv e rovy b á z o v y c ao h e z á pis o cl p o v í cl a j í c í zachycenému požadavku pro poskytnutí serverové bázové f o r m y , počítačem čitelné programové kódové prostředky pro zachycení datového toku, odpovídajícího odpovědi vytvořené první aplikací v odpovědi na zachycený požadavek od druhé aplikace, před odesláním odpovědi na externí komunikační spoj (35), počí tačem č:i telné Ρrogramové kódové prostředky pro porovnání zachycené odpovědi se serverovou bázovou formou pro poskytnutí rozdí1ových dat, odpovídaj ících rozdí1u mezi zachycenou odpovědí a serverovou bázovou formou, počítačem čitelné programové kódové prostředky pro odesláni rozdílových dat na druhý počítač (6) přes externí k o m ii n i k a č η í spoj (35), počítačem čitelné programové kódové prostředky pro vyžádání rozdílových dat, přenášených přes externí komunikační spoj (35) a odesílaných prvním počítačem (5), počítačem čitelné programové kódové prostředky pro r e k o n s t r u k c i d a t ového t o k u odpovědi , odp o v í d a j í o í. komunikaci od první aplikace, ze specifického datového i oku klient/server, přijatého přes externí komunikační spoj sloučením klientovy bázové formy s rozdílovými daty pi i.ja byTíi i pi es extei ni komunika,cni spo j (35) pro vytvořen i dat o ve li o loku odpo věa i , odpovídajícímu zachycené odpovědi. Po*'1 tácem čitelné programové kódové prostředky pro poskytnuti rekonstruovaného datového toku, odpovídajícího zachycené odpovědi, druhé aplikaci. advokát JUDr. Petr KALENSKYSPOLEČNÁ ADVOKÁTNÍ KANCELÁŘ VŠETEČKA ZEltivY SVOROÍK KALENSKÝ A PARTNEŘI 120 00 Praha 2, Hájkova 2 Česká republika
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/601,903 US5859971A (en) | 1996-02-15 | 1996-02-15 | Differencing client/server communication system for use with CGI forms |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CZ354097A3 true CZ354097A3 (cs) | 1998-03-18 |
| CZ289259B6 CZ289259B6 (cs) | 2001-12-12 |
Family
ID=24409216
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CZ19973540A CZ289259B6 (cs) | 1996-02-15 | 1996-07-11 | Způsob redukce dat, zařízení a počítačový programový produkt k jeho provádění |
Country Status (15)
| Country | Link |
|---|---|
| US (1) | US5859971A (cs) |
| EP (1) | EP0823171B1 (cs) |
| JP (1) | JP3491011B2 (cs) |
| KR (1) | KR100295730B1 (cs) |
| CN (1) | CN1167237C (cs) |
| AT (1) | ATE201946T1 (cs) |
| CA (1) | CA2218187C (cs) |
| CZ (1) | CZ289259B6 (cs) |
| DE (1) | DE69613225T2 (cs) |
| ES (1) | ES2159037T3 (cs) |
| HU (1) | HU227369B1 (cs) |
| MY (1) | MY120208A (cs) |
| PL (1) | PL180619B1 (cs) |
| TW (1) | TW299544B (cs) |
| WO (1) | WO1997030539A1 (cs) |
Families Citing this family (86)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5754774A (en) * | 1996-02-15 | 1998-05-19 | International Business Machine Corp. | Client/server communication system |
| US6194992B1 (en) * | 1997-04-24 | 2001-02-27 | Nomadix, Llc | Mobile web |
| 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 |
| US7266526B1 (en) * | 1996-11-27 | 2007-09-04 | Diebold, Incorporated | Automated banking machine system with multiple browsers |
| US6901425B1 (en) | 1996-12-23 | 2005-05-31 | International Business Machines Corporation | Computer apparatus and method including a disconnect mechanism for communicating between software applications and computers on the world-wide web |
| US6144990A (en) * | 1996-12-23 | 2000-11-07 | International Business Machines Corporation | Computer apparatus and method for communicating between software applications and computers on the world-wide web using universal variable handling |
| US6845505B1 (en) | 1997-02-03 | 2005-01-18 | Oracle International Corporation | Web request broker controlling multiple processes |
| US6710786B1 (en) | 1997-02-03 | 2004-03-23 | Oracle International Corporation | Method and apparatus for incorporating state information into a URL |
| US6247056B1 (en) | 1997-02-03 | 2001-06-12 | Oracle Corporation | Method and apparatus for handling client request with a distributed web application server |
| US6026404A (en) * | 1997-02-03 | 2000-02-15 | Oracle Corporation | Method and system for executing and operation in a distributed environment |
| US6225995B1 (en) | 1997-10-31 | 2001-05-01 | Oracle Corporaton | Method and apparatus for incorporating state information into a URL |
| US6182122B1 (en) * | 1997-03-26 | 2001-01-30 | International Business Machines Corporation | Precaching data at an intermediate server based on historical data requests by users of the intermediate server |
| US7103794B2 (en) | 1998-06-08 | 2006-09-05 | Cacheflow, Inc. | Network object cache engine |
| US6070184A (en) * | 1997-08-28 | 2000-05-30 | International Business Machines Corporation | Server-side asynchronous form management |
| US6035324A (en) * | 1997-08-28 | 2000-03-07 | International Business Machines Corporation | Client-side asynchronous form management |
| US6085193A (en) * | 1997-09-29 | 2000-07-04 | International Business Machines Corporation | Method and system for dynamically prefetching information via a server hierarchy |
| US6393526B1 (en) | 1997-10-28 | 2002-05-21 | Cache Plan, Inc. | Shared cache parsing and pre-fetch |
| US6334114B1 (en) | 1997-10-31 | 2001-12-25 | Oracle Corporation | Method and apparatus for performing transactions in a stateless web environment which supports a declarative paradigm |
| FR2774241B1 (fr) * | 1998-01-23 | 2000-02-25 | Sagem | Systeme de teleinformation pour un site d'exploitation de donnees et terminal de restitution de donnees d'un tel systeme |
| US6272534B1 (en) * | 1998-03-04 | 2001-08-07 | Storage Technology Corporation | Method and system for efficiently storing web pages for quick downloading at a remote device |
| US7007072B1 (en) * | 1999-07-27 | 2006-02-28 | Storage Technology Corporation | Method and system for efficiently storing web pages for quick downloading at a remote device |
| AUPP252798A0 (en) * | 1998-03-24 | 1998-04-23 | Griffits, John Philip | Enhanced trusted systems processing |
| US6170013B1 (en) * | 1998-03-27 | 2001-01-02 | Nortel Networks Limited | Method and apparatus for controlling access to network information sources |
| US6148340A (en) * | 1998-04-30 | 2000-11-14 | International Business Machines Corporation | Method and system for differencing container files |
| US6427187B2 (en) | 1998-07-31 | 2002-07-30 | Cache Flow, Inc. | Multiple cache communication |
| US6397253B1 (en) | 1998-10-06 | 2002-05-28 | Bull Hn Information Systems Inc. | Method and system for providing high performance Web browser and server communications |
| US6574239B1 (en) * | 1998-10-07 | 2003-06-03 | Eric Morgan Dowling | Virtual connection of a remote unit to a server |
| US8713641B1 (en) | 1998-12-08 | 2014-04-29 | Nomadix, Inc. | Systems and methods for authorizing, authenticating and accounting users having transparent computer access to a network using a gateway device |
| US7194554B1 (en) | 1998-12-08 | 2007-03-20 | Nomadix, Inc. | Systems and methods for providing dynamic network authorization authentication and accounting |
| US8266266B2 (en) | 1998-12-08 | 2012-09-11 | Nomadix, Inc. | Systems and methods for providing dynamic network authorization, authentication and accounting |
| GB2339516B (en) * | 1999-04-06 | 2000-07-05 | Iesearch Limited | An inter-computer communications apparatus |
| US6253198B1 (en) * | 1999-05-11 | 2001-06-26 | Search Mechanics, Inc. | Process for maintaining ongoing registration for pages on a given search engine |
| US7908602B2 (en) | 1999-06-30 | 2011-03-15 | Blackboard Inc. | Internet-based education support system, method and medium providing security attributes in modular, extensible components |
| US6988138B1 (en) | 1999-06-30 | 2006-01-17 | Blackboard Inc. | Internet-based education support system and methods |
| 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 |
| US6356933B2 (en) * | 1999-09-07 | 2002-03-12 | Citrix Systems, Inc. | Methods and apparatus for efficiently transmitting interactive application data between a client and a server using markup language |
| US6721780B1 (en) * | 1999-11-09 | 2004-04-13 | Fireclick, Inc. | Predictive pre-download of network objects |
| US6324568B1 (en) * | 1999-11-30 | 2001-11-27 | Siebel Systems, Inc. | Method and system for distributing objects over a network |
| US6374248B1 (en) * | 1999-12-02 | 2002-04-16 | Sun Microsystems, Inc. | Method and apparatus for providing local path I/O in a distributed file system |
| US6983315B1 (en) | 2000-01-18 | 2006-01-03 | Wrq, Inc. | Applet embedded cross-platform caching |
| CA2398838A1 (en) * | 2000-03-01 | 2001-09-07 | Computer Associates Think, Inc. | Method and system for updating an archive of a computer file |
| US7028251B2 (en) * | 2000-03-02 | 2006-04-11 | Iora, Ltd. | System and method for reducing the size of data difference representations |
| US6990526B1 (en) * | 2000-05-22 | 2006-01-24 | Pointred Technologies, Inc. | Method and apparatus for web caching |
| JP4282207B2 (ja) * | 2000-05-31 | 2009-06-17 | 日本電気株式会社 | サーバ装置、クライアント装置、クライアントサーバ通信システム及びそれらに用いるサーバ特定方式 |
| US6941351B2 (en) * | 2000-07-11 | 2005-09-06 | Microsoft Corporation | Application program caching |
| US6839737B1 (en) | 2000-07-19 | 2005-01-04 | Neoplanet, Inc. | Messaging system for indicating status of a sender of electronic mail and method and computer program product therefor |
| US7529750B2 (en) * | 2000-08-11 | 2009-05-05 | International Business Machines Corporation | Accessing information on a network |
| US7571217B1 (en) | 2000-08-16 | 2009-08-04 | Parallel Networks, Llc | Method and system for uniform resource locator transformation |
| US7346842B1 (en) * | 2000-11-02 | 2008-03-18 | Citrix Systems, Inc. | Methods and apparatus for incorporating a partial page on a client |
| WO2002063504A2 (en) * | 2000-11-02 | 2002-08-15 | Citrix Systems, Inc. | Methods and apparatus for augmenting page generation code to effect partial page regeneration |
| US7051084B1 (en) | 2000-11-02 | 2006-05-23 | Citrix Systems, Inc. | Methods and apparatus for regenerating and transmitting a partial page |
| US7194743B2 (en) * | 2000-12-12 | 2007-03-20 | Citrix Systems, Inc. | Methods and apparatus for communicating changes between a user interface and an executing application using property paths |
| US7269784B1 (en) | 2001-01-22 | 2007-09-11 | Kasriel Stephane | Server-originated differential caching |
| US6912591B2 (en) * | 2001-05-02 | 2005-06-28 | Science Application International Corporation | System and method for patch enabled data transmissions |
| US7185063B1 (en) * | 2001-06-22 | 2007-02-27 | Digital River, Inc. | Content delivery network using differential caching |
| US20020198956A1 (en) * | 2001-06-25 | 2002-12-26 | International Business Machines Corporation | Method and apparatus for managing a cache |
| US7092997B1 (en) | 2001-08-06 | 2006-08-15 | Digital River, Inc. | Template identification with differential caching |
| US7188214B1 (en) | 2001-08-07 | 2007-03-06 | Digital River, Inc. | Efficient compression using differential caching |
| US7305381B1 (en) | 2001-09-14 | 2007-12-04 | Ricoh Co., Ltd | Asynchronous unconscious retrieval in a network of information appliances |
| US7375835B1 (en) | 2001-10-29 | 2008-05-20 | Ricoh Co., Ltd. | E-mail transmission of print-ready documents |
| JP2003177992A (ja) * | 2001-12-10 | 2003-06-27 | Seiko Epson Corp | 差分通信システム、差分通信装置及び差分通信プログラム、並びに差分通信方法 |
| US7296051B1 (en) | 2002-02-19 | 2007-11-13 | Digital River, Inc. | Predictive predownload of templates with delta encoding |
| US7487261B1 (en) | 2002-02-22 | 2009-02-03 | Digital River, Inc. | Delta caching service |
| US7111038B2 (en) * | 2002-04-03 | 2006-09-19 | International Business Machines Corporation | Enhancing application server performance by relocating performance-degrading processing |
| US7428578B1 (en) * | 2002-07-02 | 2008-09-23 | Ricoh Co., Ltd | Remotely initiated document transmission |
| EP1664992A4 (en) * | 2003-08-15 | 2010-05-19 | Blackboard Inc | CONTENT SYSTEM AND ASSOCIATED METHODS |
| US7472254B2 (en) * | 2003-10-10 | 2008-12-30 | Iora, Ltd. | Systems and methods for modifying a set of data objects |
| US7203708B2 (en) * | 2003-11-06 | 2007-04-10 | Microsoft Corporation | Optimizing file replication using binary comparisons |
| US8010670B2 (en) * | 2003-12-23 | 2011-08-30 | Slipstream Data Inc. | Meta-data based method for local cache utilization |
| JP4745839B2 (ja) | 2005-01-28 | 2011-08-10 | 富士通株式会社 | データ転送システム、送信プログラム、受信プログラム及びデータ送信方法 |
| US8326659B2 (en) * | 2005-04-12 | 2012-12-04 | Blackboard Inc. | Method and system for assessment within a multi-level organization |
| JP2007128371A (ja) * | 2005-11-04 | 2007-05-24 | Fujitsu Ltd | コンテンツ検索システム |
| US7924884B2 (en) * | 2005-12-20 | 2011-04-12 | Citrix Systems, Inc. | Performance logging using relative differentials and skip recording |
| US8493858B2 (en) | 2006-08-22 | 2013-07-23 | Citrix Systems, Inc | Systems and methods for providing dynamic connection spillover among virtual servers |
| US8312120B2 (en) * | 2006-08-22 | 2012-11-13 | Citrix Systems, Inc. | Systems and methods for providing dynamic spillover of virtual servers based on bandwidth |
| WO2008138008A1 (en) * | 2007-05-08 | 2008-11-13 | Riverbed Technology, Inc | A hybrid segment-oriented file server and wan accelerator |
| TW201009698A (en) * | 2008-08-19 | 2010-03-01 | Arcadyan Technology Corp | Method for improving the accessing efficiency of embedded web page |
| US20100131617A1 (en) * | 2008-11-25 | 2010-05-27 | John Osborne | Method and system for differential transmission of web page structures |
| EP2502402A1 (en) * | 2009-11-20 | 2012-09-26 | Alcatel Lucent | Expediting the distribution of data files between a server and a set of clients |
| US10142157B2 (en) | 2010-06-10 | 2018-11-27 | Blackberry Limited | Method and system for reducing transmission of redundant data |
| US8495019B2 (en) | 2011-03-08 | 2013-07-23 | Ca, Inc. | System and method for providing assured recovery and replication |
| US9832095B2 (en) * | 2011-12-14 | 2017-11-28 | Seven Networks, Llc | Operation modes for mobile traffic optimization and concurrent management of optimized and non-optimized traffic |
| US8606973B1 (en) * | 2012-07-05 | 2013-12-10 | International Business Machines Corporation | Managing monitored conditions in adaptors in a multi-adaptor system |
| JP6212944B2 (ja) * | 2013-05-14 | 2017-10-18 | 日本電気株式会社 | 通信システム、プロキシサーバ、通信方法およびプログラム |
| CN112333787B (zh) * | 2020-11-13 | 2023-09-12 | Oppo广东移动通信有限公司 | 数据传输方法、装置、存储介质、终端及网络接入点设备 |
| US11968417B2 (en) * | 2021-12-30 | 2024-04-23 | Comcast Cable Communications, Llc | Systems, methods, and apparatuses for buffer management |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5473772A (en) * | 1991-04-02 | 1995-12-05 | International Business Machines Corporation | Automatic update of static and dynamic files at a remote network node in response to calls issued by or for application programs |
| US5193162A (en) * | 1989-11-06 | 1993-03-09 | Unisys Corporation | Cache memory with data compaction for use in the audit trail of a data processing system having record locking capabilities |
| US5241625A (en) * | 1990-11-27 | 1993-08-31 | Farallon Computing, Inc. | Screen image sharing among heterogeneous computers |
| US5611038A (en) * | 1991-04-17 | 1997-03-11 | Shaw; Venson M. | Audio/video transceiver provided with a device for reconfiguration of incompatibly received or transmitted video and audio information |
| JPH06324928A (ja) * | 1993-05-14 | 1994-11-25 | Mitsubishi Electric Corp | ログ生成装置とファイルの異なるバージョンの調停のための装置及び異なる場所にあるコンピュータファイルの異なるバージョンを調停するための装置 |
| US5446888A (en) * | 1994-01-14 | 1995-08-29 | Pyne; Charles F. | Remote file transfer method and apparatus |
| US5574906A (en) * | 1994-10-24 | 1996-11-12 | International Business Machines Corporation | System and method for reducing storage requirement in backup subsystems utilizing segmented compression and differencing |
-
1996
- 1996-02-15 US US08/601,903 patent/US5859971A/en not_active Expired - Lifetime
- 1996-05-01 TW TW085105223A patent/TW299544B/zh not_active IP Right Cessation
- 1996-07-11 CN CNB961939486A patent/CN1167237C/zh not_active Expired - Lifetime
- 1996-07-11 ES ES96923752T patent/ES2159037T3/es not_active Expired - Lifetime
- 1996-07-11 WO PCT/US1996/011555 patent/WO1997030539A1/en active IP Right Grant
- 1996-07-11 CA CA002218187A patent/CA2218187C/en not_active Expired - Lifetime
- 1996-07-11 KR KR1019970707264A patent/KR100295730B1/ko not_active IP Right Cessation
- 1996-07-11 EP EP96923752A patent/EP0823171B1/en not_active Expired - Lifetime
- 1996-07-11 AT AT96923752T patent/ATE201946T1/de not_active IP Right Cessation
- 1996-07-11 DE DE69613225T patent/DE69613225T2/de not_active Expired - Lifetime
- 1996-07-11 JP JP52931497A patent/JP3491011B2/ja not_active Expired - Fee Related
- 1996-07-11 CZ CZ19973540A patent/CZ289259B6/cs not_active IP Right Cessation
- 1996-07-11 PL PL96322830A patent/PL180619B1/pl not_active IP Right Cessation
- 1996-07-11 HU HU9801874A patent/HU227369B1/hu not_active IP Right Cessation
-
1997
- 1997-02-03 MY MYPI97000410A patent/MY120208A/en unknown
Also Published As
| Publication number | Publication date |
|---|---|
| EP0823171A1 (en) | 1998-02-11 |
| CA2218187C (en) | 2004-11-02 |
| JP3491011B2 (ja) | 2004-01-26 |
| HUP9801874A3 (en) | 1999-05-28 |
| ES2159037T3 (es) | 2001-09-16 |
| CA2218187A1 (en) | 1997-08-21 |
| PL180619B1 (pl) | 2001-03-30 |
| DE69613225T2 (de) | 2001-11-08 |
| CN1167237C (zh) | 2004-09-15 |
| CN1184575A (zh) | 1998-06-10 |
| KR100295730B1 (ko) | 2001-09-07 |
| PL322830A1 (en) | 1998-02-16 |
| WO1997030539A1 (en) | 1997-08-21 |
| HU227369B1 (en) | 2011-04-28 |
| EP0823171B1 (en) | 2001-06-06 |
| TW299544B (en) | 1997-03-01 |
| ATE201946T1 (de) | 2001-06-15 |
| JPH11500250A (ja) | 1999-01-06 |
| HUP9801874A2 (hu) | 1998-11-30 |
| CZ289259B6 (cs) | 2001-12-12 |
| US5859971A (en) | 1999-01-12 |
| DE69613225D1 (de) | 2001-07-12 |
| MY120208A (en) | 2005-09-30 |
| KR19980703864A (ko) | 1998-12-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CZ354097A3 (cs) | Způsob redukce dat, zařízení a počítačový programový produkt k jeho provádění | |
| US5754774A (en) | Client/server communication system | |
| CZ287957B6 (cs) | Způsob redukce dat a zařízení a počítačový programový produkt k jeho provádění | |
| EP0823093B1 (en) | Time coherent caching system | |
| 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 |
|---|---|---|---|
| PD00 | Pending as of 2000-06-30 in czech republic | ||
| MM4A | Patent lapsed due to non-payment of fee |
Effective date: 20070711 |