HU227369B1 - A method, apparatus and computer program for reducing data transmitted over an external communication link from a first application resident in a first computer to a second application resident in a second computer - Google Patents

Description

jegyzés létrehozásához a második számítógép (6) kérelmére válaszként a második alkalmazásnak szánt adatfolyamot eltárolnak a második számítógép (6) gyorsítótárában; ügyfélbázislap biztosításához a második alkalmazás kérelmeinek kiértékelésével megvizsgálják, hogy létezik-e már a vizsgált kérelemnek megfelelő ügyfél gyorsítótár-bejegyzés; kiszolgálóbázis-lap biztosításához a második alkalmazás kérelmeinek kiértékelésével megvizsgálják, hogy létezik-e már a vizsgált kérelemnek megfelelő kiszolgáló gyorsítótár-bejegyzés; a második alkalmazás megvizsgált kérelmére válaszként az első alkalmazástól származó válasznak megfelelő adatfolyamot még a válasznak a külső kommunikációs útvonalon történő elküldését megelőzően elfogják; az elfogott választ összehasonlítják a kiszolgálóbázis-lappal, és a kettő közötti különbségnek megfelelő különbözeti adatot állítanak elő; a különbözeti adatot a külső kommunikációs útvonalon a második számítógéphez (6) elküldik; az első számítógéppel (5) a külső kommunikációs útvonalon elküldött különbözeti adatot megszerzik; az elfogott válasznak megfelelő válaszadatfolyam létrehozásához a külső kommunikációs útvonalon kapott különbözeti adatok és az ügyfélbázislap kombinálásával a külső kommunikációs útvonalon vett ügyfélkiszolgáló specifikus adatfolyamból újraszerkesztik az első alkalmazástól származó kommunikációnak megfelelő válaszadatfolyamot; és az elfogott válasznak megfelelő újraszerkesztett adatfolyamot a második alkalmazás rendelkezésére bocsátják.

A találmány szerinti berendezésnek a javasolt eljárás egyes lépéseit megvalósító eszközei vannak. A találmány szerinti programterméknek az eljárás egyes lépéseinek megvalósítását eredményező, számítógéppel végrehajtható programkód eszközei vannak.

A találmány tárgya eljárás, berendezés és programtermék egy első számítógépben lévő első alkalmazástól egy második számítógépben lévő második alkalmazáshoz, annak kérelmére válaszként külső kommunikációs útvonalon továbbított adatmennyiség csökkentésére. A találmány ezen belül különböző számítógépeken található alkalmazások, például webböngészők és webkiszolgálók közötti különbözeti adatküldési kommunikációs megoldásokra vonatkozik.

Az „információs szupersztráda” utóbbi időbeni nagy publicitása növelte és erősítette az internetet, mint tömegkommunikációs média megértését és elfogadását. Az internetnek mint hálózatok közötti kommunikációra alkalmas médiának e széles körű elismerése egy olyan felhasználói bázist alakított ki, amely a számítógépes hálózatok közötti kommunikációt megvalósító, szabványos internetprotokollokra épül.

Az internet mintája az az ügyfél-kiszolgáló kapcsolat, ahol internetügyfelek (böngészők) kommunikálnak internetkiszolgálókkal. Azért, hogy egyre többen elérhessék az internetet, a kommunikációs protokollokat, valamint az ügyfelek és kiszolgálók által használt nyelveket egységesítették. Ilyen protokoll például a hipertext átviteli protokoll (HTTP, Hypertext Transfer Protocol), amely ügyfelek és kiszolgálók közötti kommunikációra alkalmas, valamint az átvitelirányító protokoll/internetprotokoll (TCP/IP, Transmission Control Protocol/lnternet Protocol), melynek TCP része a számítógépek vagy alkalmazások közötti kommunikációnak az adatátvitel-specifikus protokollja. Szintén szabványosított az a hipertext nyelvnek (HTML, Hypertext Markup Language) nevezett nyelv, amellyel ügyfelek és kiszolgálók kommunikálnak egymással. Mivel ezek a protokollok és a nyelv géptípustól függetlenek, és az információtovábbításhoz összeköttetés-mentes, a legjobb minőségre törekvő, ám azt nem garantáló (best-efforts) protokollt használnak, minden egyes ügylet teljesen önállóan kezelhető. így például az ügyféltől származó minden egyes üzenet információt tartalmaz a böngé25 sző képességeiről, és független minden egyéb kommunikációtól. Az ügyfél és a kiszolgáló közötti kommunikációnak ezen önálló, független tulajdonsága, amely „hontalan” (csomagkapcsolt) kommunikációnak nevezhető, növeli az adott kommunikáció alkalmával az ügyfél és a kiszolgáló között átvihető adatmennyiséget.

World wide webes ügyfél-kiszolgáló alkalmazások környezetében az ügyfél általában egy webböngészőt jelent, amely felhasználói felületként működik. A webböngésző elküldi a felhasználói kérelmeket a megfelelő webkiszolgálóhoz, valamint formázza és megjeleníti a kiszolgáló által visszaküldött HTML adatot. A webböngésző emellett megvizsgálja a HTML adatot, hogy megállapítsa, van-e benne beágyazott hipercsatolás, amely további böngészőkérelmeket tehet szükségessé, amelyeket a böngésző aztán kezdeményez is. A webkiszolgáló az ügyfél kiszolgálójaként működik, feldolgozza a böngésző kérelmeit, és a kért választ egy HTTP adatfolyam HTML adatrészeként visszaküldi.

A world wide web kommunikáció egy tipikus példája, mikor egy webböngésző elküld egy „honlap”-kérelmet, jól illusztrálja a HTTP, HTML, TCP és a webböngésző, illetve kiszolgáló közötti kapcsolatot. Amikor a webböngésző felhasználója információt kér egy bizonyos webhelyről, a webböngésző kommunikációt kezdeményez a kiszolgálóval úgy, hogy egy „kap” kérelmet küld a webkiszolgálónak, megadva a keresett webhely egységes forrásmeghatározóját (URL, Universal Resource Locator), amely e példa kedvéért legyen egy honlap. Az URL tulajdonképpen a webhely címének szerepét tölti be, így minden webhelynek egyedi címe van az interneten. A webkiszolgáló ekkor megszerzi és elküldi a webböngészőnek az URL által meghatározott honlapnak megfelelő HTML adatot. Ez a művelet a webkiszolgálót az interneten további kommunikációra késztetheti, vagy az URL azonosíthatja azon helyi hálózatban lévő kiszolgálót is, amelyikhez a böngésző is csatlakozik. A webböngésző ezután kiértékeli a HTTP adatfolyamként megkapott HTML adatot, hogy megál2

HU 227 369 Β1 lapítsa, van-e benne beágyazott hipercsatolás, például egy ikon vagy egy kép. Ha létezik ilyen hipercsatolás, akkor a webböngésző a meghatározott adat beszerzéséhez kérelmeket kezdeményez, meghatározva a hipercsatolás URL-jét. Ezt az adatot aztán a böngésző beágyazza a honlapba, és megjeleníti a felhasználó számára. Mint ebben az egyszerű példában látható, a webböngészőn keresztül megadott egyszeri felhasználói kérelem olyan többszöri, kiegészítő kérelmeket eredményezhet, melyeket a webböngésző automatikusan végrehajt, a felhasználói kérelemre válaszként kapott HTML adatnak megfelelően.

Az 1. ábra egy az internetre épülő rendszer alapvető kommunikációs szerkezetét ábrázolja. Az 1. ábrán egy 10 webböngésző és egy 20 webkiszolgáló kommunikál egymással egy 15 átviteli vonalon keresztül. Ez a kommunikációs vonal általában egy helyi hálózati kapcsolat, kiterjedt hálózati kapcsolat, telefonvonalon keresztüli kapcsolat vagy különböző kapcsolatfajták kombinációja. A 10 webböngésző a 20 webkiszolgálóval a TCP/IP-t használva kommunikál. Az internetes kommunikációk többségénél a webböngésző a webkiszolgálóval a HTTP általános kommunikációs protokollt használva kommunikál, ami a webböngésző és a webkiszolgáló közötti TCP/IP kapcsolaton továbbítódik. A fent leírtak szerint a 10 webböngésző és 20 webkiszolgáló között átvitt tényleges adatok tehát HTTP adatobjektumok (például HTML adatok). A 20 webkiszolgáló lehet egy megbízott (proxy) is, amely különböző webböngészőktől kap kérelmeket, és átirányítja azokat a megfelelő kiszolgálóhoz.

A webböngészők/webkiszolgálók, valamint közös információs és átviteli protokolljaik, a HTML és a HTTP népszerűsége a webtechnológiának, mint a hálózati információ-hozzáférés univerzális felületének rendkívül gyors elfogadásához vezetett. Továbbá, mivel a webböngészők és webkiszolgálók közötti kommunikációs nyelv és protokollok szabványosítottak, független attól, hogy a felhasználó Netscape Navigator(TM), NCSA Mosaic(TM), WebExplorer(TM) vagy bármilyen más webböngészőt használ az információs hálózat eléréséhez, a kommunikációs nyelv és protokollok ugyanazok lesznek. Ezért a webböngészők nagy felhasználói bázisa, az internetre csatlakozás lehetőségével és a webalkalmazásoknak, a HTTP által definiált közös átjárófelületen (CGI, Common Gateway Interface) való egyszerű meg írhatóságával együtt, nagyon vonzóvá teszik a webtechnológiát az űrlapalapú alkalmazások nagy része számára.

A röviden vázolt megoldás részletesen is megismerhető Francis Heylighen: „World-Wide Web: a distributed hypermedia paradigm tor global networking” Apr. 18, 1994, IEE/INSPEC Database Updates and Additions (1960-95) doc.}# 1374618; Proceedings. Share Europe Spring Conference 1994. 355-368. oldalain, vagy a magyar nyelvű szakirodalomban például Füstös János: „World-Wide Web. Bevezetés a hálózati információszolgáltató rendszer tervezésébe és használatába” című könyvéből SZAK Kiadó, Bicske, 1996. Ezek a találmányunk szempontjából ismert műszaki szintnek tekinthető források nem számoltak azonban az alábbi, egyre erőteljesebben jelentkező ténnyel:

Az internet népszerűségének és elfogadottságának növekedésével egy időben a hordozható számítógépek népszerűsége is megnövekedett. A laptopok, a noteszgépek, az elektronikus személyi/kommunikációs titkárok (PDA-k/PCA-k) és egyéb hordozható eszközök használata a vezeték nélküli kommunikáció iránti igény növekedéséhez vezetett. A kiterjedt vezeték nélküli hálózatok, a mobiltelefon-kommunikáció és a csomagkapcsolt rádiósugárzás webes környezetben való használata azonban közös korlátokba ütközik. A kommunikáció bájtonkénti magas ára, a hosszú válaszolás! idő, az alacsony sávszélesség és a megbízhatatlanság mind gátolják a vezeték nélküli technológia alkalmazását a world wide web „hontalan” kommunikációs protokolljával. Sőt, mivel a webprotokoll „hontalan”, a kérelmenként! adatmennyiségek és a vezeték nélküli kapcsolaton áthaladó kérelmek száma nagyobb, mint amire akkor lenne szükség, ha a kommunikáció nem lenne önálló. Tehát a vezeték nélküli technológia, vagy bármilyen más alacsony sebességű kommunikációs technológia kombinálása a webtechnológiával célszerűtlennek tűnik, mivel a webtechnológia a maga univerzális természetével súlyosbítja a vezeték nélküli technológia gyengéit.

A vázolt korlátok és hiányosságok keretében a találmánnyal célunk olyan eljárás, azt megvalósító berendezés, valamint program létrehozása, amellyel csökkenteni tudjuk az alkalmazások között továbbítandó adatok mennyiségét. Célunk továbbá, hogy a létrehozott eljárás, berendezés és program webböngésző/webkiszolgáló környezetben is eredményesen használható legyen. Célunk továbbá a találmánnyal, hogy a megoldás kompatibilis legyen a kis sebességű vagy vezeték nélküli rendszerekben már létező kommunikációs protokollokkal és nyelvekkel, anélkül, hogy szükségessé válna a webböngésző és webkiszolgáló alkalmazások módosítása. Ugyancsak célunk a találmánnyal, hogy a webböngésző és a webkiszolgáló közötti kommunikáció, adatmennyiség csökkentésével a kommunikációs rendszer teljesítményét növeljük.

A kitűzött feladat megoldása során olyan eljárást vettünk alapul egy első számítógépben lévő első alkalmazástól egy második számítógépben lévő második alkalmazáshoz, annak kérelmére válaszként külső kommunikációs útvonalon továbbított adatmennyiség csökkentésére, amelynek során a továbbfejlesztés értelmében egy kiszolgálóbázis gyorsítótár-bejegyzés létrehozásához a második alkalmazástól érkezett kérelemre válaszként az első alkalmazásból származó adatfolyamot eltárolunk az első számítógép gyorsítótárában; egy ügyfélbázis gyorsítótár-bejegyzés létrehozásához a második számítógép kérelmére válaszként a második alkalmazásnak szánt adatfolyamot eltárolunk a második számítógép gyorsítótárában; az ügyfélbázislap biztosításához a második alkalmazás kérelmeinek kiértékelésével megvizsgáljuk, hogy létezik-e már a vizsgált kérelemnek megfelelő ügyfél gyorsítótár-bejegyzés; a kiszolgálóbázis-lap biztosításához a

HU 227 369 Β1 második alkalmazás kérelmeinek kiértékelésével megvizsgáljuk, hogy létezik-e már a vizsgált kérelemnek megfelelő kiszolgáló gyorsítótár-bejegyzés; a második alkalmazás megvizsgált kérelmére válaszként az első alkalmazástól származó válasznak megfelelő adatfolyamot még a válasznak a külső kommunikációs útvonalon történő elküldését megelőzően elfogjuk; az elfogott választ összehasonlítjuk a kiszolgálóbázis-lappal, és a kettő közötti különbségnek megfelelő különbözeti adatot állítunk elő; a különbözeti adatot a külső kommunikációs útvonalon a második számítógéphez elküldjük; az első számítógéppel a külső kommunikációs útvonalon elküldött különbözeti adatot megszerezzük; az elfogott válasznak megfelelő válaszadatfolyam létrehozásához a külső kommunikációs útvonalon kapott különbözeti adatok és az ügyfélbázislap kombinálásával a külső kommunikációs útvonalon vett ügyfél-kiszolgáló specifikus adatfolyamból újraszerkesztjük az első alkalmazástól származó kommunikációnak megfelelő válaszadatfolyamot; és az elfogott válasznak megfelelő újraszerkesztett adatfolyamot a második alkalmazás rendelkezésére bocsátjuk.

A találmány szerinti eljárás egy előnyös foganatosítási módja értelmében meghatározzuk, hogy a kiszolgálóbázis-lap azonos-e az ügyfélbázislappal; és ha a kettő nem azonos, akkor a különbözeti adatok elküldése során mind a kiszolgálóbázis-lapot, mind a különbözeti adatokat elküldjük a külső kommunikációs útvonalon a második számítógéphez; a válaszadatfolyam újraszerkesztése során az első alkalmazástól származó válasznak megfelelő elfogott válaszadatfolyamot a külső kommunikációs útvonalon vett kiszolgálóbázis-lap és a különbözeti adatok kombinálásával szerkesztjük újra; és az ügyfélbázislapot a vett kiszolgálóbázis-lapnak az elfogott kérelemnek megfelelő ügyfélbázis gyorsítótár-bejegyzéseként való eltárolásával az elfogott kérelemnek megfelelően aktualizáljuk.

A találmány szerinti eljárás egy további előnyös foganatosítási módja értelmében megállapítjuk, hogy a kiszolgálóbázis-lap és az elfogott válasz közötti különbség meghalad-e egy előre meghatározott különbségküszöböt; és amennyiben meghalad, akkor az első alkalmazástól származó elfogott válaszadatfolyamnak az elfogott kérelemnek megfelelő kiszolgálóbázis gyorsítótár-bejegyzéseként való eltárolásával a kiszolgáló alaplapot az elfogott kérelemnek megfelelően aktualizáljuk; és az összehasonlítást és a küldést az aktualizált kiszolgálóbázis-lap használatával végezzük.

Ugyancsak előnyös a találmány értelmében, ha a második alkalmazástól származó kérelemnek megfelelő több kiszolgálóbázis gyorsítótár-bejegyzést fenntartunk; a második alkalmazástól származó kérelmek vizsgálása során több kiszolgálóbázis-lap létrehozásához meghatározzuk, hogy léteznek-e a második alkalmazástól származó kérelemnek megfelelő kiszolgálóbázis gyorsítótár-bejegyzések; megvizsgáljuk, hogy a szerverbázislapok egyike azonos-e az ügyfélbázislappal; és az elfogott válaszok összehasonlítása során a kiszolgálóbázis-lapok közül az ügyfélbázislappal azonos bázislapot használjuk, ha az előző lépésben valamelyik kiszolgálóbázis-lap és az ügyfélbázislap azonosságát megállapítottuk.

Fentieken túlmenően előnyös, ha a kiszolgáló gyorsítótár-bejegyzést a második alkalmazástól származó kérelem függvényében az első alkalmazástól származó adatfolyammal aktualizáljuk; a régi különbözeti adatok biztosításához a második alkalmazástól származó kérelemnek megfelelő és az egymást követő kiszolgáló gyorsítótár-bejegyzések közötti különbségeket képviselő különbözeti adatkészleteket tartunk fenn; a különbözeti adatkészletek egyikével társított és a különbözeti adatkészletet szolgáltató kiszolgálóbázis-lapot egyedien azonosító CRC bejegyzéseket tartunk fenn; a kérelmek megvizsgálása során meghatározzuk, hogy léteznek-e a második alkalmazástól származó kérelemnek megfelelő különbözeti adatkészletek és CRC-k; meghatározzuk, hogy a CRC-k valamelyike megfelel-e az ügyfélbázislappal azonos kiszolgálóbázis-lapnak; a különbözeti adatok elküldése során a külső kommunikációs útvonalon keresztül a második számítógépnek elküldjük az összehasonlítással kiszámított különbözeti adatok, az egymást követő régi különbözeti adatkészleteknek és az ügyfélbázislapoknak megfelelő CRCnek megfelelő régi különbözeti adatokat; az újraszerkesztés során az elfogott válasznak megfelelő válaszadatfolyam létrehozásához az ügyfélbázislap és a külső kommunikációs útvonalon át kapott különbözeti adatok egymást követő kombinálásával a válaszadatfolyamot a külső kommunikációs útvonalon át fogadott adatfolyamból az első alkalmazástól származó kommunikációnak megfelelően újraszerkesztjük; és az ügyfél gyorsítótár-bejegyzést az újraszerkesztett adatfolyammal második alkalmazástól származó kérelemnek megfelelően aktualizáljuk.

Ugyancsak előnyös a találmány értelmében, ha első alkalmazásként webkiszolgáló alkalmazást, második alkalmazásként webböngészö alkalmazást használunk.

A találmány szerinti eljárás egy további előnyös foganatosítási módja értelmében a külső kommunikációs útvonalként vezeték nélküli kommunikációs kapcsolatot használunk.

Fentieken túlmenően előnyös továbbá, ha a webböngészőtől származó kérelembe CGI-kérelmet ágyazunk.

A kitűzött feladat megoldása során továbbá olyan berendezést vettünk alapul egy első számítógépben lévő első alkalmazástól egy második számítógépben lévő második alkalmazáshoz, annak kérelmére válaszként külső kommunikációs útvonalon továbbított adatmennyiség csökkentésére, amelynek a találmány értelmében egy kiszolgálóbázis gyorsítótár-bejegyzés létrehozásához a második alkalmazástól érkezett kérelemre válaszként az első alkalmazásból származó adatfolyamot az első számítógép gyorsítótárában eltároló eszköze; egy bázis gyorsítótár-bejegyzés létrehozásához a második számítógép kérelmére válaszként a második alkalmazásnak szánt adatfolyamot a második számítógép gyorsítótárában eltároló eszköze; egy ügyfélbázislap biztosításához a második alkalmazás kérel4

HU 227 369 Β1 meinek kiértékelésére a vizsgált kérelemnek megfelelő ügyfél gyorsítótár-bejegyzés létezését megvizsgáló eszköze; egy kiszolgálóbázis-lap biztosításához a második alkalmazás kérelmeinek kiértékelésére a vizsgált kérelemnek megfelelő kiszolgáló gyorsítótárbejegyzés létezését megvizsgáló eszköze; a második alkalmazás megvizsgált kérelmére válaszként az első alkalmazástól származó válasznak megfelelő adatfolyamot még a válasznak a külső kommunikációs útvonalon történő elküldését megelőzően elfogó eszköze; az elfogott választ a kiszolgálóbázis-lappal összehasonlító és a kettő közötti különbségnek megfelelő különbözeti adatot előállító eszköze; a különbözeti adatot a külső kommunikációs útvonalon a második számítógéphez elküldő eszköze; az első számítógéppel a külső kommunikációs útvonalon elküldött különbözeti adatot megszerző eszköze; az elfogott válasznak megfelelő válaszadatfolyam létrehozásához a külső kommunikációs útvonalon kapott különbözeti adatok és az ügyfélbázislap kombinálásával a külső kommunikációs útvonalon vett ügyfél-kiszolgáló specifikus adatfolyamból az első alkalmazástól származó kommunikációnak megfelelő válaszadatfolyamot újraszerkesztő eszköze; és az elfogott válasznak megfelelő újraszerkesztett adatfolyamot a második alkalmazás rendelkezésére bocsátó eszköze van.

A kitűzött feladat megoldása során ezen túlmenően olyan programterméket vettünk alapul egy első számítógépben lévő első alkalmazástól egy második számítógépben lévő második alkalmazáshoz, annak kérelmére válaszként külső kommunikációs útvonalon továbbított adatmennyiség csökkentésére, amelynek a továbbfejlesztés szerint egy kiszolgálóbázis gyorsítótár-bejegyzés létrehozásához a második alkalmazástól érkezett kérelemre válaszként az első alkalmazásból származó adatfolyamot az első számítógép gyorsítótárában eltároló számítógéppel olvasható programkód eszköze; egy ügyfélbázis gyorsítótár-bejegyzés létrehozásához a második számítógép kérelmére válaszként a második alkalmazásnak szánt adatfolyamot a második számítógép gyorsítótárában eltároló számítógéppel olvasható programkód eszköze; egy ügyfélbázislap biztosításához a második alkalmazás kérelmeinek kiértékelésére a vizsgált kérelemnek megfelelő ügyfél gyorsítótár-bejegyzés létezését megvizsgáló számítógéppel olvasható programkód eszköze; egy kiszolgálóbázis-lap biztosításához a második alkalmazás kérelmeinek kiértékelésére a vizsgált kérelemnek megfelelő kiszolgáló gyorsítótár-bejegyzés létezését megvizsgáló számítógéppel olvasható programkód eszköze; a második alkalmazás megvizsgált kérelmére válaszként az első alkalmazástól származó válasznak megfelelő adatfolyamot még a válasznak a külső kommunikációs útvonalon történő elküldését megelőzően elfogó számítógéppel olvasható programkód eszköze; az elfogott választ a kiszolgálóbázis-lappal összehasonlító és a kettő közötti különbségnek megfelelő különbözeti adatot előállító számítógéppel olvasható programkód eszköze; a különbözeti adatot a külső kommunikációs útvonalon a második számítógéphez elküldő számítógéppel olvasható programkód eszköze; az első számítógéppel a külső kommunikációs útvonalon elküldött különbözeti adatot megszerző számítógéppel olvasható programkód eszköze; az elfogott válasznak megfelelő válaszadatfolyam létrehozásához a külső kommunikációs útvonalon kapott különbözeti adatok és az ügyfélbázislap kombinálásával a külső kommunikációs útvonalon vett ügyfél—kiszolgáló-specifikus adatfolyamból az első alkalmazástól származó kommunikációnak megfelelő válaszadatfolyamot újraszerkesztő számítógéppel olvasható programkód eszköze; és az elfogott válasznak megfelelő újraszerkesztett adatfolyamot a második alkalmazás rendelkezésére bocsátó számítógéppel olvasható programkód eszköze van.

A találmányt az alábbiakban a csatolt rajz segítségével ismertetjük részletesebben, amelyen a javasolt eljárás példaként! foganatosítási módját, illetve az eljárást megvalósító berendezés példaként! kiviteli alakját tüntettük fel. A rajzon az

1. ábra az ismert műszaki szinthez tartozó, jellemző webböngésző-webkiszolgáló rendszer tömbvázlata, a

2. ábrán a találmány szerinti berendezés ügyféloldali kommunikációelfogást és kiszolgálóoldali kommunikációelfogást alkalmazó lehetséges kiviteli alakjának tömbvázlata látható, a

3. ábrán egy időben összetartozó, azaz koherens gyorsítótárrendszert megvalósító találmány szerinti eljárás egy előnyös foganatosítási módja ügyféloldali elfogási lépéseit bemutató folyamatábra látható, a

4. ábrán egy időben összetartozó, azaz koherens gyorsítótárrendszert megvalósító találmány szerinti eljárás egy előnyös foganatosítási módja ügyféloldali elfogási lépéseit bemutató további folyamatábra látható, az

5. ábrán egy időben összetartozó, azaz koherens gyorsítótárrendszert megvalósító találmány szerinti eljárás egy előnyös foganatosítási módja kiszolgálóoldali elfogási lépéseit bemutató folyamatábra látható, a

6. ábrán egy időben összetartozó, azaz koherens gyorsítótárrendszert megvalósító találmány szerinti eljárás egy előnyös foganatosítási módja kiszolgálóoldali elfogási lépéseit bemutató további folyamatábra látható, a

7. ábrán egy időben összetartozó, azaz különbözeti adattovábbító rendszert megvalósító találmány szerinti eljárás egy előnyös foganatosítási módja ügyféloldali elfogási lépéseit bemutató folyamatábra látható, a

8. ábrán egy időben összetartozó, azaz különbözeti adattovábbító rendszert megvalósító találmány szerinti eljárás egy előnyös foganatosítási módja ügyféloldali elfogási lépéseit bemutató további folyamatábra látható, a

HU 227 369 Β1

9. ábrán egy időben összetartozó, azaz különbözeti adattovábbító rendszert megvalósító találmány szerinti eljárás egy előnyös foganatosítási módja kiszolgálóoldali elfogási lépéseit bemutató folyamatábra látható, a

10A., 10B. ábrán egy időben összetartozó, azaz különbözeti adattovábbító rendszert megvalósító találmány szerinti eljárás egy előnyös foganatosítási módja kiszolgálóoldali elfogási lépéseit bemutató folyamatábra látható, a

11. ábra a találmány szerinti berendezés virtuális szoftvercsatornákat használó lehetséges kiviteli alakjának tömbvázlata, a

12. ábra a találmány szerinti berendezés virtuális szoftvercsatornákat alkalmazó lehetséges kiviteli alakjának részét képező ügyféloldali elfogómodul és szerveroldali elfogómodul tömbvázlata, a

13A., 13B. ábra a találmány szerinti eljárás virtuális szoftvercsatornákat használó lehetséges foganatosítási módja ügyféloldali elfogómoduljának vagy kiszolgálóoldali elfogómoduljának a szoftvercsatorna kezelője által elvégzett műveleteit mutatja folyamatábra alakjában, a

14. ábra a találmány szerinti eljárás virtuális szoftvercsatornákat alkalmazó egy lehetséges foganatosítási módjában az ügyféloldali elfogóalkalmazás révén végrehajtott műveleteket ismerteti egy folyamatábra segítségével, a

15. ábra a találmány szerinti eljárás virtuális szoftvercsatornákat alkalmazó egy lehetséges foganatosítási módjában a kiszolgálóoldali elfogóalkalmazás révén végrehajtott műveleteket ismerteti egy folyamatábra segítségével, a

16-1. ábra a találmány szerinti eljárás virtuális szoftvercsatornákat alkalmazó lehetséges foganatosítási módja szerinti virtuális létrehozás műveletét ismertető folyamatábra, a

16-2. ábra a találmány szerinti eljárás virtuális szoftvercsatornákat alkalmazó lehetséges foganatosítási módja szerinti virtuális küldés műveletét ismertető folyamatábra, a

16-3. ábra a találmány szerinti eljárás virtuális szoftvercsatornákat alkalmazó lehetséges foganatosítási módja szerinti virtuális vétel műveletét ismertető folyamatábra, a

16— 4. ábra a találmány szerinti eljárás virtuális szoftvercsatornákat alkalmazó lehetséges foganatosítási módja szerinti virtuális kiválasztás műveletét ismertető folyamatábra, a

17- 1. ábra a találmány szerinti eljárás virtuális szoftvercsatornákat alkalmazó lehetséges foganatosítási módja szerinti virtuális ürítés műveletét ismertető folyamatábra, a

17-2. ábra a találmány szerinti eljárás virtuális szoftvercsatornákat alkalmazó lehetséges foganatosítási módja szerinti virtuális lezárás műveletét ismertető folyamatábra.

Áttérve az ábrák részletes bemutatására, a 3-10., valamint a 13-17-2. ábrákon a találmány szerinti eljárás foganatosítási módjának folyamatábráit tüntettük fel. Szakember számára kézenfekvő módon a folyamatábrák minden egyes lépése és a lépések kombinációi számítógépprogram-utasításként is tekinthetők és megvalósíthatók úgy, hogy számítógépbe vagy más programozható készülékbe töltve és utasításként végrehajtva a folyamatábra egyes lépéseiben meghatározott feladatokat valósítják meg. Az egyes lépések utasítások - számítógép által olvasható memóriában is tárolhatók, amelyek a számítógépet vagy más programozható szerkezetet úgy vezérlik, hogy az az utasítások hatására valamilyen gyártmányt, terméket állítson elő. Ezeket a számítógépprogram-utasításokat úgy is betölthetjük a számítógépbe vagy más programozható berendezésbe, hogy azzal végrehajtva olyan műveleti lépések sorozatát idézzék elő, aminek következtében a folyamatábrában meghatározott funkciók hajthatók végre.

Ennek megfelelően a folyamatábra egyes lépései támogatják a meghatározott feladatok elvégzésére szolgáló eszközök kombinációit, valamint a meghatározott feladatok elvégzésére szolgáló lépések kombinációit is. A folyamatábra egyes lépései, vagy bizonyos lépések kombinációi olyan célorientált hardverrel rendelkező számítógéprendszerekkel is megvalósíthatók, amelyek a célorientált hardver és számítógép-utasítás kombinációit, illetve a meghatározott funkciókat vagy lépéseket képesek megvalósítani.

A 2. ábrán a találmány szerinti rendszer egy lehetséges kiviteli alakjának tömbvázlatát tüntettük fel. Ezen 10 webböngésző ügyféloldali 30 elfogómodullal, 20 webkiszolgáló pedig kiszolgálóoldali 40 elfogómodullal áll kapcsolatban. Az ügyféloldali 30 elfogómodul 35 átviteli vonalon keresztül kommunikál a kiszolgálóoldali 40 elfogómodullal. A 10 webböngésző és az ügyféloldali 30 elfogómodul első 5 számítógépben helyezhető el. A kiszolgálóoldali 40 elfogómodult és a 20 webkiszolgálót második 6 számítógép tartalmazhatja. Az első 5 számítógép és a második 6 számítógép a külső 35 átviteli vonalon keresztül áll egymással kapcsolatban.

A 10 webböngésző célszerűen olyan internet 10 webböngésző, amely hipertext átviteli protokollt (HTTP) és hipertext nyelvet (HTML) használ arra, hogy egy ugyancsak ezt a protokollt és ezt a nyelvet használó internet 20 webkiszolgálóval kommunikálni tudjon. Működése során a 10 webböngésző HTTP adatfolyamot bocsát ki, amelyet az ügyféloldali 30 elfogómodul fogad. Az ügyféloldali 30 elfogómodul ezt a HTTP adatfolyamot saját TCP/IP visszacsatolási tulajdonsága ré6

HU 227 369 Β1 vén fogadhatja, ha egy 127 hálózati számú IP-címen, például a 127.0.01 IP-címen található. Az ügyféloldali 30 elfogómodul ezt a HTTP adatfolyamot ügyfél-kiszolgáló specifikus protokollra alakítja át, majd az ügyfél-kiszolgáló specifikus adatfolyamot kiadja a külső 35 átviteli vonalra. A kiszolgálóoldali 40 elfogómodul fogadja az ügyfél-kiszolgáló specifikus adatfolyamot, és abból helyreállítja a 10 webböngészőtől származó kommunikációnak megfelelő eredeti HTTP adatfolyamot, és azt továbbítja a 20 webkiszolgálónak. A 20 webkiszolgáló a HTTP adatfolyamra az internet 20 webkiszolgálók hagyományos módján válaszol. Mint ez szakember számára nyilvánvaló, a 20 webkiszolgáló több 10 webböngésző internethez csatlakozását lehetővé tevő proxy is lehet. Amikor a 20 webkiszolgáló a 10 webböngészőnek továbbítandó információt fogad, például a 10 webböngésző egy meghatározott URL honlap iránti kérelmére válaszolva, akkor egy, a 10 webböngészőnek küldendő kommunikációnak megfelelő HTTP adatfolyamot bocsát ki. Ezt a 20 webkiszolgálótól származó kommunikációt a kiszolgálóoldali 40 elfogómodul elfogja, és az ügyfél-kiszolgáló specifikus adatfolyam segítségével átalakítja, és a 20 webkiszolgálótól származó kommunikációnak megfelelő ügyfél-kiszolgáló specifikus adatfolyamot a külső 35 átviteli vonalon keresztül a második 6 számítógépből elküldi az első 5 számítógépnek. Az ügyfél-kiszolgáló specifikus adatfolyamot az ügyféloldali 30 elfogómodul fogadja, visszaállítja a 20 webkiszolgálótól származó kommunikációnak megfelelő eredeti HTTP adatfolyamot, és azt továbbítja a 10 webböngészőnek.

A találmány szerinti rendszer egy lehetséges kiviteli alakjánál a külső 35 átviteli vonal vezeték nélküli kommunikációs vonal. Ilyen esetben annak érdekében, hogy a felhasználók számára is elfogadható rendszerteljesítményt kapjunk, célszerű a külső 35 átviteli vonalon történő adatátvitelek mértékét csökkenteni, mégpedig mind az átvitelek gyakoriságát, mind a továbbítandó információ mennyiségét illetően. Ennek megfelelően találmányunkban különböző közbenső tárolási, megkülönböztetési és protokollcsökkentési módszereket használunk a külső 35 átviteli vonalon keresztül történő kommunikáció mennyiségének a minimalizálása érdekében. Ezeket a módszereket a hontalan vagy statisztikai valószínűségen alapuló (sztohasztikus) HTTP protokollnak ügyfél-kiszolgáló specifikus protokollra történő átalakításával végezzük úgy, hogy az ügyfél-kiszolgáló specifikus protokollal az ügyfélre és a kiszolgálóra jellemző információkat hasznosítjuk a kommunikáció mennyiségének és gyakoriságának a csökkentése céljából.

A találmányt eddigiekben - és a továbbiakban is egyetlen 10 webböngésző és egyetlen 20 webkiszolgáló esetére ismertettük, de szakember számára kézenfekvő módon a találmány előnyei egyetlen 20 webkiszolgálóval kapcsolatban álló több 10 webböngésző esetében is élvezhetők. így tehát a találmány szerinti eljárás során és rendszerben, és az ebből levezethető programtermékben is többszörös 10 webböngésző esetén a 10 webböngészők egy-egy ügyféloldali 30 elfogómodullal kommunikálnak, és a 30 elfogómodulok állnak kapcsolatban a 20 webkiszolgáló vagy a proxy kiszolgálóoldali 40 elfogómoduljával.

A találmány egy további lehetséges kiviteli alakjánál mind az ügyféloldali 30 elfogómodul, mind pedig a kiszolgálóoldali 40 elfogómodul gyorsítótárat (cache) tartalmaz. Az első 5 számítógépben lévő ügyfélgyorsítótár a 10 webböngészőtől származó kommunikációra válaszként érkező, a 10 webböngésző által fogadható HTTP adatfolyamokat tárol. A második 6 számítógépben lévő kiszolgáló gyorsítótár pedig olyan HTTP adatfolyamokat tárol, amelyeket a 20 webkiszolgálótól kapott, egy 10 webböngészőtől származó kommunikációra adott válaszként.

Szakember számára nyilvánvaló módon az első 5 számítógépben, illetve a második 6 számítógépben található gyorsítótár mérete az 5, 6 számítógépek egyedi hardverkiépítésétől függően bármekkora lehet. Ezek a gyorsítótárak minden egyes átvitelre vonatkozóan tartalmaznak információt, beleértve a kommunikáció URL-jét, egy, a kommunikáció tartalmán alapuló egyedi azonosítót, például a kommunikáció adatainak ciklikus redundancia-ellenőrzését (CRC), a tárolási időpontot (SDT), amely a gyorsítótár létrejöttének vagy frissítésének az időpontját jelzi, valamint az átvitel adatait. így a gyorsítótárban tárolt minden egyes kommunikáció számára létrehozható egy-egy tárbejegyzés. Ezen túlmenően a hardverkiépítéseknél lévő korlátozott erőforrások miatt a szakterületen ismert összes olyan gyorsítótármódszer alkalmazható, amely elősegíti az első és második 5, 6 számítógépben található gyorsítótárak fenntartását. így például a gyorsítótár érvénytelenítheti a legkorábbi könyvtárbejegyzést, ha az újabb bejegyzés hozzáadása meghaladná a felhasználó által meghatározott gyorsítótárméretet, és az új bejegyzést az érvénytelenített bejegyzés helyére teheti. Ezenkívül a gyorsítótár-bejegyzések fenntarthatok több párhuzamosan futó 10 webböngésző 20 webkiszolgáló-alkalmazás számára, vagy akár az első, illetve második 5, 6 számítógép ki- és bekapcsolása közben, így állandó gyorsítótárat hozunk létre.

A 3-6. ábrák segítségével a gyorsítótárak találmány szempontjából lényeges szerkezeti kialakítását és működését mutatjuk be. A 3-6. ábrák tulajdonképpen az ügyféloldali 30 elfogómodul és a kiszolgálóoldali 40 elfogómodul használatára vonatkozó lehetséges eljárás folyamatábrái.

A 3. ábra 100 lépésében az ügyféloldali 30 elfogómodullal kérelmet fogadunk a 10 webböngészőtől, mely kérelem történhet a HTTP adatfolyam formájában. 105 lépésben az ügyféloldali 30 elfogómodullal ellenőrizzük a beérkező kérelem univerzális forrásmeghatározóját (URL-jét), és az URL alapján megállapítjuk, hogy az első 5 számítógépben található ügyfélgyorsítótárban eltároltunk-e a 10 webböngészőtől származó kérelemnek megfelelő információt. Ha ez még nem történt meg, akkor 106 lépésben az ügyféloldali 30 elfogómodullal elküldjük a kérelmet a kiszolgálóoldali 40 elfogómodulhoz, beleértve a HTTP-kérelmet, az időbeli összetartozási intervallumot, valamint egy nulla értékű

HU 227 369 Β1

CRC-t. Mindezt a külső 35 átviteli vonalon keresztül juttatjuk el a kiszolgálóoldali 40 elfogómodulhoz.

Ha azonban a 105 lépésben azt állapítjuk meg a 10 webböngészőtől származó kommunikáció vizsgálata során, hogy már létezik egy, a 10 webböngészőtől származó kommunikációnak megfelelő ügyfél gyorsítótár-bejegyzés, akkor a találmány szerinti eljárás legegyszerűbb foganatosítási módja értelmében ezt az információt HTTP adatfolyam formájában továbbítjuk a 10 webböngészőnek. A javasolt eljárás bemutatott foganatosítási módja szerint a 10 webböngészőtől származó kommunikációnak megfelelő gyorsítótár-bejegyzésen elvégzünk egy, a továbbiakban időbeli összetartozási intervallum ellenőrzésként nevezett műveletet ezt a 3. ábra 110 lépésében hajtjuk végre.

Az ügyféloldali 30 elfogómodul időbeli összetartozási intervallumnak értékét a felhasználó is meghatározhatja, és ez az érték azt az időtartamot jelenti, ameddig a gyorsítótárbejegyzés létezhet, mielőtt a benne tárolt adatok elavulnak. A gyorsítótárat akkor is frissíteni kell a 20 webkiszolgálótól kért és a 10 webböngészőtől származó kommunikációnak megfelelő információval, ha ez az érték adott. A 110 lépésben elvégzett időbeli összetartozási intervallum ellenőrzés az aktuális dátum és idő, valamint a 10 webböngészőtől származó kommunikációnak megfelelő gyorsítótár-bejegyzés SDT-jének, és a felhasználó által meghatározott időbeli összetartozási intervallum összegének az összehasonlítása révén történik. Ha az aktuális dátum és idő meghaladja ezt az összegértéket, akkor a 10 webböngészőtől származó gyorsítótárban tárolt információk már elavultak, és a 110 lépésben a „NEM” ágat választjuk. Ha azonban az aktuális dátum és idő értéke kisebb, mint az SDT és a felhasználó által meghatározott időbeli összetartozási intervallum összege, akkor a 110 lépésben az „IGEN” ágat választjuk és 110 lépésben a gyorsítótár-bejegyzést továbbítjuk a 10 webböngészőnek HTTP adatfolyam formájában, és ezzel fejezzük be a 100 lépésben az ügyféloldali 30 elfogómodul által fogadott 10 webböngészőtől származó kommunikációt.

Ha a 110 lépésben jelzett időbeli összetartozási intervallum ellenőrzése során azt állapítjuk meg, hogy az első 5 számítógépben található gyorsítótár-bejegyzés elavult, akkor a 3. ábra 112 lépésében a kiszolgálóoldali 40 elfogómodulnak kérelmet küldünk, hogy ellenőrizze a második 6 számítógépben található gyorsítótár-bejegyzést is. Ezt a kiszolgálóoldali 40 elfogómodulnak a külső 35 átviteli vonalon keresztül a 10 webböngészőtől származó HTTP-kérelem és a 10 webböngészőtől származó kommunikáció URL-jének megfelelő ügyfélgyorsítótár tartalmáról szóló különleges megkülönböztetőjel elküldésével történhet. Egy előnyös foganatosítási mód értelmében ilyen különleges megkülönböztető jelként a gyorsítótár-bejegyzés ciklikus redundancia-ellenőrzésének (CRC) az eredményét használjuk.

Az 5. ábrán a kiszolgálóoldali 40 elfogómodullal a külső 35 átviteli vonalon keresztül az ügyféloldali 30 elfogómodultól fogadott információk hatására végzett műveleteket mutatjuk be. Amikor a kiszolgálóoldali 40 elfogómodullal az ügyféloldali 30 elfogómodultól kérelmet fogadunk, a kiszolgálóoldali 40 elfogómodullal fogadjuk az előre meghatározott ügyfél időbeli összetartozási intervallumot, az ügyfélgyorsítótár CRC-értékét, és a 10 webböngészőtől származó HTTP-kérelmet. Mindezt az 5. ábrán a 120 lépésben végezzük el.

Ezt követően az ügyféloldali 30 elfogómodul információinak fogadása után a kiszolgálóoldali 40 elfogómodullal a második 6 számítógépben található gyorsítótárat ellenőrizzük, hogy megállapítsuk, létezik-e a 10 webböngészőtől származó HTTP-kérelem URL-jének megfelelő kiszolgáló gyorsítótár-bejegyzés. Ha a 125 lépésben végrehajtott, a 10 webböngészőtől származó kommunikáció vizsgálata során a kiszolgálóoldali 40 elfogómodullal megállapítjuk, hogy létezik a 10 webböngészőtől származó kommunikáció által kérelmezett információnak megfelelő gyorsítótár-bejegyzés, akkor a 125 lépésről az „IGEN” ágon haladunk tovább, és összehasonlítjuk a kiszolgálóoldali 40 elfogómodullal saját aktuális dátumunkat és időnket a 10 webböngészőtől származó kommunikáció által kért információnak megfelelő kiszolgáló gyorsítótár-bejegyzés SDT-jének és az ügyféloldali 30 elfogómodultól fogadott, előre meghatározott időbeli összetartozási intervallumnak összegével.

Ha az aktuális idő és dátum kevesebb mint a kiszolgáló gyorsítótár-bejegyzés SDT-jének és az időbeli összetartozási intervallumnak az összege, akkor 130 lépésről az „IGEN” ágon haladunk tovább, és a kiszolgálóoldali 40 elfogómodullal összehasonlítjuk a kiszolgáló gyorsítótár-bejegyzés CRC-jét az ügyfél gyorsítótár-bejegyzés CRC-jével, annak meghatározására, hogy a két gyorsítótár-bejegyzés egymással azonos-e. Ha azonos, akkor a 135 lépésről az „IGEN” ágon haladunk tovább, és 136 lépésben „időbelileg összetartozó” választ küldünk az ügyféloldali 30 elfogómodulnak.

Ha a 135 lépésben állapítjuk meg, hogy a két vizsgált CRC nem egyenlő, akkor az ügyfél gyorsítótárban és a kiszolgáló gyorsítótárban tárolt információk nem azonosak. Ebben az esetben 137 lépésben a kiszolgálóoldali 40 elfogómodullal elküldjük a kiszolgáló gyorsítótár-bejegyzést a külső 35 átviteli vonalon keresztül az első 5 számítógépnek. A kiszolgáló gyorsítótár-bejegyzésnek az ügyféloldali 30 elfogómodulhoz való elküldése során a kiszolgálóoldali 40 elfogómodullal a bejegyzést átalakítjuk olyan ügyfél-specifikus kommunikációs protokollra, amely tartalmazza a kiszolgáló gyorsítótárbejegyzés CRC-jét, a kiszolgáló gyorsítótár-bejegyzés adatait, és a kiszolgáló gyorsítótár-bejegyzés korát, azaz létrejöttének időpontját. A kiszolgáló gyorsítótárbejegyzés korát úgy számítjuk ki, hogy a gyorsítótárbejegyzés SDT-jét kivonjuk az aktuális dátumból és időből.

Amennyiben vagy az SDT-nek és az előre meghatározott ügyfél időbeli összetartozási intervallumnak az összege kisebb, mint az aktuális dátum és idő, vagy nem létezik a 10 webböngészőtől származó kommunikáció URL-jének megfelelő gyorsítótár-bejegyzés, akkor a 130 lépésről, illetve a 125 lépésről a „NEM” ágon

HU 227 369 Β1 haladunk tovább, és 126 lépésben a kiszolgálóoldali 40 elfogómodullal HTTP adatfolyamként elküldjük a kiszolgálónak a 10 webböngészőtől származó kommunikációt. Ha a kiszolgálóoldali 40 elfogómodullal a 10 webböngészőtől származó kommunikációt HTTP adatfolyamként kell elküldenünk, akkor a kiszolgálóoldali 40 elfogómodullal a 6. ábra folyamatábráján vázolt műveleteket hajtjuk végre az alábbiak szerint.

140 lépésben válaszul a 10 webböngészőtől származó kommunikációra kiszolgálóoldali 40 elfogómodullal a 20 webkiszolgálótól HTTP adatfolyamot fogadunk. A HTTP adatfolyam megérkezésekor a kiszolgálóoldali 40 elfogómodullal kiszámítjuk a HTTP adatfolyam CRC-jét és átmenetileg taroljuk a HTTP adatfolyamot. Ezután 140 lépésben a kiszolgálóoldali 40 elfogómodullal megvizsgáljuk a HTTP adatfolyamot és megállapítjuk, hogy létezik-e a HTTP adatfolyam URLjének megfelelő kiszolgáló gyorsítótár-bejegyzés. Ha létezik ilyen bejegyzés, akkor a 145 lépésről az „IGEN” ágon haladunk tovább, és a kiszolgálóoldali 40 elfogómodullal összehasonlítjuk a 20 webkiszolgálótól fogadott HTTP adatfolyam újonnan kiszámolt CRC-jét a 20 webkiszolgáló által létrehozott válaszkommunikáció URL-jének megfelelő kiszolgáló gyorsítótár-bejegyzés CRC-jével 150 lépésben. Ha a két CRC egyezik, akkor 151 lépésben a kiszolgálóoldali 40 elfogómodullal aktualizáljuk a kiszolgáló gyorsítótár-bejegyzés SDT bejegyzését és a 20 webkiszolgáló által fogadott HTTP adatfolyamot kiürítjük 152 lépésben az átmeneti tárból.

Ha a CRC-értékek összehasonlítása azt az eredményt adja, hogy a kiszolgáló gyorsítótárbejegyzés eltérő a 20 webkiszolgálótól fogadott HTTP adatfolyamhoz képest, akkora 150 lépésről 153 lépésre térünk át, amelynek során a kiszolgálóoldali 40 elfogómodullal eltávolítjuk a kiszolgáló gyorsítótárból az adatokat, 154 lépésben az újabb adatokkal aktualizáljuk a kiszolgáló gyorsítótárat. Ez az aktualizálás magában foglalja a 20 webkiszolgáló kommunikációja CRC-jének a kiszolgáló gyorsítótárban való eltárolását, az aktuális dátumnak és időnek gyorsítótár-bejegyzés SDT-jeként a gyorsítótár-bejegyzésben való eltárolását és a HTTP adatfolyam eltárolását. Mindegyik esetben, akár aktualizáljuk a kiszolgáló gyorsítótár-bejegyzést, akár a 20 webkiszolgálótól fogadott HTTP adatfolyammal azonosnak bizonyul a kiszolgáló gyorsítótár-bejegyzés, a kiszolgálóoldali 40 elfogómodullal 155 lépésben megállapítjuk, hogy a kiszolgáló gyorsítótár-bejegyzés megegyezik-e a 10 webböngészőtől származó kommunikációnak megfelelő ügyfél gyorsítótár-bejegyzéssel.

Ha a kiszolgálóoldali 40 elfogómodullal azt állapítjuk meg, hogy nem létezik a 20 webkiszolgálótól fogadott válasznak megfelelő gyorsítótár-bejegyzés, akkor 145 lépés után 146 lépésben egy gyorsítótár-bejegyzést hozunk létre a 20 webkiszolgálótól fogadott válasz URL-jének, a 20 webkiszolgálótól fogadott válasz CRC-jének, magának a HTTP adatfolyamnak, valamint az aktuális dátumnak és időnek SDT-ként való eltárolásával. A 10 webböngészőtől származó kommunikációnak megfelelő gyorsítótár-bejegyzés elkészítését követően a kiszolgálóoldali 40 elfogómodullal 155 lépésben ismét összehasonlítjuk ennek a gyorsítótár-bejegyzésnek a CRC-jét az ügyfél gyorsítótár-bejegyzés CRC-jével.

Ha a kiszolgáló gyorsítótár-bejegyzés és az ügyfél gyorsítótár-bejegyzés összehasonlításának az eredménye azt jelzi, hogy a gyorsítótár-bejegyzések azonosak, akkor 156 lépésben a kiszolgálóoldali 40 elfogómodullal egy időben „összetartozó” választ küldünk az ügyféloldali 30 elfogómodulnak, valamint a kiszolgáló kérelem gyorsítótár-bejegyzés egy ügyfél-kiszolgáló specifikus adatfolyammá alakítjuk az ügyféloldali 30 elfogómodulnak küldött időben „összetartozó (azaz koherens) válasz elküldésével, valamint a friss létrejövetelre utaló nulla élettartam információt is elküldünk.

Ha a kiszolgálóoldali 40 elfogómodullal azt állapítjuk meg, hogy az ügyfél gyorsítótárbejegyzés nem azonos a 10 webböngészőtől származó kommunikációnak megfelelő kiszolgáló gyorsítótár-bejegyzéssel, akkor 155 lépésről a 157 lépésre térünk át, amelynek során a kiszolgálóoldali 40 elfogómodullal a kiszolgáló gyorsítótár-bejegyzést ügyfélkiszolgáló specifikus adatfolyammá alakítjuk át. Ez az adatfolyam tartalmazza a kiszolgáló gyorsítótár-bejegyzés CRC-jét, a kiszolgáló gyorsítótár-bejegyzés HTTP adatfolyamot és a gyorsítótár-bejegyzés korát, amely mint az előbb jeleztük nullára van állítva. Ezt az ügyfél-kiszolgáló specifikus kommunikációt a külső 35 átviteli vonalon keresztül továbbítjuk az ügyféloldali 30 elfogómodulhoz.

Az ügyféloldali 30 elfogómodul egy, a kiszolgálóoldali 40 elfogómodultól kapott kommunikációt követő működését a 4. ábra segítségével mutatjuk be. 160 lépésben az ügyféloldali 30 elfogómodullal a külső 35 átviteli vonalon keresztül fogadjuk az ügyfélkiszolgáló specifikus adatfolyamot. Az ügyféloldali 30 elfogómodullal ezután 165 lépésben megállapítjuk, hogy a kiszolgálóoldali 40 elfogómodultól milyen fajta kommunikációt kaptunk. Ha a kiszolgálóoldali 40 elfogómodul azt jelzi, hogy az ügyfél gyorsítótárbejegyzés időben összetartozó, azaz koherens, tehát a kiszolgáló gyorsítótár-bejegyzés és az ügyfél gyorsítótár-bejegyzés azonos, akkor 166 lépésben az ügyféloldali 30 elfogómodullal aktualizáljuk a 10 webböngészőtől származó kommunikációnak megfelelő ügyfél gyorsítótár-bejegyzés SDT-jét a kiszolgálóoldali 40 elfogómodultól kapott kor (élettartam), valamint az aktuális dátum és idő különbségének segítségével. így az első 5 számítógép és a második 6 számítógép óráinak összehangolása nélkül találmányunk segítségével ki tudjuk javítani az első 5 számítógép gyorsítótár-bejegyzésének összetartozási idejét úgy, hogy az a második 6 számítógép újabb adatait tükrözze. Miután a 10 webböngészőtől származó kommunikációnak megfelelő ügyfél gyorsítótár-bejegyzés SDT-jét aktualizáltuk, az ügyféloldali 30 elfogómodullal a gyorsítótár-bejegyzést HTTP adatfolyamként 174 lépésben a 10 webböngészőhöz továbbítjuk.

Ha a 165 lépésben azt állapítjuk meg az ügyféloldali 30 elfogómodul segítségével, hogy a válasz típusa adat vagy adatfolyam, akkor 167 lépésben fogadjuk a HTTP adatfolyamot és azt átmenetileg tároljuk. Ezt kö9

HU 227 369 Β1 vetően 170 lépésben az ügyféloldali 30 elfogómodullal megállapítjuk, hogy létezik-e a 10 webböngészőtől származó kommunikációnak megfelelő gyorsítótár-bejegyzés. Ha létezik ilyen gyorsítótár-bejegyzés, akkor

171 lépésben kiürítjük a létező gyorsítótár-bejegyzést, majd az ügyféloldali 30 elfogómodullal a 10 webböngészőtől származó kommunikációnak megfelelő ügyfél gyorsítótár-bejegyzést aktualizáljuk egyrészt a kiszolgálóoldali 40 elfogómodultól fogadott HTTP adatfolyam CRC-jének, másrészt a fogadott kor, továbbá az aktuális dátum és idő különbségének SDT-ként való, harmadrészt a HTTP adatfolyam eltárolásával, és mindezt

172 lépésben hajtjuk végre.

Ha a 10 webböngészőtől származó kommunikációnak megfelelő gyorsítótár-bejegyzés nem létezik, akkor 170 lépésről 173 lépésre térünk át, amelynek során az ügyféloldali 30 elfogómodullal egy ügyfél gyorsítótárbejegyzést készítünk a kiszolgálóoldali 40 elfogómodultól fogadott HTTP adatfolyam URL-jének, továbbá CRC-jének, valamint magának a HTTP adatfolyamnak az eltárolásával. Az ügyféloldali 30 elfogómodullal aktualizáljuk vagy eltároljuk továbbá az SDT-t, kivonva az aktuális dátumból és időből a külső 35 átviteli vonalon keresztül a kiszolgálóoldali 40 elfogómodultól kapott korinformáció értéket.

Akár a 166, akár 172, akár a 173 lépésben leírt műveletek révén készítünk ügyfél gyorsítótár-bejegyzést az ügyféloldali 30 elfogómodullal az ügyfél gyorsítótárbejegyzést HTTP adatfolyamként továbbítjuk vagy biztosítjuk a 10 webböngésző számára 174 lépésben.

Szakember számára kézenfekvő módon az ügyfélgyorsítótárak és a kiszolgáló gyorsítótárak megvalósíthatók pusztán félvezető memóriával, vagy ismert nagy kapacitású tárolóeszközök segítségével, például merevlemezekkel, újraírható CD-ROM-okkal, optikai lemezekkel vagy egyéb tárolási módszerek segítségével, sőt az ügyféloldali 30 elfogómodul és a kiszolgálóoldali 40 elfogómodul megvalósítható tisztán hardveresen, tisztán szoftveresen, vagy a kettő kombinációja révén is.

A találmány szerinti eljárás és rendszer eddigi ismertetése során a gyorsítótárra eddig mindig úgy utaltunk, mint valamilyen első vagy második 5, 6 számítógépben található egységre. Szakember számára azonban nyilvánvaló, hogy a találmány célkitűzései akkor is megvalósíthatók, ha a gyorsítótár nem az első vagy a második 5, 6 számítógépben van megvalósítva, hanem egyszerűen a külső 35 átviteli vonalnak ugyanazon oldalán található, mint az 5, 6 számítógép. Ebben az esetben az ügyfélgyorsítótárként szolgáló hardvergyorsítótár az első 5 számítógépen kívül is elrendezhető úgy, hogy nagy átviteli sebességű vonalon keresztül kötjük az első 5 számítógéphez, mégis ameddig a külső 35 átviteli vonalnak ugyanazon az oldalán található, mint az első 5 számítógép, a találmány szerinti előnyök ugyanúgy megvalósulnak.

A találmány szerinti rendszer egy másik lehetséges kiviteli alakjánál a kiszolgálóoldali 40 elfogómodullal nem képezünk és tartunk fenn másolatot a 20 webkiszolgálótól kapott HTTP adatfolyamról, hanem egyszerűen egy könyvtárbejegyzést tartunk fenn a kommunikáció számára. Ez a könyvtárbejegyzés tartalmazza a közlés URL-jét, a HTTP adatfolyamra kiszámított CRC-t, azt az időpontot, amikor a HTTP adatfolyamot fogadtuk a 20 webkiszolgálótól, valamint a CRC kiszámításának időpontja beállítható kommunikációs SDT-t. Ilyen esetben, ha az ügyféloldali 30 elfogómodullal a kiszolgálóoldali 40 elfogómodulnak olyan kommunikáció iránti kérelmet küldünk, amely megfelel egy URL-nek, amelynek a kiszolgálóoldali 40 elfogómodul fenntartotta a CRC-jét és az SDT-jét, akkor a kiszolgálóoldali 40 elfogómodullal ellenőrizzük az ügyféloldali 30 elfogómodultól kapott CRC-t, hogy megállapítsuk, megfelel-e annak a bizonyos URL-nek a legutolsó HTTP adatfolyama CRC-jének. Ha megfelel, akkor „koherens” választ küldünk az ügyféloldali 30 elfogómodulnak, ha pedig nem felel meg, akkor a kiszolgálóoldali 40 elfogómodullal elküldjük az ügyféloldali 30 elfogómodultól fogadott HTTP adatfolyamot a 20 webkiszolgálónak, és a 20 webkiszolgálótól fogadott választ küldjük vissza az ügyféloldali 30 elfogómodulnak.

A 7-10. ábrákon a találmány szerinti eljárás további lehetséges foganatosítási módját vázoljuk, amelynek során a külső 35 átviteli vonalon keresztül továbbítandó adatok csökkentésére különbözeti adatküldést (differenciális adatküldést) alkalmazunk. A 7. ábra 200 lépésében az ügyféloldali 30 elfogómodultól HTTP-kérelmet fogadunk a 10 webböngészőtől. 205 lépésben az ügyféloldali 30 elfogómodullal ezt a HTTP-kérelmet megvizsgáljuk és megállapítjuk, hogy a kérelem egy közös átjárófelületre (CGI) vonatkozik-e. Ha a kérelem nem egy közös átjárófelületre vonatkozik, akkor az ügyféloldali 30 elfogómodullal a kiszolgálóoldali 40 elfogómodulnak továbbítjuk a kérelmet 206 lépésben úgy, ahogy a 3-6. ábrák esetében is ismertettük.

Ha azonban a 10 webböngészőtől származó kommunikáció egy közös átjárófelületre vonatkozó kérelem, akkor 205 lépésről 210 lépésre térünk át, amelynek során az ügyféloldali 30 elfogómodullal megállapítjuk, hogy létezik-e ügyfélbázis gyorsítótár-bejegyzés, amely egy olyan HTTP adatfolyamnak felel meg, amelyet egy megfelelő CGI-kérelemre válaszul korábban továbbítottunk a 10 webböngészőnek. A CGI-kérelmet az ügyfélbázis gyorsítótár-bejegyzésben tárolt URL-ek és a 10 webböngészőtől származó kommunikáció URL-jének az összehasonlításával végezhetjük el.

Az ügyfélbázis-gyorsítótár az első ügyféloldali 30 elfogómodul által fogadott, a 10 webböngésző által egy bizonyos URL-re továbbítandó HTTP adatfolyam eltárolásával inicializálható. Ez az ügyfélbázis-gyorsítótár a 10 webböngésző többszöri, akár egyidejű használata során is fenntartható. Az ügyfélbázis gyorsítótárbejegyzések a 7-10. ábrák kapcsán leírtak szerint frissíthetők. Ha a 10 webböngészőtől származó kommunikáció URL-jének megfelelő ügyfélbázis gyorsítótár-bejegyzés létezik, akkor a külső 35 átviteli vonalon keresztül a kiszolgálóoldali 40 elfogómodulnak küldendő CRC-t egyenlővé tesszük az ügyfélbázis gyorsítótárbejegyzés CRC-jével a 211 lépésben. Ha nem létezik ügyfélbázis gyorsítótár-bejegyzés, akkor 212 lépésben

HU 227 369 Β1 a külső 35 átviteli vonalon keresztül a kiszolgálóoldali 40 elfogómodulnak küldendő kérelem CRC-jét lenullázzuk.

213 lépésben a CGI-kérelmet a külső 35 átviteli vonalon keresztül továbbítjuk a kiszolgálóoldali 40 elfogómodulhoz, mégpedig az ügyféloldali 30 elfogómodullal továbbítjuk egyrészt a HTTP-kérelmet, másrészt a kérelem CRC-jét, amelyet abban az esetben, ha nem létezett a CGI-kérelem URL-jének ügyfélbázis gyorsítótár-bejegyzése, akkor lenulláztunk, vagy ha létezett ilyen bejegyzés, akkor az ügyfélbázis gyorsítótár-bejegyzés CRC-jének értékére állítottuk. Ily módon az ügyféloldali 30 elfogómodullal a CGI-kérelmet ügyfél-kiszolgáló specifikus protokollá alakítottuk át, és ezt az ügyfél-kiszolgáló specifikus közlést, kommunikációt továbbítottuk a külső 35 átviteli vonalon keresztül a kiszolgálóoldali 40 elfogómodulhoz.

A kiszolgálóoldali 40 elfogómodul használatát egy CGI-kérelem vételekor a 9. ábra segítségével mutatjuk be. 220 lépésben a kiszolgálóoldali 40 elfogómodullal CGI-kérelmet fogadunk, és amikor azt megkapjuk, megtartjuk a HTTP-kérelem és a CRC érték egy-egy másolatát. 221 lépésben a kiszolgálóoldali 40 elfogómodullal a HTTP-kérelmet továbbítjuk 20 webkiszolgálónak.

Amikor a kiszolgálóoldali 40 elfogómodullal a 10 webböngészőtől származó kommunikációnak megfelelő HTTP-kérelemre vagy pedig a CGI-kérelemre választ kapunk, akkor a kiszolgálóoldali 40 elfogómodullal ezt a választ HTTP adatfolyamként fogadjuk 230 lépésben (lásd 10. ábra). Ekkor a kiszolgálóoldali 40 elfogómodullal megőrizzük a HTTP adatfolyamot, kiszámítjuk a 20 webkiszolgálótól fogadott HTTP adatfolyam CRC értékét. A kiszolgálóoldali 40 elfogómodullal a különbözeti értéket szintén lenullázzuk, a különbözeti érték inicializálása céljából. Ezt követően a kiszolgálóoldali 40 elfogómodullal megállapítjuk, hogy a 20 webkiszolgálótól származó kommunikációként fogadott válasz egy CGI-kérelemre jött-e a 235 lépésben. Ha nem CGI-kérelemre jött, akkor 236 lépésben a HTTP adatfolyamot elküldjük az ügyféloldali 30 elfogómodulnak, amelynek során a 3-6. ábrák kapcsán leírt módszereket is alkalmazhatjuk. Ha a 235 lépésben azt állapítjuk meg, hogy a kapott válasz egy CGI-kérelemre jött, akkor 240 lépésben a kiszolgálóoldali 40 elfogómodullal megállapítjuk, hogy a CGI-válasznak létezik-e kiszolgálóbázis gyorsítótár-bejegyzése.

Ilyen kiszolgálóbázis gyorsítótár-bejegyzés akkor is létrejöhet, amikor a kiszolgálóoldali 40 elfogómodullal először kapunk választ egy CGI-kérelemre. Ebben az esetben 241 lépésben a kiszolgálóoldali 40 elfogómodullal a CGI URL-jének, a CGI-kérelem URL-jének, a CGI-kérelemre válaszoló HTTP adatfolyamnak és a HTTP adatfolyam CRC-jének az eltárolásával elkészítjük a CGI-kérelemnek megfelelő kiszolgálóbázis gyorsítótár-bejegyzést. Annak érdekében, hogy a megoldás kompatibilis legyen 3-6. ábrákon bemutatott összetartozó gyorsítótárrendszerrel, a kiszolgálóbázis gyorsítótár-bejegyzésbe az SDT-t is belevehetjük. Leírásunk további részében a 10 webböngészőtől kapott

CGI-kérelemnek megfelelő kiszolgálóbázis gyorsítótárbejegyzést kiszolgáló CGI bázislapként fogjuk említeni.

Ha létezik a CGI-kérelemnek megfelelő kiszolgálóbázis gyorsítótár-bejegyzés, akkor 245 lépésben a kiszolgálóoldali 40 elfogómodullal összehasonlítjuk a kiszolgálóbázis gyorsítótár-bejegyzés CRC-jét a 20 webkiszolgálótól kapott válasz CRC-jével. Ha a CRC-k megegyeznek, akkor a kiszolgálóoldali 40 elfogómodullal megállapítjuk, hogy a kiszolgálóbázis gyorsítótárbejegyzés CRC-je megfelel-e az ügyfélbázis gyorsítótár-bejegyzés CRC-jének. Ha ez a két CRC-érték azonos, a kiszolgálóbázis gyorsítótár-bejegyzés, az ügyfélbázis gyorsítótár-bejegyzés és a 20 webkiszolgálótól kapott válasz mind-mind ugyanazt a HTTP adatfolyamot tartalmazza. A kiszolgálóbázis gyorsítótár-bejegyzést a 250 lépésben hasonlítjuk össze az ügyfélbázis gyorsítótár-bejegyzéssel.

Ha a két bázis gyorsítótár-bejegyzés azonos, akkor a kiszolgálóoldali 40 elfogómodullal nem kell a bázis gyorsítótár-bejegyzést elküldenünk az ügyféloldali 30 elfogómodulhoz, így 251 lépésben az ügyféloldali 30 elfogómodulnak küldendő HTTP adatfolyam adatait is lenullázzuk. A kiszolgálóoldali 40 elfogómodullal ezután a CGI-kérelemnek megfelelő kiszolgálóbázis gyorsítótárban tárolt HTTP adatfolyam CRC-jének a lenullázott HTTP adatfolyam adatainak és a lenullázott különbözeti adatnak az elküldésével a 20 webkiszolgálótól fogadott HTTP adatfolyamot ügyfél-kiszolgáló specifikus kommunikációs protokollra alakítjuk át 252 lépésben annak érdekében, hogy jelezzük, hogy a CGI-kérelemre érkezett válasz megegyezik az ügyfélbázis gyorsítótár-bejegyzéssel.

Visszatérve a 245 lépéshez, ha a CGI-kérelemnek megfelelő kiszolgálóbázis gyorsítótárbejegyzés CRC-je különbözik a 10 webböngészőtől származó CGI-kérelemre válaszoló, a 20 webkiszolgálótól kapott válasz CRC-jétől, akkor 246 lépésben a kiszolgálóoldali 40 elfogómodul összehasonlítja az elfogott CGI-választ és az elfogott CGI-kérelemnek megfelelő kiszolgálóbázis gyorsítótár-bejegyzést vagy kiszolgálóbázis CGI lapot, és az elfogott CGI-válasz és a kiszolgáló CGI bázislap összehasonlításával CGI-különbözeti adatot kapunk, amely megfelel az elfogott CGI-válasz és a kiszolgáló CGI bázislap különbségének.

A szakember általános köteles tudásához tartozó bármilyen módszerrel elvégezhető a bázislap és a módosított lap közötti különbségének meghatározása. A találmány szerinti eljárás egy lehetséges foganatosítási módjánál használt előnyös megkülönböztetési eljárás leírása megtalálható Coppieters: „Egy platformok közötti bináris megkülönböztetés’’ című cikkében (a Cross-Platform Binary Diff”, Dr. Dobb’s Journal, 1995. május, 32-36. old.), mely dokumentumot találmányunk tekintetében referenciaként tekintjük. A különbözeti adatok meghatározására szolgáló másik módszer ismerhető meg az IBM Technical Disclosure Bulletin, Vol. 22, No. 8A, 1980. januári számában, amelyet találmányunk tekintetében szintén referenciaként tekintünk.

247 lépésben ezt követően a kiszolgálóoldali 40 elfogómodullal meghatározzuk, hogy a kiszolgáló CGI

HU 227 369 Β1 bázislap igényel-e frissítést, és ezt annak alapján végezzük el, hogy a kapott CGI-válasz és a kiszolgáló CGI bázislap közötti átlag különbözeti adat nagyobb-e az előre meghatározott küszöbértéknél. Egyéb, a CGIkérelemnek megfelelő kiszolgálóbázis gyorsítótár-bejegyzés aktualizálásának, frissítésének szükségességét meghatározó módszerként használhatjuk a 3-6. ábrák kapcsán leírt idő-összetartozási módszert, vagy más, szakember számára ismert eljárást is, amellyel meg tudjuk állapítani, hogy a különbözeti adat megnőtt-e annyira, hogy a bázislap újraalapozásával egy új bázis gyorsítótárbejegyzés készítése javítaná-e a rendszer teljesítményét.

Ha a kiszolgálóbázis újraalapozására nincs szükség, akkor 250 lépésben a kiszolgálóoldali 40 elfogómodullal meghatározzuk, hogy az ügyfélbázis gyorsítótár-bejegyzés CRC-je azonos-e a kiszolgálóbázis gyorsítótár-bejegyzés CRC-jével, vagy a kiszolgálóbázislap megegyezik-e az ügyfélbázislappal, mely lapok a kiszolgáló és az ügyfélbázis gyorsítótár-bejegyzései, amelyek a 10 webböngészőtől származó kommunikáció egy bizonyos CGI-kérelmének felelnek meg. Ha az említett bázislapok megegyeznek, akkor az ügyfél bázislapján nem kell újraalapozni, és 251 lépésben a HTTP adatfolyamot lenullázzuk. Ezt követően 252 lépésben a kiszolgálóoldali 40 elfogómodullal a különbözeti választ elküldjük az ügyféloldali 30 elfogómodulnak, pontosabban a CGI-kérelemnek megfelelő kiszolgálóbázis gyorsítótár-bejegyzés CRC-jét (a kiszolgáló CGI bázislap CRC-jét), a bázisadatnak megfelelő lenullázott HTTP adatfolyamot, valamint a 246 lépésben meghatározott különbözeti adatot elküldjük.

Ha a kiszolgálóoldali 40 elfogómodullal megállapítjuk, hogy a kiszolgálóbázis-lap CRC-je az ügyfél CGI bázislap CRC-je nem azonos, akkor az ügyfél bázislapját újra kell alapoznunk. Az ügyfél bázislapjának az újraalapozása során a kiszolgáló CGI bázislapot elküldjük az ügyféloldali 30 elfogómodulhoz. A művelet elvégzése érdekében 253 lépésben a kiszolgálóoldali 40 elfogómodullal az ügyféloldali 30 elfogómodulhoz küldendő adatfolyam adatait egyenlővé tesszük a kiszolgáló CGI bázislappal. Ezt követően a kiszolgálóoldali 40 elfogómodullal átalakítjuk a 20 webkiszolgálótól kapott HTTP adatfolyamot egy ügyfél-kiszolgáló specifikus protokollra a kiszolgáló CGI bázislap CRC-jének az elküldése, a kiszolgáló CGI bázislapnak megfelelő HTTP adatfolyam adatainak elküldése, és a 20 webkiszolgálótól fogadott válasz és a kiszolgáló CGI bázislap közötti különbség elküldése útján a 252 lépésben. Ezt az információt a külső 35 átviteli vonalon keresztül továbbítjuk az ügyféloldali 30 elfogómodulhoz.

Visszatérve még a 247 lépésre, ha szükség van a kiszolgáló bázislapjának az újraalapozására, akkor 248 lépésben a kiszolgálóoldali 40 elfogómodullal aktualizáljuk a 10 webböngészőtől származó kommunikációnak megfelelő kiszolgálóbázis gyorsítótár-bejegyzést a 20 webkiszolgálótól kapott HTTP adatfolyammal. A válasz CRC-jét ugyancsak frissítjük, és nullázzuk a CGI-különbséget. Ezt követően a kiszolgálóoldali 40 elfogómodullal 250 lépésben összehasonlítjuk az új kiszolgálóoldali gyorsítótár-bejegyzést, és az adatokat a fent leírt módon továbbítjuk.

A 8. ábra segítségével az ügyféloldali 30 elfogómodul használatát mutatjuk be a kiszolgálóoldali 40 elfogómodul egy válaszának a fogadása esetén. A kiszolgálóoldali 40 elfogómodultól származó választ 260 lépésben fogadjuk az ügyféloldali 30 elfogómodullal, majd 265 lépésben az ügyféloldali 30 elfogómodullal megállapítjuk, hogy a válasz egy CGI-kérelemre érkezett-e. Ha a válasz nem egy CGI-kérelemre jött, akkor az ügyféloldali 30 elfogómodullal 267 lépésben a HTTP választ továbbítjuk a 10 webböngészőnek, és ennek során végrehajthatjuk a 3-6. ábrák kapcsán leírt gyorsítótár-műveleteket is, ha azonban a válasz egy CGIkérelemre érkezett, akkor 266 lépésben az ügyféloldali 30 elfogómodullal megtartjuk a HTTP adatfolyam adatait, a különbözeti adatot és a külső 35 átviteli vonalon keresztül továbbított ügyfél-kiszolgáló specifikus adatfolyamból szerzett CRC-t.

Ezt követően 270 lépésben az ügyféloldali 30 elfogómodullal, a HTTP-kérelem vagy válasz URL-jének vizsgálatával meghatározzuk, hogy létezik-e egy, a vett CGI-kérelemnek megfelelő ügyfélbázis gyorsítótár-bejegyzés, amely egy ügyfél CGI bázislapot tartalmaz. Ha létezik ilyen ügyfélbázislap, akkor 275 lépésben az ügyféloldali 30 elfogómodullal a külső 35 átviteli vonalon keresztül vett CRC-t összehasonlítjuk az ügyfél CGI bázislapjának a CRC-jével. Ha itt különbséget találunk, akkor 276 lépésben a CGI bázislap frissítésével újraalapozzuk az ügyfél bázislapját úgy, hogy a 10 webböngészőtől származó közlés CGI-kérelme URL-jének megfelelő ügyfélbázis gyorsítótár-bejegyzést kicseréljük a kiszolgálóoldali 40 elfogómodultól a külső 35 átviteli vonalon keresztül vett HTTP adatfolyamra. Az ügyfélbázis gyorsítótár-bejegyzést a HTTP adatfolyam CRC-re nézve is felfrissíti.

Ha a külső 35 átviteli vonalon keresztül vett CRC ugyanaz, mint a CGI bázislap CRC-je, akkor a kiszolgálóoldali 40 elfogómodul kiszolgáló CGI bázislapja megegyezik az ügyféloldali 30 elfogómodul ügyfélbázislapjával, és ebben az esetben 275 lépésről 277 lépésre térünk át, amelynek során függetlenül attól, hogy a bázislapok megegyeznek-e, az ügyfél bázislapjának újraalapozását végezzük, az ügyféloldali 30 elfogómodullal rekonstruáljuk a 20 webkiszolgálótól érkezett kommunikációnak megfelelő HTTP adatfolyamot a külső 35 átviteli vonalon keresztül vett ügyfél-kiszolgáló specifikus adatokból, az ügyfél CGI bázislapnak és a külső 35 átviteli vonalon keresztül vett CGI-különbözeti adatoknak a kombinálásával, egy, a CGI-válasznak megfelelő HTTP adatfolyam létrehozásához. Ezt a választ 278 lépésben HTTP adatfolyamként küldjük meg a 10 webböngészőnek.

Amennyiben az ügyfélnek nincs a CGI-kérelem URL-jéhez megfelelő CGI bázislapja, akkor 270 lépést követően 271 lépésben az ügyféloldali 30 elfogómodullal létrehozunk egy, a CGI-kérelem URL-jének megfelelő ügyfélbázis gyorsítótár-bejegyzést az URL tárolásával, valamint a kiszolgálóoldali 40 elfogómodultól a külső 35 átviteli vonalon keresztül vett HTTP adatfo12

HU 227 369 Β1 lyam CRC-je, és magának a HTTP adatfolyamnak az eltárolásával. Ezen információ eltárolásával létrehozunk egy gyorsítótár-bejegyzést a vett CGI-kérelemnek megfelelően, és ezzel létrehozzuk a CGI bázislapot. Ezt követően az ügyféloldali 30 elfogómodullal 277 lépésben rekonstruáljuk a HTTP adatfolyamot az ügyfél CGI bázislap és az esetleg hatálytalanná vált CGI-különbözeti adatok egyesítésével vagy összevonásával.

Ezeket a különbözeti eljárásokat nem CGI adatokra is alkalmazhatjuk. Ilyen helyzetben a kiszolgálóoldali 40 elfogómodullal a kiszolgálóbázis gyorsítótár-bejegyzések több generációját kell eltárolnunk, hogy felkészülhessünk arra az esetre, ha a 10 webböngészőnek a 20 webkiszolgálóhoz kapcsolt ügyféloldali elfogómoduljai különböző bázislapokat tartalmaznak. A kiszolgálóoldali 40 elfogómodullal ekkor összehasonlíthatjuk az ügyféloldali 30 elfogómodultól kapott CRC-t a kiszolgálóbázis-lapok korábbi generációinak CRC-ivel, amíg egyezést nem találunk, ezt követően a kiszolgálóoldali 40 elfogómodullal vagy újraalapozzuk az ügyféloldali 30 elfogómodul bázislapját, vagy pedig egyszerűen elküldjük a különbözeti adatot az ügyféloldali 30 elfogómodulnak. így az itt leírt, a CGI-kérelmekkel kapcsolatos különbözeti eljárásokat ugyanúgy alkalmazhatjuk HTTP-kérelmekre és válaszokra is.

Jóllehet a fent vázolt, a bázislapok több generációját fenntartó rendszer lehetővé teszi a különbözeti adatküldést nem CGI-kérelmek esetén is, ez a módszer azonban több memóriát és nagyobb tárolókapacitást igényel, és nem használja ki teljesen a vázolt gyorsítási képességeket. A memória- vagy társzükséglet csökkentése és a vázolt gyorsítási módszerek kihasználása érdekében a nem CGI-kérelmek körében a különbözeti adatküldéshez a következőkben vázolt eljárást alkalmazhatjuk, amelynek során a kiszolgálóoldali 40 elfogómodullal számítjuk ki a kérelemnek megfelelő kiszolgálóbázis-lap és a 20 webkiszolgálótól válaszként kapott HTTP adatfolyam közötti különbséget. Ezt követően a kiszolgálóoldali 40 elfogómodullal eltároljuk ezt a különbözeti adatfolyamot, majd a kiszolgálóbázislapot a bázislapnak a 20 webkiszolgálótól kapott új válaszra történő kicserélésével frissítjük, beleértve a bázislap CRC-jének a frissítését is. Ezen túlmenően a régi CRC elhagyása helyett az előző bázislapok CRC-i is tárolásra kerülnek a különbözeti adattal együtt, és a különbözeti adatokat és a CRC-k megelőző generációit kiválogatva továbbítjuk az ügyféloldali 30 elfogómodulhoz a nem CGI-kérelemnek megfelelő ügyfélbázislap CRC-je alapján.

A nem CGI-különbözeti eljárásra példaként olyan foganatosítási módot említhetünk, ahol ha a kiszolgálóoldali 40 elfogómodullal egy nem CGI-kérelmet veszünk, akkor ezt a kérelmet a nem CGI-kérelem URLjének megfelelő ügyféloldali 30 elfogómodulban található bázislap CRC-je kísérné. Amikor a kiszolgálóoldali 40 elfogómodullal megkapjuk a választ a 20 webkiszolgálótól, akkor kiszámítjuk a válasz CRC-jét, majd kiszámítjuk a különbséget a válasz és az URLhez tartozó kiszolgálóbázis-lap között, és a különbözeti adatot elmentjük. Ezután a kiszolgálóoldali 40 elfogómodullal frissítjük a kiszolgálóbázis-lapot az új válasz adataival, és tároljuk az előző bázislap CRC-jét, valamint a válasz és a régi bázislap közötti különbözeti adatot. Ezt követően a kiszolgálóoldali 40 elfogómodullal összehasonlítjuk az ügyfélbázislap CRC-jét a kiszolgáló-bázislap CRC-jével és bármilyen más, tárolt vagy archivált CRC-vel, és megvizsgáljuk, hogy van-e egyezés, amennyiben nem találunk egyezést, úgy a választ egyszerűen elküldjük az ügyféloldali 30 elfogómodulnak.

Ha azonban egyezést találunk, a CRC találatnak megfelelő különbözeti adatot és minden későbbi különbözeti adatot a jelenlegi különbözeti adatig bezárólag elküldünk az ügyféloldali 30 elfogómodulnak, amellyel ezt követően ráillesztjük a különbözeti adatot az ügyfélbázislapra, hogy rekonstruálni tudjuk a választ. így tehát, ha a CRC egy három generációval régebbi bázislap CRC-jével érkezett, akkor három különbözeti adathalmazt küldünk el az ügyféloldali 30 elfogómodulhoz, és a válasz összeállítása során három egymást követő különbözeti adathalmazt illesztünk az ügyfélbázislapra. Ha azonban a válasz konstruálásához szükséges különbözeti adathalmazok száma vagy mérete olyan nagy, hogy a tulajdonképpeni válasz elküldése kisebb adatátvitelt jelentene, akkor a kiszolgálóoldali 40 elfogómodullal magát a választ küldjük el. Bármelyik esetben a válasz rekonstruálása vagy vétele során az ügyféloldali 30 elfogómodullal frissítjük a kérelem URL-jének ügyfélbázislapját a válaszadattal, és frissítjük a CRC-t is a válasz CRC-jével. Mivel az ügyfélbázislap minden egyes alkalommal frissítésre kerül, ha válasz érkezik egy bizonyos URL-től, a fent bemutatott ügyfélgyorsítótárat ügyfélbázislap-gyorsítótárként használhatjuk, kiiktatva ezzel egy külön gyorsítótárat az ügyfélbázislapok számára, a nem CGI-kérelmeknél különbözeti eljárást használunk.

A találmány szerinti eljárás egy további lehetséges foganatosítási módja értelmében további megtakarításokat érhetünk el az adatátvitelben egy olyan állapot nélküli, hontalan kommunikációs protokoll redundanciája alapján, mint a HTTP. Egy ilyen protokollban az ügyfél minden egyes alkalommal, amikor közlést kezdeményez, információt továbbít magáról a kiszolgálónak, és ugyanígy, a kiszolgáló minden egyes alkalommal, amikor egy választ elindít, bizonyos információt közöl magáról az ügyfélnek.

A találmány szerinti rendszer egy további lehetséges kiviteli alakjánál az első 5 számítógép közli a második 6 számítógéppel az első 5 számítógép előre meghatározott jellemzőinek megfelelő számítógépspecifikus információt, amely azt eltárolja. Az első számítógép ezután ezt a már megadott számítógépspecifikus információt elhagyja a 10 webböngészőtől származó, ezt követő közlésekből a külső 35 átviteli vonalon át történő továbbítást megelőzően. A második számítógép az eltárolt számítógép-specifikus információk, és az ezt követő, a külső 35 átviteli vonalon át vett kommunikáció összevonásával felépíti az eredetileg a 10 webböngészőtől származó kommunikációt, és létrehoz egy HTTP adatfolyamot.

HU 227 369 Β1

A számítógép-specifikus információnak a 10 webböngészőtől származó kommunikációkból való elhagyásán túlmenően ezt a számítógép-specifikus információt a 20 webkiszolgálótól származó közlésekből is elhagyhatjuk. Ilyen esetben a második 6 számítógép a 2. ábrán feltüntetett tömbvázlat szerint külső 35 átviteli vonalon keresztül juttatja el az első 5 számítógépnek a második 6 számítógép előre meghatározott jellemzőinek megfelelő számítógép-specifikus információt. Az első 5 számítógép ezt a számítógép-specifikus információt a kiszolgáló fejlécinformációjaként eltárolja. Az ezt követő kommunikációk során a második 6 számítógép a 20 webkiszolgálótól származó közlésekből szintén elhagyja a számítógép-specifikus információt, és a külső 35 átviteli vonalon át továbbítja a 20 webkiszolgálótól származó közlés megmaradt részét. Az első 5 számítógép veszi a közlést a külső 35 átviteli vonalon keresztül és felépíti az eredeti, a 20 webkiszolgálótól származó közlést, a kiszolgáló fejléc-információ és a külső 35 átviteli vonalon át fogadott ügyfél-kiszolgáló specifikus adat összevonásával, hogy létrehozzon egy kért HTTP adatfolyamot. Mindkét esetben, tehát vagy kiszolgáló fejléc-információ, vagy ügyfél fejléc-információ létrehozása céljából a számítógép-specifikus információ elhagyását és az információ tárolását vagy az ügyféloldali 30 elfogómodul, vagy a kiszolgálóoldali 40 elfogómodul hajtja végre attól függően, hogy a művelet az első 5 számítógépben vagy a második 6 számítógépben zajlik le.

A találmány szerinti rendszer egy további lehetséges kiviteli alakjánál a 10 webböngésző az ügyféloldali 30 elfogómodullal TCP/IP protokoll útján kommunikál. A TCP-t az ügyféloldali 30 elfogómodul és a kiszolgálóoldali 40 elfogómodul közötti kommunikációra is felhasználhatjuk a külső 35 átviteli vonalon keresztül, valamint a kiszolgálóoldali 40 elfogómodul és a 20 webkiszolgáló közötti kommunikációra is felhasználhatjuk. Jóllehet a találmány szerinti rendszer részét alkotó egységek közötti kommunikációra TCT-t használhatunk, külső 35 átviteli vonalon keresztül a HTTP protokoll nem bizonyult a leghatékonyabb kommunikációs eszköznek. A külső 35 átviteli vonal teljesítményének a növelésére a találmány értelmében „virtuális szoftvercsatornákat’’ hozunk létre, amelyek a 10 webböngésző és az ügyféloldali 30 elfogómodul, valamint a kiszolgálóoldali 40 elfogómodul és a 20 webkiszolgáló közötti kommunikációra használhatók. A virtuális szoftvercsatornák felépítését és működését a 11-17. ábrák segítségével mutatjuk be az alábbiakban.

A 11. ábrán a találmány szerinti rendszer olyan lehetséges kiviteli alakjának tömbvázlata látható, amelyben virtuális szoftvercsatornákat használunk. Az első 5 számítógép és a második 6 számítógép a külső 35 átviteli vonalon keresztül kapcsolódik egymáshoz. A 10 webböngésző valódi szoftvercsatornák sokaságával rendelkezik, amelyekkel az ügyféloldali 30 elfogómodulhoz csatlakozik. A 10 webböngészőben az első valódi 65A szoftvercsatornát, az ügyféloldali 30 elfogómodulban pedig az ennek megfelelő 65B szoftvercsatornát mutatjuk be. Az első valódi 65A szoftvercsatorna az a TCP 65 szoftvercsatorna, amelyen keresztül a 10 webböngésző további csatlakozásokat kérelmez az ügyféloldali 30 elfogómodultól.

Amikor a 10 webböngésző egy új TCP kapcsolatot kérelmez, egy közlés (kommunikáció) zajlik a valódi 65A szoftvercsatornán keresztül, amelyet a 65B szoftvercsatorna fogad. Az ügyféloldali 30 elfogómodul ennek alapján egy további valódi szoftvercsatornát hoz létre a 10 webböngészővel folytatandó kommunikációhoz. Mint az ábrán látható, a 10 webböngészőben számos valódi 60A, 64A szoftvercsatorna jön létre, és mindegyiknek megfelelően egy további 60B-64B szoftvercsatorna létezik az ügyféloldali 30 elfogómodulban. Ezek a 60A-65B szoftvercsatornák azok az eszközök, amelyeken keresztül a 10 webböngésző és az ügyféloldali 30 elfogómodul egymással kommunikál. A 60A-64B szoftvercsatornák létrehozása után az ezen keresztül zajló kommunikációk multiplexeit állapotban valódi 36A szoftvercsatornára kerülnek, amely elérést biztosít az ügyféloldali 30 elfogómodulnak egy külső 35 átviteli vonalhoz. A valódi 36A, 36B szoftvercsatornák akkor jönnek létre, amikor az első 5 számítógép valódi 37A szoftvercsatornáján keresztül kérelmet küld a második 6 számítógép valódi 37B szoftvercsatornájának. Amint a valódi 37B szoftvercsatorna veszi a csatlakozási kérelmet, létrejönnek a 36A, 36B szoftvercsatornák. A valódi 37A, 37B szoftvercsatornák az ügyféloldali 30 elfogómodul és a kiszolgálóoldali 40 elfogómodul közötti kommunikáció első valódi szoftvercsatornáiként viselkednek, és csak a 36A, 36B szoftvercsatornák által képviselt 30, 40 elfogómodul csatlakoztatására szabad azokat használni. Ezeknek a 36A-37B szoftvercsatornáknak mindegyike szabványos TCP/IP protokollt használ. Amikor a második 6 számítógép kommunikációt fogad a külső 35 átviteli vonalon keresztül, akkor a valódi 36B szoftvercsatornán keresztül veszi azt. A kiszolgálóoldali 40 elfogómodul ezután szétválasztja a valódi 36B szoftvercsatornán vett kommunikációkat, közléseket, és átadja azokat a 20 webkiszolgálóhoz való továbbítás céljából a megfelelő 60C-64D szoftvercsatornáknak, így például, ha a 60A szoftvercsatornáról a 60B szoftvercsatornára érkezik közlés, például egy meghatározott URL-ről való információ iránti kérelem, akkor az a 36A szoftvercsatornán multiplexelve a 36B szoftvercsatornára érkezik, a kiszolgálóoldali 40 elfogómodul szétválasztja, majd a 60C és 60D szoftvercsatornákon keresztül kerül tovább a 20 webkiszolgálóhoz. Ugyanígy, a 61A szoftvercsatornán keresztül érkező közléseket a 61B szoftvercsatorna fogadja, az ügyféloldali 30 elfogómodul multiplexen, majd a 36A szoftvercsatornától a 36B szoftvercsatornához továbbítja, ahol a kiszolgálóoldali 40 elfogómodul a közlést szétválasztja, és szétválasztottan továbbítja a 61C szoftvercsatornán keresztül a 61D szoftvercsatornához. Tehát a 60A-64B szoftvercsatornákon keresztüli kommunikációka hozzájuk tartozó 60A-64B szoftvercsatornákon kerülnek továbbításra a kiszolgálóoldali 40 elfogómodul és a 20 webkiszolgáló között a 60C és 60D, a 61C és 61D, a 62C és 62D, a 63C és 63D, valamint a 64C és 64D szoftvercsatornákon át.

HU 227 369 Β1

A 20 webkiszolgálónak a 10 webböngésző kérelmeire adott válaszai hasonlóképpen a 20 webkiszolgálót a kiszolgálóoldali 40 elfogómodullal összekötő 60C-64D szoftvercsatornákon keresztül kerülnek továbbításra, majd jutnak a külső 35 átviteli vonalon át az ügyféloldali 30 elfogómodulhoz és végül a 10 webböngészőhöz. Tehát például egy a 20 webkiszolgálótól származó válasz a 60D szoftvercsatornán keresztül a 60C szoftvercsatornához érkezik, onnan a kiszolgálóoldali 40 elfogómodul a 36B szoftvercsatornára multiplexen, ahonnan a külső 35 átviteli vonalon keresztül a 36A szoftvercsatornához kerül. Az ügyféloldali 30 elfogómodul ezután szétválasztja az érkezett közlést és átadja a 60B szoftvercsatornának a 10 webböngészőben lévő 60A szoftvercsatornához történő továbbítás céljából. Hasonló kommunikációs útvonal jön létre a 10 webböngésző és a 20 webkiszolgáló által használt minden egyes 60A-64D szoftvercsatorna esetében. Ugyan a találmány szerinti rendszer a 10 webböngésző és a 20 webkiszolgáló közötti négy csatlakozás bemutatása révén került ismertetésre, de szakember számára nyilvánvaló, hogy a 10 webböngésző és a 20 webkiszolgáló közötti kommunikáció biztosítására akármennyi 60A-65B szoftvercsatornát megnyithatunk.

A 12. ábrán az ügyféloldali 30 elfogómodulban és a kiszolgálóoldali 40 elfogómodulban kialakított virtuális 36A, 36B, 37A, 37B, 60B, 60C, 61B, 61C, 62B, 62C, 63B, 63C, 64B, 64C, 65B szoftvercsatorna-rendszert tüntettük fel tömbvázlat szinten. Az ügyféloldali 30 elfogómodulon és a kiszolgálóoldali 40 elfogómodulon kívül az ügyféloldali 30 elfogómodul és a 10 webböngésző között, valamint a kiszolgálóoldali 40 elfogómodul és a 20 webkiszolgáló között ezek a 36A, 36B, 37A, 37B, 60B, 60C, 61B, 61C, 62B, 62C, 63B, 63C, 64B, 64C, 65B szoftvercsatornák hagyományos TCP/IP szoftvercsatornaként működnek, így a virtuális szoftvercsatornák használata sem a 10 webböngésző, sem a 20 webkiszolgáló számára nem jelent akadályt.

A találmány szerinti egy további lehetséges kiviteli alakját részben a 12. ábra tömbvázlata, részben a 13-17. ábrákon bemutatott folyamatábrák segítségével ismertetjük részletesebben. A 13. ábrán a 12. ábra 68 csatorna kezelőjének működését tüntettük fel. A 13. ábra 300 lépésében létrehozzuk az ügyféloldali 30 elfogómodul valódi 68 szoftvercsatorna kezelőjét, majd annak létrejötte után létrehozunk egy első valódi 65B szoftvercsatornát a 301 lépésben. Az első valódi 65B szoftvercsatorna létrehozását követően az ügyféloldali 30 elfogómodulban létrehozott 68 szoftvercsatorna-kezelővel - amelyet akár ügyfélszoftvercsatornakezelőnek is nevezhetnénk - eseményre várunk az első valódi 65B szoftvercsatornán a 302 lépésben, majd 305 lépésben a valódi 68 szoftvercsatorna-kezelővel akkor, amikor az első valódi 65B szoftvercsatornán át érkező eseményt észlelünk, azt megvizsgáljuk és a vizsgálat eredményeképpen öt lehetőség közül kiválasztunk egyet, az alábbiak szerint.

Ha az első valódi 65B szoftvercsatornán vett közlési kérelemre válaszként valódi szoftvercsatorna jön létre, akkor 306 lépésben a valódi 68 szoftvercsatornakezelővel felvesszük ezt a létrejövő valódi szoftvercsatornát a valódi események listájára. A valódi 68 szoftvercsatorna-kezelővel ezután létrehozunk 307 lépésben egy egyirányú virtuális szoftvercsatornát, és az ügyféloldali 30 elfogómodul esetében a 68 szoftvercsatorna-kezelővel olyan szoftveres működést kezdeményezünk, amellyel elvégezzük az ügyféloldali 30 elfogómodul feladatát 308 lépésben a virtuális szoftvercsatorna számára.

Az előző bekezdésben használt „egyszeres szoftvercsatorna” vagy „egyszeres virtuális szoftvercsatorna kifejezések alatt olyan szoftvercsatornát értünk, amely közvetlenül vagy egyetlen szoftvercsatornához vagy egyetlen alkalmazáshoz csatlakozik. A leírásunkban használt „multiplex szoftvercsatorna” pedig olyan szoftvercsatornára vonatkozik, amely más szoftvercsatornák sokaságához csatlakozik, tehát multiplexelő vagy demultiplexelő feladatot hajt végre, míg az egyszeres szoftvercsatorna közvetlen csatlakozást valósít meg. így például a 306-308 lépések végrehajtásához a valódi 68 szoftvercsatorna-kezelővel az első valódi 65B szoftvercsatorna által vett első csatlakozási kérelemre válaszul létrehozzuk a valódi 60B szoftvercsatornát, az egyszeres virtuális 70 szoftvercsatornát, és egy 80 ügyféloldali elfogóalkalmazást indítunk. Hasonlóan az ezt követő eseményeknél, amikor egy valódi szoftvercsatorna jön létre, a valódi 68 szoftvercsatorna-kezelővel létrehozzuk a valódi 61 Β, 62B, 63B, 64B szoftvercsatornákat és az egyszeres virtuális 71, 72, 73, 74 szoftvercsatornákat, valamint a valódi és virtuális 61 Β, 62B, 63B, 64B, 71, 72, 73, 74 szoftvercsatornáknak megfelelően 81,82, 83, 84 ügyféloldali elfogóalkalmazást indítunk.

A 12. ábrán 80 ügyféloldali elfogóalkalmazást is mutattuk a valódi 60B szoftvercsatorna, az egyszeres virtuális 70 szoftvercsatorna szempontjából. A 14. ábrán 325 lépésben 80 ügyféloldali elfogóalkalmazást indítunk, amely létrejöttekor 326 lépésben az egyszeres virtuális 70 szoftvercsatornán egy eseményre várunk. Ezt a várakozást a 16-4. ábrán bemutatott virtuális kiválasztási művelettel hajtjuk végre. Ha eseményt észlelünk, úgy a 330 lépésben azt megvizsgáljuk, és ha az esemény egy virtuális szoftvercsatorna lezárásának bizonyul, akkora 80 ügyféloldali elfogóalkalmazással töröljük az egyszeres virtuális 70 szoftvercsatornát a 349 lépésben, majd azt 350 lépésben megszűntnek tekintjük.

Ha az esemény nem virtuális szoftvercsatorna lezárás, hanem például adat vétele, akkor 331 lépésben a 80 ügyféloldali elfogóalkalmazással fogadjuk a 10 webböngészőtől származó közlést az egyszeres virtuális 70 szoftvercsatornán keresztül 16-3. ábrán bemutatott virtuális fogadó művelettel. A 80 ügyféloldali elfogóalkalmazással az ügyféloldali 30 elfogómodul feladatát végrehajtjuk a fentiek szerint (ehhez lásd például a 3. és 7. ábrát is), majd a 332 lépésről továbblépve a 80 ügyféloldali elfogóalkalmazással létrehozunk egy multiplex virtuális 90 szoftvercsatornát, amelyet az ügyféloldali 30 elfogómodulban a valódi 36A szoftver15

HU 227 369 Β1 csatornához csatlakoztatunk. A valódi 36A szoftvercsatornát a kiszolgálóoldali 40 elfogómodul valódi 36B szoftvercsatornájához csatlakoztatjuk. A multiplex virtuális 90 szoftvercsatornát a 333 lépésben hozzuk létre a 16-1. ábrák szerint tárgyalt virtuális létrehozási művelettel, míg 334 lépésben a 10 webböngészöböl vett információt a 60B szoftvercsatornán keresztül elküldjük az egyszeres virtuális 70 szoftvercsatornához, miután a 80 ügyféloldali elfogóalkalmazás befejeződött a 10 webböngészőtől származó kommunikáción. Ezt a kommunikációt a 16-2. ábrán bemutatott virtuális küldési művelettel várakozási sorba állítjuk a multiplex virtuális 90 szoftvercsatornában, és miután a kérelmet a multiplex virtuális 90 szoftvercsatornában várakozási sorba állítottuk, a 80 ügyféloldali elfogóalkalmazással a 335 lépésben kiürítjük a várakozási sorba állított adatokat, majd 336 lépésben egy következő eseményre várunk a multiplex virtuális 90 szoftvercsatornán. A virtuális kiürítést a 17-1. ábrán bemutatott módon hajtjuk végre, amelynek során az adatokat a multiplex virtuális 90 szoftvercsatorna várakozási sorából kivesszük, és átadjuk a valódi 36A szoftvercsatornának. A várakozást a 16^4. ábrák kapcsán bemutatott virtuális kiválasztási művelettel hajtjuk végre. Az elvégzett műveletek után az ügyféloldali 30 elfogómodul a 10 webböngészőtől vette az érkező közlést, és továbbította azt a kiszolgálóoldali 40 elfogómodulnak a külső 35 átviteli vonalon keresztül.

A 13. ábrán az ügyféloldali 30 elfogómodulban, illetve a kiszolgálóoldali 40 elfogómodulban lévő 68, illetve 69 szoftvercsatorna-kezelő működését mutatjuk be. A kiszolgálóoldali 40 elfogómodulban kialakított valódi 69 szoftvercsatorna kezelő ugyanazt a feladatot tölti be, mint az ügyféloldali 30 elfogómodul valódi 68 szoftvercsatorna kezelője. Amint a 301 lépésben létrehozzuk az első valódi 37A szoftvercsatornát, a kiszolgálóoldali 40 elfogómodulban is létrehozunk egy „jól ismert” 37B szoftvercsatornát a kiszolgálóoldali 40 elfogómodullal kapcsolatos szoftvercsatorna-kérelmek vételére, amelyek az ügyféloldali 30 elfogómodultól érkeznek. Amikor a kiszolgálóoldali 40 elfogómodul valódi 36B szoftvercsatornáján valódi esemény történik, akkor azt a 305 lépésben megvizsgáljuk, és ha úgy találjuk, hogy az esemény a valódi 36A szoftvercsatornán át érkező adat, akkor 320 lépésben megvizsgáljuk a valódi 36B szoftvercsatornán keresztül érkezett adatot, és ha az, mint a jelen példában, egy, az ügyféloldali 30 elfogómodul által továbbított, a 10 webböngészőtől származó kommunikáció, akkor a kiszolgálóoldali 40 elfogómodulban egy új virtuális szoftvercsatornát hozunk létre a 321 lépésben. A kiszolgálóoldali 40 elfogómodulban lévő 69 szoftvercsatorna-kezelővel ezután elvégezzük 321, 322, 323 és 324 lépés műveleteit, és a kiszolgáló 69 szoftvercsatorna-kezelővel létrehozunk egy multiplex virtuális 95 szoftvercsatornát, érvénytelenítjük a multiplex 95 szoftvercsatorna tevékenység időzítőjét, és a 12. ábra szerinti 85 kiszolgálóoldali elfogóalkalmazást indítunk. A valódi 36B szoftvercsatornán vett adatot ezután a multiplex virtuális 95 szoftvercsatorna várakozási sorába tesszük, és egy virtuális eseményt jelzünk.

A 15. ábrán 360 lépésben létrehozzuk a 85 kiszolgálóoldali elfogóalkalmazást, amellyel majd az ügyféloldali 30 elfogómodultól elküldött és a 10 webböngészőtől származó kommunikációnak megfelelő adatot a multiplex virtuális 95 szoftvercsatornán keresztül fogadjuk. Miután a 85 kiszolgálóoldali elfogóalkalmazással vettük az ügyféloldali 30 elfogómodultól származó adatot, 362 lépésben a korábban a kiszolgálóoldali 40 elfogómodullal kapcsolatban leírt bármely módon feldolgozzuk (lásd például az 5. és 9. ábrát). Az információ feldolgozása után a 85 kiszolgálóoldali elfogóalkalmazással a 16-1. ábrán bemutatott virtuális létrehozási művelet elvégzésével létrehozunk egy egyszeres virtuális 75 szoftvercsatornát a 363 lépésben, és ugyancsak a 85 kiszolgálóoldali elfogóalkalmazással a 10 webböngészőtől származó kommunikációt elküldjük

364 lépésben az egyszeres virtuális 75 szoftvercsatornához, méghozzá egy, a 16-2. ábrán bemutatott virtuális küldés művelet végrehajtásával. A 85 kiszolgálóoldali elfogóalkalmazással ezután végrehajtunk egy virtuális ürítést, hogy kiürítsük az egyszeres virtuális 75 szoftvercsatornában lévő adatokat a valódi 60C szoftvercsatornába és az egyszeres virtuális 75 szoftvercsatornán át érkező eseményre várakozunk a

365 lépésben. Megjegyezzük, hogy az említett virtuális ürítés műveletet 17-1. ábrák segítségével mutatjuk be. A várakozást elvégezhetjük például úgy, hogy a 16—4. ábrán bemutatott virtuális kiválasztás műveletet végzünk el. Amikor a 85 kiszolgálóoldali elfogóalkalmazással létrehozzuk az egyszeres virtuális 75 szoftvercsatornát, azzal együtt létrehozunk egy annak megfelelő valódi 60C szoftvercsatornát is. Ha a 10 webböngészőtől származó kommunikációt elküldjük az egyszeres virtuális 75 szoftvercsatornának, akkor a 85 kiszolgálóoldali elfogóalkalmazással ezt a kommunikációt a 20 webkiszolgálóhoz juttatjuk el.

Amikor a kiszolgálóoldali 40 elfogómodullal megkapjuk a valódi 60C szoftvercsatornán át a választ a 20 webkiszolgálótól, akkor már nem egy virtuális, hanem egy valódi esemény történik, és a kiszolgáló 69 szoftvercsatorna kezelővel a 13. ábra 305 lépésében megvizsgáljuk ezt a valódi 60C szoftvercsatornán bekövetkezett eseményt. A bemutatott esetben ez az esemény egy létező virtuális szoftvercsatorna számára érkezett adat, és a 13. ábra 324 lépésében a valódi 60C szoftvercsatornán vett adatot az egyszeres virtuális 75 szoftvercsatorna várakozási sorába töltjük, és a virtuális esemény bekövetkezését jelezzük. Amint megtörténik a virtuális esemény jelzése, a 85 kiszolgálóoldali elfogóalkalmazás révén a 15. ábra 370 lépésében megvizsgáljuk az eseményt, és ha úgy találjuk, hogy az egy szoftvercsatorna lezárása, akkor egy hibafeltételt teljesítettnek tekintünk, és erre válaszként 375 lépésben hibaüzenetet állítunk elő. Ha azonban a bekövetkezett esemény egy adatvétel, akkor a 371 lépésben a 85 kiszolgálóoldali elfogóalkalmazás révén végrehajtunk egy, a 16-3. ábrán bemutatott virtuális vétel műveletet, hogy megkapjuk a 20 webkiszolgáló válaszát az egyszeres virtuális 75 szoftvercsatornáról. A 85 kiszolgálóoldali elfogóalkalmazással ezután az

HU 227 369 Β1 egyszeres virtuális 75 szoftvercsatornát virtuálisan lezárjuk a 372 lépésben - ahol a virtuális lezárás műveletet a 17-2. ábrán bemutatott módon hajtjuk végre valamint feldolgozzuk a kiszolgálóoldali 40 elfogómodul számára érkező választ a 373 lépésben a már korábbiakban leírt módon (lásd például a 6. és 10. ábrát). Akár a 375 lépéshez vezető hibaútvonalon, akár a 371 lépéshez vezető adatútvonalon lépünk tovább a 15. ábra 370 lépéséből, a 374 lépésben az egyszeres virtuális 75 szoftvercsatornát töröljük. A 85 kiszolgálóoldali elfogóalkalmazással ezután virtuális küldési műveletet hajtunk végre a multiplex virtuális 95 szoftvercsatorna felé, hogy azon továbbítsuk a 20 webkiszolgálótól származó kommunikációt az ügyféloldali 30 elfogómodulnak a 376 lépésben. A 85 kiszolgálóoldali elfogóalkalmazással ezután egy virtuális ürítés műveletet is végrehajtunk, amellyel ürítjük a multiplex virtuális 95 szoftvercsatorna várakozási sorában lévő adatokat a 377 lépésben. Ezt követően 378 lépésben a 85 kiszolgálóoldali elfogóalkalmazással virtuális lezárás műveletet hajtunk végre, amellyel lezárjuk a multiplex virtuális 95 szoftvercsatornát, végül a 379 és 380 lépésben a 85 kiszolgálóoldali elfogóalkalmazással töröljük a multiplex virtuális 95 szoftvercsatornát, és befejezzük az eljárást.

A 85 kiszolgálóoldali elfogóalkalmazással a multiplex virtuális 95 szoftvercsatornán a virtuális küldési és ürítési műveletet hajtjuk végre, ami eseményeket vált ki a valódi 36A szoftvercsatornán, és erre az ügyfél 68 szoftvercsatorna kezelővel 305 lépésben megvizsgáljuk a kiváltott eseményt. Mivel az adatok a valódi 36A szoftvercsatornán keresztül érkeztek, 320 lépésben az adatokat elhelyezzük a multiplex virtuális 90 szoftvercsatorna várakozási sorába. Ezért amikor a valódi 36A szoftvercsatornán át vesszük a 20 webkiszolgáló válaszát a valódi 36B szoftvercsatornán és a külső 35 átviteli vonalon keresztül, ezt az információt szétválasztjuk és a multiplex virtuális 90 szoftvercsatornához továbbítjuk. Az adat vétele 324 lépésben virtuális eseményt okoz, aminek hatására a 14. ábra 340 lépésében a 80 ügyféloldali elfogóalkalmazással megvizsgáljuk ezt az eseményt. Ha az esemény vizsgálata azt eredményezi, hogy az esemény egy lezárt szoftvercsatorna-válasz, akkor a 14. ábra 345 lépésében a 80 ügyféloldali elfogóalkalmazással válaszul létrehozunk egy hibaüzenetet, és továbblépünk a 344 lépésre. Ha az esemény azonban adat vétele, mint a bemutatott példában is, akkor a 341 lépésben a 80 ügyféloldali elfogóalkalmazással virtuális vételi műveletet hajtunk végre, amellyel vesszük a választ a multiplex virtuális 90 szoftvercsatornától. Miután a multiplex virtuális 90 szoftvercsatornától vettük az adatot, a 80 ügyféloldali elfogóalkalmazással virtuális lezárási műveletet hajtunk végre, hogy a 342 lépésben lezárjuk a multiplex virtuális 90 szoftvercsatornát, majd a 80 ügyféloldali elfogóalkalmazással az ügyféloldali 30 elfogómodul számára a 343 lépésben a már korábban ismertetett módon feldolgozzuk a választ (lásd például a 4. és 8. ábrát).

Ezt követően a 340 lépés eredményétől függetlenül a 344 lépésben a 80 ügyféloldali elfogóalkalmazással töröljük a multiplex virtuális 90 szoftvercsatornát, majd egy virtuális küldés műveletet hajtunk végre, amellyel a választ az egyszeres virtuális 70 szoftvercsatornán keresztül elküldjük a 10 webböngészőnek. Amikor ezzel a virtuális küldéssel kész vagyunk, a 80 ügyféloldali elfogóalkalmazással egy virtuális ürítési műveletet hajtunk végre, amellyel az egyszeres virtuális 70 szoftvercsatorna várakozási sorában lévő adatokat átküldjük a valódi 60B szoftvercsatornába a 347 lépésben, majd a 348 lépésben végrehajtunk egy virtuális lezárás műveletet, amellyel lezárjuk az egyszeres virtuális 70 szoftvercsatornát. A 80 ügyféloldali elfogóalkalmazás egyszeres virtuális 70 szoftvercsatornájának lezárását követően 349 lépésben töröljük az egyszeres virtuális 70 szoftvercsatornát, és 350 lépésben befejezzük a 80 ügyféloldali elfogóalkalmazás tevékenységét.

Amint ez szakember számára nyilvánvaló, a találmány szerinti eljárás és rendszer csupán egyetlen konkrét megvalósításban került ismertetésre az egyszeres és a multiplex virtuális szoftvercsatornák, valamint az ügyféloldali és a kiszolgálóoldali elfogóalkalmazások tekintetében, de egyetlen ügyféloldali elfogómodulon vagy egyetlen kiszolgálóoldali elfogómodulon belül számos funkció hozható létre és valósítható meg. így például a találmány szerinti ügyféloldali elfogómodullal és kiszolgálóoldali elfogómodullal létrehozhatunk egy TCP/IP csatlakozást a kettő között, majd webböngészők és webkiszolgálók sokaságától származó kommunikációt multiplexelhetünk erre a kapcsolatra, miután értesülünk a kapcsolat meglétéről.

Az ügyfél 68 szoftvercsatorna-kezelő és a kiszolgáló 69 szoftvercsatorna-kezelő további funkcióit és működését a 16-1.-16-4., valamint a 17-1. és 17-2. ábrák segítségével mutatjuk be részletesebben, amelyen az ügyféloldali 30 elfogómodul és a kiszolgálóoldali 40 elfogómodul funkciói figyelhetők meg a virtuális létrehozás, virtuális küldés, virtuális vétel, virtuális kiválasztás, virtuális ürítés és virtuális lezárás műveletek közben.

Amikor például a 14. ábra 333 lépésében és a 15. ábra 363 lépésében bemutatott virtuális létrehozás műveletet hajtunk végre, akkor a 16-1. ábrák 400 lépésével kezdődő eljárásmodult hajtjuk tulajdonképpen végre. A 68, 69 szoftvercsatorna-kezelővel 405 lépésben meghatározzuk, hogy szükség van-e egy valódi szoftvercsatornára, és ha már létezik ilyen valódi szoftvercsatorna, például amikor a virtuális létrehozás művelettel olyan multiplex virtuális 90 szoftvercsatornát hoztunk létre, amelyet egy létező valódi 60C szoftvercsatornához kell csatlakoztatni, akkor 409 lépésben a virtuális 90 szoftvercsatornát a valódi 61C szoftvercsatornához csatlakoztatjuk. Ha viszont szükség van ilyen valódi 61C szoftvercsatornára, akkor 406 lépésben létrehozunk egy ilyen valódi 61C szoftvercsatornát, amelyet 408 lépésben hozzáadunk az eseménylistához ellenőrzés céljából. Az ellenőrzést a 13. ábra 302 lépésében hajtjuk végre. A valódi 61C szoftvercsatorna létrehozása és egy csatlakozás megteremtése után a virtuális 90 szoftvercsatornát a valódi 61C szoftvercsatornához kapcsoljuk a 409 lépésben, majd 410 lépésben befejezzük a virtuális létrehozás műveletet.

HU 227 369 Β1

Térjünk át a 16-2. ábrák 420 lépésében kezdődő virtuális küldési művelet bemutatására, amelyre egyébként a 14. ábra 334 és 346 lépéseiben vagy a 15. ábra 364 és 376 lépéseiben hivatkoztunk. 427 lépésben az adatokat hozzáadjuk a virtuális 90 szoftvercsatorna várakozási sorához, és amikor ez készen van, 428 lépésben befejezzük a rutint, és visszatérünk a fő folyamathoz.

A 16-3. ábrán a 14. ábra 331 és 341 lépésében, valamint a 15. ábra 361 és 371 lépésében említett virtuális vétel művelet rutinját mutatjuk be. 430 lépésben vesszük az adatokat, majd 435 lépésben megvizsgáljuk a virtuális 90 szoftvercsatorna várakozási sorát, hogy abban van-e már adat. Ha van, akkor 436 lépésben az adatokat visszaküldjük a vétel műveletet meghívó funkcióhoz, míg ha nincs adat a virtuális 90 szoftvercsatorna várakozási sorában és a 90 szoftvercsatorna sincs lezáródóként megjelölve, akkor 440 lépés eredményeként a 441 lépésben semmit sem küldünk vissza. Ha azonban nincs adat a virtuális 90 szoftvercsatorna várakozási sorában és 442 lépésben a 90 szoftvercsatornát lezártként jelöljük meg, akkor a 443 lépésben a lezárt 90 szoftvercsatorna választ küldjük vissza a 430 lépésben leírt vételt meghívó művelethez.

A 16-4. ábrán azt a virtuális kiválasztás műveletet mutatjuk be, amelyet a 14. ábra 326 és 336 lépésénél, valamint a 15. ábra 366 lépésénél említettünk meg, illetve hajtottunk végre. 445 lépésben kezdve a kiválasztást 446 lépésben meghatározzuk, hogy a kiválasztott virtuális 90 szoftvercsatornán adat vagy virtuális lezárás művelet van-e éppen folyamatban. Ha egyik sincs folyamatban, akkor 447 lépésben a virtuális 90 szoftvercsatornán virtuális eseményre várunk, majd ilyen esemény észlelésekor a rutint 448 lépésben befejezzük. Ha azonban a 446 lépésben azt állapítjuk meg, hogy vagy virtuális lezárás, vagy adat van folyamatban a kiválasztott virtuális szoftvercsatornán, akkor virtuális esemény történt, és várakozás nélkül továbblépünk a 448 lépéshez.

A 17-1. ábrán a virtuális ürítés műveletét ismertetjük, amelyre a 14. ábra 335 és 347 lépésében, valamint a 15. ábra 365 és 377 lépésében hivatkoztunk. A rutin 450 lépésben kezdődő műveleteket foglalja magában. Amikor meghívjuk, először meghatározzuk, hogy van-e ürítendő adat a virtuális 90 szoftvercsatorna várakozási sorában. Ha a virtuális 90 szoftvercsatorna várakozási sorában nincs adat, akkor 455 lépést elhagyva a virtuális ürítési műveletet egyszerűen befejezzük és 467 lépésben az irányítást visszaadjuk a hívó funkciónak. Ha viszont van adat a virtuális 90 szoftvercsatorna várakozási sorban, akkor 460 lépésben meghatározzuk, hogy egy multiplex virtuális 90 szoftvercsatornáé-e a várakozási sor. Ha a válasz igenlő, akkor a 90 szoftvercsatorna fejlécet, amely három, a 90 szoftvercsatorna egyedi azonosítóját és az átvitelben az adat mennyiségét tartalmazó bájtból áll, hozzáadjuk a valódi 61C szoftvercsatorna közbenső tárához a 461 lépésben. Akár multiplex virtuális 90 szoftvercsatornáról, akár szimplex valódi 61C szoftvercsatornáról van szó, bármelyik esetben a valódi 61C szoftvercsatornának szánt adatokat annak közbenső tárába töltjük be a 462 lépésben. Ha a valódi 61C szoftvercsatorna közbenső tára megtelik, akkor a valódi 61C szoftvercsatorna közbenső tárában lévő adatokat elküldjük a valódi 61C szoftvercsatornán keresztül a 466 lépésben, míg ha a közbenső tár még nem telt be, akkor 470 lépésben megvizsgáljuk, hogy van-e bármilyen más adat bármelyik másik multiplex virtuális 90 szoftvercsatorna várakozási sorában, amelyet a valódi 61C szoftvercsatornának el kell küldeni. Amennyiben van, akkor a valódi 61C szoftvercsatorna közbenső tárában lévő adatot nem küldjük el, amíg a virtuális ürítési művelet nem kerül még egyszer meghívásra, hogy ürítse valamelyik másik virtuális 90 szoftvercsatorna várakozási sorát. Ha viszont nincs más adat, vagy a többi multiplex virtuális 90 szoftvercsatorna adatait már hozzáadtuk, úgy 466 lépésben a valódi 61C szoftvercsatorna közbenső sorában lévő adatokat azon keresztül elküldjük. Miután a virtuális ürítést meghívó funkcióhoz tartozó összes virtuális 90 szoftvercsatorna várakozási sorában lévő adatot elküldtük a valódi 61C szoftvercsatornán át, 467 lépésben befejezzük a virtuális ürítés műveletet.

A17-2. ábrán a virtuális lezárás műveletet mutatjuk be, amelyre a 14. ábra 342 és 348 lépésében, valamint a 15. ábra 372 és 378 lépésében hivatkoztunk. Amikor 480 lépésben meghívunk egy virtuális lezárás műveletet, akkor 485 lépésben először megvizsgáljuk, hogy a virtuális lezárás egy multiplex virtuális 90 szoftvercsatornához tartozik-e. Ha igen, akkor 486 lépésben a „lezárás” műveletjelzőt a virtuális 90 szoftvercsatorna várakozási sorához adjuk. Akár egy multiplex virtuális 90 szoftvercsatornához tartozik a virtuális lezárás művelet, akár nem, a virtuális lezárási művelettel 487 lépésben meghívjuk a virtuális ürítési műveletet, majd 488 lépésben megszüntetjük a kapcsolatot a valódi 61C szoftvercsatornával. Ezt követően 490 lépésben meghatározzuk, hogy a virtuális lezárás egy egyszeres virtuális 90 szoftvercsatornához tartozik-e, és amennyiben nem, tehát a lezárás egy multiplex 90 szoftvercsatornához tartozik, akkor 495 lépésben megvizsgáljuk, hogy ez az utolsó multiplex virtuális 90 szoftvercsatorna-e, és ha igen, akkor beállítjuk a multiplex tevékenység időzítőjét a 496 lépésben. Ha nem ez az utolsó multiplex virtuális 90 szoftvercsatorna, akkor a 496 lépést átugorjuk.

Visszatérve a 490 lépésre, amennyiben virtuális lezárás egy egyszeres virtuális 90 szoftvercsatornáé, akkor az ennek megfelelő valódi 61C szoftvercsatornát levesszük az eseménylistáról 491 lépésben, 492 lépésben pedig a valódi 61C szoftvercsatornát lezárjuk, majd töröljük. A szoftvercsatorna lehet akár egyszeres, akár multiplex virtuális 90 szoftvercsatorna, 497 lépésben mindenképpen lezártként jelöljük meg, majd a lezárási műveletet 498 lépésben befejezzük, és visszatérünk a fő folyamathoz.

Mivel szorosan a 16-1.-16-4. és a 17-1., 17-2. ábrákhoz kapcsolódik, most térünk rá a 13. ábrán bemutatott folyamatábra tényleges ismertetésére. 300 lépésben elindítva a rutint és 301 lépésben létre18

HU 227 369 Β1 hozva az első valódi 61C szoftvercsatornát, azon keresztül eseményre várakozunk, és a várakozásból továbblépve eseményt a 68, 69 szoftvercsatorna-kezelővel megvizsgáljuk. Ha az esemény nem más, mint a multiplex 90 szoftvercsatorna tevékenység időzítőjének a lejárta, amelyet a 17-2. ábrák 496 lépésében állítottunk be, akkor a 13. ábrán 312 lépésben a 68, 69 szoftvercsatorna-kezelővel lezárjuk a multiplex virtuális 90 szoftvercsatornát, majd 313 lépésben töröljük az annak a 90 szoftvercsatornának megfelelő multiplex virtuális 95 szoftvercsatornát, amely az ügyféloldali 30 elfogómodult a kiszolgálóoldali 40 elfogómodullal köti össze. A 68, 69 szoftvercsatorna-kezelővel ezután 302 lépésben megvárjuk a következő valódi eseményt, és a multiplex esemény időzítőt a multiplex virtuális 90 szoftvercsatorna létrehozásával nullázzuk.

Amennyiben a valódi 61C szoftvercsatornán bekövetkező esemény egy valódi 61C szoftvercsatorna lezárása, például, ha a 20 webkiszolgáló a közte és a kiszolgálóoldali 40 elfogómodul közötti kapcsolaton lezárási műveletet hajt végre, akkor a 13. ábra 309 lépésében a 68, 69 szoftvercsatorna-kezelővel eltávolítjuk a valódi 61C szoftvercsatornát a valódi események listájáról, és 310 lépésben szétkapcsoljuk a virtuális 90 szoftvercsatornát, illetve multiplex virtuális 90 szoftvercsatornák esetén a 90 szoftvercsatornát a valódi 61 szoftvercsatornától, illetve szoftvercsatornáktól, majd 311 lépésben a virtuális 90 szoftvercsatornát lezáródóként megjelöljük, és virtuális eseményt jelzünk. Amikor már minden adatot kiürítettünk a virtuális 90 szoftvercsatorna várakozási sorából, a virtuális 90 szoftvercsatornát lezárjuk. A virtuális 90 szoftvercsatorna lezáródóként való megjelölését követően a 68, 69 szoftvercsatorna-kezelővel meghatározzuk, hogy a lezárandó valódi 61C szoftvercsatorna egyszeres 61C szoftvercsatorna-e vagy sem a 315 lépésben, és ha a lezáródó valódi 61C szoftvercsatorna egyszeres, akkor a valódi 61C szoftvercsatornát lezárjuk és 316 lépésben töröljük, majd a 302 lépésre visszatérve a 68, 69 szoftvercsatorna-kezelővel a következő valódi esemény bekövetkeztére várunk.

Amennyiben nem egyszeres 61C szoftvercsatornát zárunk le, akkor a 315 lépést elhagyva a 68, 69 szoftvercsatorna-kezelővel a következő valódi esemény bekövetkeztét várjuk, vagyis a multiplex valódi 61C szoftvercsatorna, tehát az ügyféloldali 30 elfogómodult a kiszolgálóoldali 40 elfogómodullal összekötő 61C szoftvercsatornát csak a multiplex szoftvercsatorna tevékenységidőzítőjének lejártával tudjuk lezárni. Ez lehetővé teszi az ügyféloldali 30 elfogómodul és a kiszolgálóoldali 40 elfogómodul közötti kapcsolat fenntartását a közöttük folytatott utolsó kommunikációt követő, felhasználó által előre meghatározott ideig. A 10 webböngésző egy ezt követő csatlakozási kérelme esetén a multiplex szoftvercsatorna tevékenységidőzítőjének lejárta előtt a kommunikáció az ügyféloldali 30 elfogómodul és a kiszolgálóoldali 40 elfogómodul közötti újracsatlakozás létrehozása nélkül végbemehet, kiküszöbölve ezzel egy ilyen újracsatlakozás költségét.

A 13. ábra utolsóként ismertetésre kerülő útvonala arra az esetre vonatkozik, amikor valódi esemény történik, és ez az esemény nem más, mint a 12. ábra 36A és 36B szoftvercsatornáin, azaz multiplex valódi szoftvercsatornákon keresztül történő adatvétel. Amikor a multiplex valódi 36A, 36B szoftvercsatornákon adat vételére kerül sor, akkor azt megvizsgáljuk, és ha tartalmazza a lezárási művelet jelzőjét, amilyet például a 17-2. ábrák 486 lépésében egy virtuális várakozási sorhoz adtunk, akkor végrehajtunk egy virtuális lezárási műveletet. A 68, 69 szoftvercsatorna-kezelővel lekapcsoljuk a valódi 36A, 36B szoftvercsatornát az azzal vett adatokban azonosított multiplex virtuális 90 szoftvercsatornától a 310 lépésben, majd a virtuális 90 szoftvercsatornát „lezáródóként” megjelöljük és 311 lépésben virtuális eseményt jelzünk. Ezzel a lezárás egy multiplex virtuális 90 szoftvercsatorna lezárása, a 315 lépésről visszalépünk a 302 lépésre, amelyen a 68, 69 szoftvercsatorna-kezelővel újabb valódi eseményre várunk.

A 13-17. ábrák kapcsán bemutatott műveletek végrehajtása révén a találmány szerinti eljárás bemutatott foganatosítási módjával állandó kapcsolatot létesítettünk egy első 5 számítógép és egy második 6 számítógép között egy külső 35 átviteli vonalon keresztül. Ez az állandó kapcsolat addig marad fenn, amíg minden, a 10 webböngészőtől származó kommunikáció befejeződik, és a 10 webböngészőtől vagy böngészőktől származó kommunikációk sokasága multiplexelve a külső 35 átviteli vonalra kerül, miközben az állandó kapcsolat fennmarad, az ügyfél-kiszolgáló specifikus adatfolyam ezután demultiplexelhető, vagyis szétválasztható, hogy több HTTP adatfolyamot hozzunk létre, majd a HTTP adatfolyamok sokaságát a 20 webkiszolgálóhoz juttatjuk el. Az említett állandó kapcsolat mindaddig fennmarad, amíg minden, a 20 webkiszolgálótól származó kommunikáció befejeződik. A 20 webkiszolgálótól származó kommunikációk sokasága multiplexelve szintén rákerül a külső 35 átviteli vonalra, miközben az állandó kapcsolat fennmarad. Ezen túlmenően az ügyfél-kiszolgáló specifikus adatfolyamot demultiplexelhetjük, hogy ezzel visszaállítsuk a számos HTTP adatfolyamot, és a számos HTTP adatfolyamot adhatjuk át a 20 webkiszolgálónak.

Leírásunkban és az ábrákon a találmány jellemzőnek és általánosnak tekinthető előnyös kiviteli alakjait mutattuk be, de az esetleges konkrét megjelölések kizárólag a találmány lényegének jobb megértését szolgálják és a találmány oltalmi körének meghatározásánál mindenütt az általános fogalmakból kell kiindulni.

Claims (10)

1. SZABADALMI IGÉNYPONTOK

   1. Eljárás egy első számítógépben lévő első alkalmazástól egy második számítógépben lévő második alkalmazáshoz, annak kérelmére válaszként külső kommunikációs útvonalon továbbított adatmennyiség csökkentésére, azzal jellemezve, hogy egy kiszolgálóbázis gyorsítótár-bejegyzés létrehozásához a második

   HU 227 369 Β1 alkalmazástól érkezett kérelemre válaszként az első alkalmazásból származó adatfolyamot eltárolunk az első számítógép (5) gyorsítótárában; ügyfélbázis gyorsítótár-bejegyzés létrehozásához a második számítógép (6) kérelmére válaszként a második alkalmazásnak szánt adatfolyamot eltárolunk a második számítógép (6) gyorsítótárában; ügyfélbázislap biztosításához a második alkalmazás kérelmeinek kiértékelésével megvizsgáljuk, hogy létezik-e már a vizsgált kérelemnek megfelelő ügyfél gyorsítótár-bejegyzés; kiszolgálóbázis-lap biztosításához a második alkalmazás kérelmeinek kiértékelésével megvizsgáljuk, hogy létezik-e már a vizsgált kérelemnek megfelelő kiszolgáló gyorsítótárbejegyzés; a második alkalmazás megvizsgált kérelmére válaszként az első alkalmazástól származó válasznak megfelelő adatfolyamot még a válasznak a külső kommunikációs útvonalon történő elküldését megelőzően elfogjuk; az elfogott választ összehasonlítjuk a kiszolgálóbázis-lappal, és a kettő közötti különbségnek megfelelő különbözeti adatot állítunk elő; a különbözeti adatot a külső kommunikációs útvonalon a második számítógéphez (6) elküldjük; az első számítógéppel (5) a külső kommunikációs útvonalon elküldött különbözeti adatot megszerezzük; az elfogott válasznak megfelelő válaszadatfolyam létrehozásához a külső kommunikációs útvonalon kapott különbözeti adatok és az ügyfélbázislap kombinálásával a külső kommunikációs útvonalon vett ügyfél-kiszolgáló specifikus adatfolyamból újraszerkesztjük az első alkalmazástól származó kommunikációnak megfelelő válaszadatfolyamot; és az elfogott válasznak megfelelő újraszerkesztett adatfolyamot a második alkalmazás rendelkezésére bocsátjuk.
2. 2. Az 1. igénypont szerinti eljárás, azzal jellemezve, hogy meghatározzuk, hogy a kiszolgálóbázis-lap azonos-e az ügyfélbázislappal; és ha a kettő nem azonos, akkor a különbözeti adatok elküldése során mind a kiszolgálóbázis-lapot, mind a különbözeti adatokat elküldjük a külső kommunikációs útvonalon a második számítógéphez (6); a válaszadatfolyam újraszerkesztése során az első alkalmazástól származó válasznak megfelelő elfogott válaszadatfolyamot a külső kommunikációs útvonalon vett kiszolgálóbázis-lap és a különbözeti adatok kombinálásával szerkesztjük újra; és az ügyfélbázislapot a vett kiszolgálóbázis-lapnak az elfogott kérelemnek megfelelő ügyfélbázis gyorsítótár-bejegyzéseként való eltárolásával az elfogott kérelemnek megfelelően aktualizáljuk.
3. 3. Az 1. igénypont szerinti eljárás, azzal jellemezve, hogy megállapítjuk, hogy a kiszolgálóbázis-lap és az elfogott válasz közötti különbség meghalad-e egyelőre meghatározott különbségküszöböt; és amennyiben meghalad, akkor az első alkalmazástól származó elfogott válaszadatfolyamnak az elfogott kérelemnek megfelelő kiszolgálóbázis gyorsítótár-bejegyzéseként való eltárolásával a kiszolgáló alaplapot az elfogott kérelemnek megfelelően aktualizáljuk; és az összehasonlítást és a küldést az aktualizált kiszolgálóbázis-lap használatával végezzük.
4. 4. Az 1. igénypont szerinti eljárás, azzal jellemezve, hogy a második alkalmazástól származó kérelemnek megfelelő több kiszolgálóbázis gyorsítótár-bejegyzést fenntartunk; a második alkalmazástól származó kérelmek vizsgálása során több kiszolgálóbázis-lap létrehozásához meghatározzuk, hogy léteznek-e a második alkalmazástól származó kérelemnek megfelelő kiszolgálóbázis gyorsítótár-bejegyzések; megvizsgáljuk, hogy a szerverbázislapok egyike azonos-e az ügyfélbázislappal; és az elfogott válaszok összehasonlítása során a kiszolgálóbázis-lapok közül az ügyfélbázislappal azonos bázislapot használjuk, ha az előző lépésben valamelyik kiszolgálóbázis-lap és az ügyfélbázislap azonosságát megállapítottuk.
5. 5. Az 1. igénypont szerinti eljárás, azzal jellemezve, hogy a kiszolgáló gyorsítótár-bejegyzést a második alkalmazástól származó kérelem függvényében az első alkalmazástól származó adatfolyammal aktualizáljuk; régi különbözeti adatok biztosításához a második alkalmazástól származó kérelemnek megfelelő és az egymást követő kiszolgáló gyorsítótár-bejegyzések közötti különbségeket képviselő különbözeti adatkészleteket tartunk fenn; a különbözeti adatkészletek egyikével társított és a különbözeti adatkészletet szolgáltató kiszolgálóbázis-lapot egyedien azonosító CRC bejegyzéseket tartunk fenn; a kérelmek megvizsgálása során meghatározzuk, hogy léteznek-e a második alkalmazástól származó kérelemnek megfelelő különbözeti adatkészletek és CRC-k; meghatározzuk, hogy a CRC-k valamelyike megfelel-e az ügyfélbázislappal azonos kiszolgálóbázis-lapnak; a különbözeti adatok elküldése során a külső kommunikációs útvonalon keresztül a második számítógépnek (6) elküldjük az összehasonlítással kiszámított különbözeti adatok, az egymást követő régi különbözeti adatkészleteknek és az ügyfélbázislapoknak megfelelő CRC-nek megfelelő régi különbözeti adatokat; az újraszerkesztés során az elfogott válasznak megfelelő válaszadatfolyam létrehozásához az ügyfélbázislap és a külső kommunikációs útvonalon át kapott különbözeti adatok egymást követő kombinálásával a válaszadatfolyamot a külső kommunikációs útvonalon át fogadott adatfolyamból az első alkalmazástól származó kommunikációnak megfelelően újraszerkesztjük; és az ügyfél gyorsítótár-bejegyzést az újraszerkesztett adatfolyammal második alkalmazástól származó kérelemnek megfelelően aktualizáljuk.
6. 6. Az 1. igénypont szerinti eljárás, azzal jellemezve, hogy első alkalmazásként webkiszolgáló (20) alkalmazást, második alkalmazásként webböngésző (10) alkalmazást használunk.
7. 7. Az 1. igénypont szerinti eljárás, azzal jellemezve, hogy a külső kommunikációs útvonalként vezeték nélküli kommunikációs kapcsolatot használunk.
8. 8. A 6. igénypont szerinti eljárás, azzal jellemezve, hogy a webböngészőtől (10) származó kérelembe CGI-kérelmet ágyazunk.
9. 9. Berendezés egy első számítógépben lévő első alkalmazástól egy második számítógépben lévő második alkalmazáshoz, annak kérelmére válaszként külső kommunikációs útvonalon továbbított adatmennyiség csökkentésére, azzal jellemezve, hogy egy kiszolgáló20

   HU 227 369 Β1 bázis gyorsítótár-bejegyzés létrehozásához a második alkalmazástól érkezett kérelemre válaszként az első alkalmazásból származó adatfolyamot az első számítógép (5) gyorsítótárában eltároló eszköze; az ügyfélbázis gyorsítótár-bejegyzés létrehozásához a második számítógép (6) kérelmére válaszként a második alkalmazásnak szánt adatfolyamot a második számítógép (6) gyorsítótárában eltároló eszköze; az ügyfélbázislap biztosításához a második alkalmazás kérelmeinek kiértékelésére a vizsgált kérelemnek megfelelő ügyfél gyorsítótár-bejegyzés létezését megvizsgáló eszköze; a kiszolgálóbázis-lap biztosításához a második alkalmazás kérelmeinek kiértékelésére a vizsgált kérelemnek megfelelő kiszolgáló gyorsítótár-bejegyzés létezését megvizsgáló eszköze; a második alkalmazás megvizsgált kérelmére válaszként az első alkalmazástól származó válasznak megfelelő adatfolyamot még a válasznak a külső kommunikációs útvonalon történő elküldését megelőzően elfogó eszköze; az elfogott választ a kiszolgálóbázis-lappal összehasonlító és a kettő közötti különbségnek megfelelő különbözeti adatot előállító eszköze; a különbözeti adatot a külső kommunikációs útvonalon a második számítógéphez (6) elküldő eszköze; az első számítógéppel (5) a külső kommunikációs útvonalon elküldött különbözeti adatot megszerző eszköze; az elfogott válasznak megfelelő válaszadatfolyam létrehozásához a külső kommunikációs útvonalon kapott különbözeti adatok és az ügyfélbázislap kombinálásával a külső kommunikációs útvonalon vett ügyfél-kiszolgáló specifikus adatfolyamból az első alkalmazástól származó kommunikációnak megfelelő válaszadatfolyamot újraszerkesztő eszköze; és az elfogott válasznak megfelelő újraszerkesztett adatfolyamot a második alkalmazás rendelkezésére bocsátó eszköze van.
10. 10. Programtermék egy első számítógépben lévő első alkalmazástól egy második számítógépben lévő második alkalmazáshoz, annak kérelmére válaszként külső kommunikációs útvonalon továbbított adatmennyiség csökkentésére, azzal jellemezve, hogy egy kiszolgálóbázis gyorsítótár-bejegyzés létrehozásához a második alkalmazástól érkezett kérelemre válaszként az első alkalmazásból származó adatfolyamot az első számítógép (5) gyorsítótárában eltároló számítógéppel olvasható programkód eszköze; az ügyfél bázis gyorsítótár-bejegyzés létrehozásához a második számítógép (6) kérelmére válaszként a második alkalmazásnak szánt adatfolyamot a második számítógép (6) gyorsítótárában eltároló számítógéppel olvasható programkód eszköze; az ügyfélbázislap biztosításához a második alkalmazás kérelmeinek kiértékelésére a vizsgált kérelemnek megfelelő ügyfél gyorsítótár-bejegyzés létezését megvizsgáló számítógéppel olvasható programkód eszköze; a kiszolgálóbázis-lap biztosításához a második alkalmazás kérelmeinek kiértékelésére a vizsgált kérelemnek megfelelő kiszolgáló gyorsítótár-bejegyzés létezését megvizsgáló számítógéppel olvasható programkód eszköze; a második alkalmazás megvizsgált kérelmére válaszként az első alkalmazástól származó válasznak megfelelő adatfolyamot még a válasznak a külső kommunikációs útvonalon történő elküldését megelőzően elfogó számítógéppel olvasható programkód eszköze; az elfogott választ a kiszolgálóbázis-lappal összehasonlító és a kettő közötti különbségnek megfelelő különbözeti adatot előállító számítógéppel olvasható programkód eszköze; a különbözeti adatot a külső kommunikációs útvonalon a második számítógéphez (6) elküldő számítógéppel olvasható programkód eszköze; az első számítógéppel (5) a külső kommunikációs útvonalon elküldött különbözeti adatot megszerző számítógéppel olvasható programkód eszköze; az elfogott válasznak megfelelő válaszadatfolyam létrehozásához a külső kommunikációs útvonalon kapott különbözeti adatok és az ügyfélbázislap kombinálásával a külső kommunikációs útvonalon vett ügyfél-kiszolgáló specifikus adatfolyamból az első alkalmazástól származó kommunikációnak megfelelő válaszadatfolyamot újraszerkesztö számítógéppel olvasható programkód eszköze; és az elfogott válasznak megfelelő újraszerkesztett adatfolyamot a második alkalmazás rendelkezésére bocsátó számítógéppel olvasható programkód eszköze van.