PL180570B1 - Sposób, urzadzenie i produkt programu komputerowego do komunikacjiw systemie klient/serwer PL PL PL PL PL PL PL PL PL PL PL - Google Patents

Abstract

1 . Sposób komunikacji w systemie klient/serwer zawierajacym pierwsza aplikacje w pierwszym komputerze, która komunikuje sie z druga aplikacja w drugim komputerze, odleglym od pierwszego komputera, przy czym pierwsza i druga aplikacje uzywaja nieza- leznego protokolu komunikacyjnego klient/serwer do komunikacji miedzy klientem a serwerem, zas na zewnetrznym laczu telekomu- nikacyjnym wystepuje co najmniej jeden segment komunikatu miedzy pierwsza aplikacja w pierwszym komputerze, a druga aplikacja w drugim komputerze, znamienny tym, ze przechwytuje sie w niezaleznym protokole komunikacyjnym klient/serwer ko- munikat, inicjowany przez pierwsza aplikacje przed przeslaniem komunikatu zewnetrznym laczem telekomunikacyjnym, dokonuje sie konwersji komunikatu inicjowanego przez pierwsza aplikacje na specyficzny protokól komunikacyjny klient/serwer i przesyla sie, po konwersji, komunikat przez zewnetrzne lacze telekomuni- kacyjne w postaci specyficznego strumienia danych klient/serwer, po czym odbiera sie komunikat transmitowany przez lacze ze- wnetrzne, dokonuje sie konwersji komunikatu, odebranego przez zewnetrzne lacze telekomunikacyjne, ze specyficznego protokolu komunikacyjnego klient/serwer na niezalezny protokól komunika- cyjny klient/serwer, i dostarcza sie komunikat inicjowany przez pierwsza aplikacje do drugiej aplikacji w niezaleznym protokole komunikacyjnym klient/serwer. FIG.1 1 PL PL PL PL PL PL PL PL PL PL PL

Description

Przedmiotem wynalazku jest sposób, urządzenie i produkt programu komputerowego do komunikacji w systemie klient/serwer, zwłaszcza do komunikacji pomiędzy aplikacjami serwera klienta takimi jak przeglądarka WWW i serwerem WWW.

Znana jest powszechna akceptacja Internetu jako medium komunikacji masowej. To oparte na szerokiej podstawie uznanie Internetu jako żywotnego medium dla komunikacji i interakcji między licznymi sieciami, wytworzyło także dobrze utrwaloną bazę zbudowaną na standaryzowanych internetowych protokółach współdziałania miedzy sieciami komputerowymi.

Zasadą dla Internetu jest taka relacja miedzy klientem a serwerem, że klienci (przeglądarki) komunikują się z serwerami Internetu. Dla zwiększenia dostępu do Internetu stosowane protokóły komunikacyjne i języki używane przez klientów i serewery zostały poddane standaryzacji. Te protokóły zawierają Hipertekstowy Protokół Transmisji (HTTP), który jest prorokółem komunikacyjnym używanym pomiędzy klientami i serwerami i Protokół Sterowania Transmisją w Sieci Internet (TCP/IP), gdzie część TCP jest specjalnym protokołem dla komunikacji pomiędzy komputerami lub aplikacjami. Również standaryzowany jest język zwany znakowanym językiem hipertekstowym (HTML). Ponieważ te protokóły i język nie zależą od urządzenia i stosują do przesyłania informacji protokół bezpołączeniowy o najlepszej zgodności, to każda transakcja jest w pełni samoistna. Dlatego, na przykład każda wiadomość od klienta zawiera informacje o możliwościach przeglądarki i jest niezależna od innych transmisji. Ta samoistna natura komunikacji pomiędzy klientem a serwerem może być określona jako transmisja bezstanowa i zwiększać liczbę danych, które muszą być przesłane pomiędzy klientem a serwerem w danej transmisji. W kontekście aplikacji klient/serwer w Światowej Sieci Komputerowej (WWW) klientem może być przeglądarka WWW, która działa jako interfejs użytkownika. Przeglądarka przesyła żądania klienta do odpowiedniego serwera WWW oraz formatuje i wyświetla dane HTML otrzymane z serwera. Przeglądarka WWW także ocenia dane HTML dla ustalenia, czy w danych HTML są zawarte instrukcje wyższych łączy, które wymagają kolejnych żądań przeglądarki, które będą następnie inicjowane przez przeglądarkę. Serwer WWW działa jak serwer klienta i przetwarza żądania przeglądarek oraz przekazuje je zwrotnie jako odpowiedzi na żądania jako część danych HTML strumienia danych HTTP.

180 570

Przykładem typowej komunikacji sieciowej może być przypadek, gdy przeglądarka sieciowa inicjuje żądanie strony tytułowej z serwera sieciowego, ilustruje podstawowe zależności pomiędzy danymi HTTP, HTML, TCP i przeglądarką oraz serwerem. Gdy użytkownik przeglądarki żąda informacji z określonej strony sieciowej, przeglądarka inicjuje komunikację z serwerem przesyłając żądanie daj do serwera sieci określając Uniwersalny Lokalizator Zasobów (URL) żądanej strony sieciowej, która dla celu tego przykładu może być stroną tytułową. Lokalizator URL funkcjonuje jak adres strony sieciowej i jest unikalny dla całego Internetu. Serwer sieciowy powinien następnie uzyskać i przesłać do przeglądarki dane HTML odpowiadające stronie tytułowej określonego lokalizatora URL. Ta operacja może inicjować dalsze transmisje w Internecie realizowane przez sieciowy serwer Internetu lub lokalizatora URL może specyfikować serwer w sieci lokalnej, do którego jest dołączona przeglądarka. Przeglądarka powinna następnie ocenić dane HTML otrzymane z serwera jako strumień danych HTTP dla sprawdzenia czy jest tam włączone hiperłącze takie jak ikona lub obraz i jeśli takie hiperłącze istnieje, powinna inicjować żądania określenia lokatora URL hiperłącza dla uzyskania określonych danych. Te dane powinny być następnie wprowadzone do strony tytułowej i wyświetlone użytkownikowi. Jak widać na tym przykładzie, jedno wejściowe żądanie użytkownika wykonane przez przeglądarkę może wywołać wiele dodatkowych żądań, które są automatycznie wykonywane przez przeglądarkę w odpowiedzi na potwierdzenie danych HTML odpowiadających wstępnemu żądaniu użytkownika.

Podstawowa, znana struktura komunikacyjna dla systemu Internetowego jest przedstawiona na figurze 1. Na fig. 1 przeglądarka WWW 10 komunikuje się z serwerem WWW 20 poprzez łącze komunikacyjne 15. To łącze komunikacyjne jest typowo połączeniem lokalnej sieci, połączeniem rozległej sieci komputerowej, połączeniem w linii telefonicznej, lub kombinacją sposobów łączenia. Przeglądarka komunikuje się z serwerem 20 wykorzystując TCP/IP. W większości połączeń Internetowych przeglądarka komunikuje się z serwerem wykorzystując protokół rodzajowy protokół komunikacyjny HTTP, który jest przesyłany pomiędzy przeglądarką a serwerem. Rzeczywiste dane przesyłane pomiędzy przeglądarką 10 i serwerem 20 są obiektami o danych HTTP, na przykład dane HTML jak opisano powyżej. Serwer 20 może być pośrednikiem, który odbiera transmisje od wielu przeglądarek i kieruje je do odpowiedniego serwera.

Popularność układu przeglądarka /serwer i ich wspólne protokoły transmisji i informacji, HTML i HTTP, doprowadziły do szybkiego przyjęcia technologii sieciowej jako uniwersalnego interfejsu dla sieciowego dostępu do informacji. Ponadto, ponieważ protokóły i język komunikacji między przeglądarkami i serwerami są standaryzowane, protokoły komunikacyjne i język będą takie same niezależnie od tego, z jakiej użytkownik korzysta przeglądarki jako z dostępu do sieci informatycznej. Dlatego powszechnie instalowane u użytkowników przeglądarki w połączeniu z dostępnością Internetu i łatwością zapisu aplikacji serwerów, wykorzystując Wspólny Interfejs Przejścia (CGI), czynią technologię sieciową bardzo atrakcyjną dla szerokiej klasy aplikacji formatowanych.

W tym samym czasie, gdy wzrastała popularność i stosowanie Internetu, zwiększała się również popularność komputerów przenośnych. Użycie laptopów, notebooków, Osobistych Cyfrowych Pomocy Komunikacyjnych (PDAs/PCAs) i innych urządzeń przenośnych doprowadziło do zwiększenia wymagań w zakresie komunikacji radiowej. Radiowe sieci wielkoobszarowe, łączność komórkowa i pakiety radiowe mają jednakże wspólne ograniczenia przy stosowaniu w sieci komputerowej. Wysoki koszt transmisji, długi czas odpowiedzi, mała szerokość pasma i mała niezawodność, wszystko to przeszkadza zastosowaniu technologii radiowej dla bezstanowego protokółu komunikacyjnego sieci WWW. Również, ponieważ protokół sieci jest bezstanowy ilość danych na żądanie i liczba żądań przesyłanych łączem radiowym jest większa niż byłaby konieczna, jeśli transmisja nie byłaby samoistna. Tak więc łączenie technologii radiowej lub innych powolnych technologii komunikacyjnych z technologią sieciową wydaje się niepraktyczne, przy czym możliwości technologii sieciowej w jej uniwersalnej naturze uwydatniają słabość technologii radiowej.

Istotą sposobu komunikacji w systemie klient/serwer, według wynalazku, zawierającym pierwszą aplikację w pierwszym komputerze, która komunikuje się z drugą aplikacją w dru

180 570 gim komputerze odległym od pierwszego komputera, przy czym pierwsza i druga aplikacje używają niezależnego protokołu komunikacyjnego Idient/serwer do komunikacji między klientem a serwerem, zaś na zewnętrznym łączu telekomunikacyjnym występuje co najmniej jeden segment komunikatu między pierwszą aplikacją w pierwszym komputerze a drugą aplikacją w drugim komputerze, jest to, że przechwytuje się w niezależnym protokole komunikacyjnym klient/serwer komunikat, inicjowany przez pierwszą aplikację przed przesłaniem komunikatu zewnętrznym łączem telekomunikacyjnym, dokonuje się konwersji komunikatu inicjowanego przez pierwszą aplikację na specyficzny protokół komunikacyjny klient/serwer i przesyła się, po konwersji, komunikat przez zewnętrzne łącze telekomunikacyjne w postaci specyficznego strumienia danych klient/serwer, po czym odbiera się komunikat transmitowany przez łącze zewnętrzne, dokonuje się konwersji komunikatu, odebranego przez zewnętrzne łącze telekomunikacyjne, ze specyficznego protokołu komunikacyjnego klient/serwer na niezależny protokół komunikacyjny klient/serwer, i dostarcza się komunikat inicjowany przez pierwszą aplikację do drugiej aplikacji w niezależnym protokole komunikacyjnym klient/serwer.

Korzystnie, jako niezależny protokół komunikacji klient/serwer stosuje się hipertekstowy protokół transmisyjny (HTTP) zaś jako komunikat inicjowany przez pierwszy komputer stosuje się strumień danych HTTP.

Korzystnie, gdy pierwszym komputerem jest klient odległy, to jako pierwszą aplikację stosuje się aplikację przeglądarki sieciowej, zaś gdy drugim komputerem jest serwer, to jako drugą aplikację stosuje się aplikacje serwerową sieć.

Korzystnie, gdy pierwszym komputerem jest serwer, to jako pierwszą aplikację stosuje się aplikację serwerową sieci, zaś gdy drugim komputerem jest klient odległy, to jako drugą aplikację stosuje się aplikację przeglądarki sieciowej.

Korzystnie, inicjowany przez przeglądarkę sieciową komunikat odpowiada na żądanie wspólnego interfejsu przejścia (CGI), to przepytuje się przechwycone żądanie interfejsu CGI dla określenia, czy istnieje pozycja podręcznej bazy klienta odpowiadająca przechwyconemu żądaniu interfejsu CGI i zapewniająca podstawowy format interfejsu CGI klienta, i przepytuje się przechwycone żądanie interfejsu CGI dla określenia, czy istnieje pozycja podręcznej bazy serwera odpowiadająca przechwyconemu żądaniu interfejsu CGI i zapewniająca podstawowy format interfejsu CGI serwera, po czym przechowuje się strumień danych HTTP odebranych z serwera sieciowego w odpowiedzi na inicjowany przez przeglądarkę sieciową komunikat, który jest skierowanym do interfejsu CGI żądaniem rezydentnej pamięci podręcznej rezydującej w drugim komputerze, dotyczącym utworzenia pozycji podstawowej pamięci podręcznej serwera, przechowuje się strumień danych HTTP przeznaczony dla przeglądarki sieciowej w odpowiedzi na komunikat inicjowany przez przeglądarkę sieciową który jest skierowanym· do interfejsu CGI. żądaniem rezydentnej pamięci podręcznej w pierwszym komputerze, dotyczącym utworzenia pozycji podstawowej pamięci podręcznej klienta, i przechwytuje się strumień danych HTTP odpowiadający inicjowanemu przez serwer sieciowy' komunikatowi w odpowiedzi na przechwycone żądanie interfejsu CGI, przed przesłaniem strumienia danych HTTP do zewnętrznego łącza telekomunikacyjnego, po czym porównuje się przechwyconą odpowiedź interfejsu CGI z podstawowym formatem interfejsu CGI serwera, dla otrzymania danych różnicowych interfejsu CGI odpowiadających różnicy między przechwyconą odpowiedzią interfejsu CGI a podstawowym formatem interfejsu CGI serwera, wysyła się dane różnicowe interfejsu CGI do przeglądarki sieciowej w pierwszym komputerze przez zewnętrzne łącze telekomunikacyjne jako specyficzny strumień danych klient/serwer i zbiera się specyficzny strumień danych klient/serwer przesyłanych przez zewnętrzne łącze telekomunikacyjne, który był wysłany przez drugi komputer, przy czym w trakcie konwersji komunikatu odebranego odtwarza się strumień danych HTTP, odpowiadający komunikatowi od serwera sieciowego, ze specyficznego strumienia danych klient/serwer odebranego przez zewnętrzne łącze telekomunikacyjne poprzez połączenie podstawowego formatu interfejsu CGI klienta i danych różnicowych interfejsu CGI otrzymanych zewnętrznym łączem komunikacyjnym, przy utworzeniu strumienia danych HTTP odpowiadającego przechwyconej odpowiedzi inter

180 570 fejsu CGI, zaś w trakcie dostarczania komunikatu inicjowanego dostarcza się komunikat inicjowany przez serwer sieciowy do przeglądarki sieciowej jako strumień danych HTTP.

Korzystnie następnie zestawia się trwałe połączenie między pierwszym komputerem a drugim komputerem przez zewnętrzne łącze telekomunikacyjne i utrzymuje się trwałe połączenie aż do zakończenia komunikacji zainicjowanej przez przeglądarkę sieciową, przy czym w trakcie przechwytywania komunikatu przechwytuje się wiele komunikatów inicjowanych przez przeglądarkę sieciową i zwielokrotnia się je na zewnętrznym łączu telekomunikacyjnym przy utrzymywaniu połączenia trwałego.

Korzystnie następnie dostarcza się do drugiego komputera, przez zewnętrzne łącze telekomunikacyjne, specyficzną informację komputerową odpowiadającą zadanym parametrom charakterystycznym pierwszego komputera, i przechowuje się specyficzną informację komputerową odpowiadającą zadanym parametrom charakterystycznym pierwszego komputera z wprowadzeniem informacji nagłówkowej przeglądarki, przy czym w trakcie konwersji komunikatu inicjowanego usuwa się specyficzną informację komputerową z komunikatu inicjowanego przez przeglądarkę sieciową, zaś w trakcie konwersji komunikatu odebranego łączy się informację nagłówkową przeglądarki ze specyficznym strumieniem danych klient/serwer tworząc strumień danych HTTP.

Korzystnie następnie wychwytuje się strumień danych HTTP odpowiadający komunikatowi inicjowanemu przez serwer sieciowy przed przesłaniem strumienia danych HTTP zewnętrznym łączem telekomunikacyjnym, dokonuje się konwersji strumienia danych HTTP, inicjowanego przez serwer sieciowy, z protokołu HTTP na specyficzny protokół komunikacyjny klient/serwer, i przesyła się, po konwersji, inicjowany przez serwer sieciowy komunikat do przeglądarki sieciowej przez zewnętrzne łącze telekomunikacyjne w postaci specyficznego strumienia danych klient/serwer, po czym odbiera się specyficzny strumień danych klient/serwer przesyłany przez zewnętrzne łącze telekomunikacyjne oraz realizuje się odbudowę strumienia danych HTTP odpowiadającego komunikatowi od serwera sieciowego ze specyficznego strumienia danych klient/serwer odebranego przez zewnętrzne łącze telekomunikacyjne poprzez konwersję specyficznego strumienia danych klient/serwer odebranego w specyficznym protokole komunikacyjnym klient/serwer na strumień danych HTTP i dostarcza się komunikat inicjowany przez serwer sieciowy do przeglądarki sieciowej jako strumień danych HTTP.

Istotą urządzenia do komunikacji w systemie klient/serwer, w którym pierwsza aplikacja w jednym komputerze jest połączona poprzez łącze komunikacyjne z aplikacją w drugim komputerze, jest to, że zawiera w pierwszym komputerze, włączony między pierwszą aplikację a zewnętrzne łącze telekomunikacyjne, pierwszy moduł przechwytujący do przechwytywania komunikatu w niezależnym protokole komunikacyjnym klient/serwer, inicjowanego przez pierwszą aplikację przed przesłaniem komunikatu zewnętrznym łączem telekomunikacyjnym, konwersji inicjowanego komunikatu na specyficzny protokół komunikacyjny klient/serwer i przesyłania, po konwersji, komunikatu do drugiego komputera zewnętrznym łączem telekomunikacyjnym w postaci specyficznego strumienia danych klient/serwer, oraz w drugim komputerze, włączony między zewnętrzne łącze telekomunikacyjne a drugą aplikację, drugi moduł przechwytujący do odbierania komunikatów transmitowanych przez telekomunikacyjne łącze zewnętrzne, konwersji komunikatu ze specyficznego protokołu komunikacyjnego klient/serwer na niezależny protokół komunikacyjny klient/serwer i dostarczenia komunikatu po konwersji do drugiej aplikacji.

Istotą produktu programu komputerowego do komunikacji w systemie klient/serwer, według wynalazku, który jest przechowywany na czytelnym dla komputera nośniku pamięciowym i zawiera wiele elementów z kodem oprogramowania do implementacji systemu po załadowaniu produktu do komputera, jest to, że zawiera odczytywalne komputerowo elementy kodu programowego przechwytywania przez pierwszy komputer komunikatu w niezależnym protokole komunikacyjnym klient/serwer, inicjowanego przez pierwszą aplikację, przed przesłaniem komunikatu zewnętrznym łączem telekomunikacyjnym, odczytywalne komputerowo elementy kodu programowego konwersji przez pierwszy komputer komunikatu inicjowanego na specyficzny protokół komunikacyjny klient/serwer, odczytywalne kompute8

180 570 rowo elementy kodu programowego przesłania, po konwersji, przez pierwszy komputer komunikatu do drugiego komputera przez zewnętrzne łącze telekomunikacyjne w postaci specyficznego strumienia danych klient/serwer, odczytywalne komputerowo elementy odbierania przez drugi komputer komunikatów przesyłanych przez zewnętrzne łącze telekomunikacyjne, odczytywalne komputerowo elementy konwersji przez drugi komputer komunikatu ze specyficznego protokołu łączności komunikacyjnego klient/serwer na niezależny protokół komunikacyjny klient/serwer i odczytywalne komputerowo elementy dostarczania przez drugi komputer komunikatu po konwersji do drugiej aplikacji.

Zaletą rozwiązania według wynalazku jest możliwość wykorzystania zainstalowanej bazy użytkowników sieci WWW w środowisku komunikacji o małej prędkości, takiej jak komunikacja radiowa, przy wykorzystaniu z istniejących protokołów komunikacyjnych i języków w systemie powolnej lub radiowej komunikacji, bez modyfikacji aplikacji przeglądarki sieciowej i serwera sieciowego.

Przedmiot wynalazku jest uwidoczniony w przykładach wykonania na rysunku, na którym fig. 1 przedstawia schemat blokowy znanego systemu przeglądarka WWW/serwer. WWW, fig. 2 - schemat blokowy systemu przeglądarka/serwer według wynalazku wykorzystującego moduł przechwytujący strony klienta i moduł przechwytujący strony serwera, fig. 3 - sieć działań operacji wykonywanych przez moduł przechwytujący klienta w przykładzie wykonania zawierającym koherentny system pamiętania pośredniczącego, fig. 4 - sieć działań operacji wykonywanych przez moduł przechwytujący klienta w przykładzie wykonania zawierającym koherentny system pamiętania pośredniczącego, fig. 5 - sieć działań operacji wykonywanych przez moduł przechwytujący serwera w przykładzie wykonania zawierającym koherentny system pamiętania pośredniczącego, fig. 6 - sieć działań operacji wykonywanych przez moduł przechwytujący serwera w przykładzie wykonania zawierającym koherentny system pamiętania pośredniczącego, fig. 7 - sieć działań operacji wykonywanych przez moduł przechwytujący klienta w przykładzie wykonania zawierającym system przesyłania danych różnicowych, fig. 8 - sieć działań operacji wykonywanych przez moduł przechwytujący klienta w przykładzie wykonania zawierającym system przesyłania danych różnicowych, fig. 9 - sieć działań operacji wykonywanych przez moduł przechwytujący serwera w przykładzie wykonania zawierającym system przesyłania danych różnicowych, fig. 10 - sieć działań operacji wykonywanych przez moduł przechwytujący serwera w przykładzie wykonania zawierającym system przesyłania danych różnicowych, fig. 11 - schemat blokowy rozwiązania według wynalazku wykorzystującego gniazda wirtualne, fig. 12 - schemat blokowy modułu przechwytującego klienta i modułu przechwytującego serwera według przykładu wykonania wynalazku wykorzystującego gniazda wirtualne, fig. 13 - sieć działań operacji wykonywanych przez zarządzającego gniazdami modułu przechwytującego klienta, albo modułu przechwytującego serwera, według przykładu wykonania wykorzystującego gniazda wirtualne, fig. 14 - sieć działań operacji wykonywanych przez funkcję przejmującą strony klienta w przykładzie wykonania wykorzystującym gniazda wirtualne, fig. 15 - sieć działań operacji wykonywanych przez funkcję przejmującą strony serwera w przykładzie wykonania wykorzystującym gniazda wirtualne, fig. 16-1 - sieć działań wirtualnej operacji tworzenia według przykładu wykonania wykorzystującego gniazda wirtualne, fig. 16-2 - sieć działań wirtualnej operacji wysyłania według przykładu wykonania wykorzystującego gniazda wirtualne, fig. 16-3 - sieć działań wirtualnej operacji odbierania według przykładu wykonania wykorzystującego gniazda wirtualne, fig. 16-4 - sieć działań wirtualnej operacji wybierania według przykładu wykonania wykorzystującego gniazda wirtualne, fig. 17-1 - sieć działań wirtualnej operacji opróżniania, według przykładu wykonania wykorzystującego gniazda wirtualne, fig. 17-2 - sieć działań wirtualnej operacji zamykania, według przykładu wykonania wykorzystującego gniazda wirtualne.

Przedstawione na figurach 3 do 10 i 13 do 17-2 sieci działań ilustrującymi sposoby według wynalazku. Jest oczywiste, że każdy blok przedstawiony w sieci działań lub kombinacja bloków może być zrealizowana w postaci instrukcji programu komputerowego. Te instrukcje programu komputerowego mogą być ładowane do komputera lub innego urządzenia programowalnego działającego jak komputer, tak, że instrukcje wykonywane przez komputer lub

180 570 inne urządzenie programowalne tworzą elementy dla realizacji funkcji określonych w bloku lub blokach sieci działań. Te instrukcje programu komputerowego mogą być także zapamiętywane w pamięci odczytywalnej przez komputer, która może sterować komputerem lub innym urządzeniem programowalnym dla działania w określony sposób tak, że instrukcje zapamiętane w pamięci odczytywalnej przez komputer tworzą wykony wany element zawierający elementy instrukcji, które realizują funkcje określone w bloku lub blokach sieci działań. Instrukcje programu komputerowego mogą być także ładowane do komputera lub innego urządzenia programowalnego dla wywołania realizacji przez komputer lub inne urządzenie programowalne serii etapów operacyjnych dla wykonania procesu realizowanego przez komputer tak, że instrukcje wykonywane przez komputer lub inne urządzenie programowalne wykonują etap operacyjny dla realizacji funkcji określonych w bloku lub blokach sieci działań. Zatem przedstawione bloki, w sieci działań przedstawiają kombinacje etapów dla wykonania określonych funkcji i kombinację elementów dla wykonania określonych funkcji. Jest oczywiste, że każdy blok i kombinacja bloków sieci działań może być realizowana przez specjalny system komputerowy lub kombinację określonego sprzętu komputerowego i oprogramowania, które wykonują określone funkcje lub etapy operacyjne.

Na figurze 2 jest przedstawiony schemat blokowy rozwiązania według wynalazku. Przeglądarka WWW 10 komunikuje się z modułem przechwytującym klienta 30. Serwer WWW 20 komunikuje się z modułem przejmującym serwera 40 przez łącze komunikacyjne 35. Przeglądarka WWW 10 i moduł przejmujący klienta 30 mogą być umieszczone w pierwszym komputerze 5. Moduł przechwytujący serwera 40 i serwer WWW 20 mogą być umieszczone w drugim komputerze 6. Pierwszy komputer 5 i drugi komputer 6 komunikują się przez zewnętrzne łącze komunikacyjne 35.

Korzystnie, przeglądarka 10 jest przeglądarka internetową wykorzystująca hipertekstowy protokół transmisyjny (HTTP) i język HTML dla komunikowania się z serwerem internetowym 20, który także używa protokołu HTTP i języka HTML. Podczas operacji przesyłania przeglądarka 10 wysyła strumień danych HTTP, który jest przejmowany przez moduł przechwytujący 30 klienta. Przejęcie strumienia danych HTTP przez moduł przechwytujący 30 klienta może być wykonane przy wykorzystaniu możliwości pętli zwrotnej TCP/IP, gdzie moduł przechwytujący 30 klienta ma adres protokołu internetowego IP o numerze sieciowym 127, taki jak 127.0.0.1. Moduł przechwytujący 30 klienta przetwarza następnie strumień danych HTTP w specyficzny protokół klient/serwer i przesyła specjalny strumień danych klient/serwer przez zewnętrzne łącze komunikacyjne 35. Moduł przechwytujący 40 serwera odbiera specyficzny strumień danych klient/serwer i odtwarza oryginalny strumień danych HTTP odpowiadający transmisji pochodzącej z przeglądarki. Ten odtworzony oryginalny strumień danych HTTP jest przesyłany do serwera 20. Serwer 20 odpowiada na strumień danych HTTP tak jak normalny serwer internetowy. Serwer 20 może być także pośrednikiem umożliwiającym łączenie się z Internetem wielu przeglądarkom. Gdy serwer 20 otrzymuje informacje dla przesłania do przeglądarki 10, na przykład w odpowiedzi na żądanie przeglądarki o określoną stronę tytułową lokalizatora URL, to serwer 20 wysyła strumień danych HTTP odpowiadający transmisji jaka ma być wysłana do przeglądarki 10. Ta transmisja pochodząca z serwera jest przejmowana przez moduł przechwytujący 40 serwera i przetworzona na specyficzny strumień danych klient/serwer. Specyficzny strumień danych klient/serwer odpowiadający transmisji pochodzącej z serwera jest następnie przesyłany przez zewnętrzne łącze komunikacyjne 35 od drugiego komputera 6 do pierwszego komputera 5. Specyficzny strumień danych klient/serwer jest odbierany przez moduł przechwytujący 30 klienta, odtwarzany i dostarczany jest do przeglądarki 10 oryginalny strumień danych HTTP pochodzący z serwera.

W szczególnym przykładzie wykonania wynalazku zewnętrzne łącze komunikacyjne jest łączem radiowym. W takim przypadku, aby uzyskać parametry systemu akceptowalne przez użytkowników jest pożądane zmniejszenie wielkości transmisji przesyłanej przez zewnętrzne łącze komunikacyjne 35 zarówno w zakresie częstotliwości transmisji jak i ilości informacji, które musza być przesłane przez zewnętrzne łącze komunikacyjne 35. Dlatego wynalazek wykorzystuje pamiętanie pośredniczące, różnicowanie i techniki redukujące

180 570 protokół dla zminimalizowania wielkości transmisji przesyłanej przez zewnętrzne łącze komunikacyjne 35. Te techniki są realizowane przez przetworzenie bezstanowych lub stochastycznych protokołów HTTP w specjalne protokoły klient/serwer, które wykorzystują specyficzne informacje dotyczące klienta i serwera dla ograniczenia wielkości i częstotliwości transmisji. Ponadto, chociaż wynalazek jest opisywany w odniesieniu do pojedynczej aplikacji przeglądarki i pojedynczej aplikacji serwera, korzyści z wynalazku mogą być również osiągnięte przy powiązaniu wielu przeglądarek z jednym serwerem.

W przykładzie wykonania wynalazku zarówno moduł przechwytujący 30 klienta jak i moduł przechwytujący 40 serwera mają pamięć pośredniczącą. Pamięć pośrednicząca klienta umieszczona w pierwszym komputerze 5 zapamiętuje strumienie danych HTTP, które mają być odebrane przez przeglądarkę w odpowiedzi na transmisję pochodzącą z przeglądarki. Pamięć pośrednicząca serwera umieszczona w drugim komputerze 6 zapamiętuje strumienie danych HTTP, które są odbierane z serwera w odpowiedzi na transmisję pochodzącą z przeglądarki.

Pamięć pośrednicząca umieszczona w pierwszym lub drugim komputerze 5 i 6 może mieć rozmiar oparty na określonej konfiguracji sprzętowej komputerów. Te informacje zapamiętywane w pamięci pośredniczącej, zawierają dla każdej transmisji URL unikalny identyfikator oparty na zawartości transmisji takich jak cykliczna kontrola nadmiarowa (CRC) danych transmisji, czas pamiętania danych (SDT) określający czas, w którym wejście podręczne było utworzone lub odświeżone i dane transmisji. Tak wiec katalog wejścia pośredniczącego dla każdej transmisji zapamiętywanej w pamięci pośredniczącej. Ponadto, z powodu ograniczonych zasobów dostępnych w danej konfiguracji sprzętowej może być stosowana, dla podtrzymania pamięci pośredniczącej, w pierwszym i drugim komputerze 5 i 6 pewna liczba technik pośredniczących. Tak wiec na przykład pamięć pośrednicząca może unieważnić najstarszy katalog wejściowy jeśli określony przez użytkownika rozmiar pamięci pośredniczącej byłby przekroczony przez dodanie nowego wejścia, a następnie dodanie nowego wejścia w miejsce wejścia unieważnionego. Ponadto, wejścia pośredniczące mogą być utrzymywane przez wiele żądań aplikacji przeglądarki lub serwera lub nawet cyklami włączenia zasilania pierwszego lub drugiego komputera 5 i 6, dla utworzenia trwałej pamięci pośredniczącej.

Działanie struktury pośredniczącej zgodnie z wynalazkiem będzie opisane w odniesieniu do figur 3 do 6, które przedstawiają sieci działań opisujące operacje modułu przechwytującego 30 klienta i modułu przechwytującego 40 serwera.

Przedstawiony na fig. 3 blok 100 pokazuje, że moduł przechwytujący 30 klienta otrzymał żądanie z przeglądarki 10. To żądanie może mieć postać strumienia danych HTTP. Moduł przechwytujący· 30 klienta sprawdza jednolity lokalizator zasobów (URL) wchodzącego żądania jak pokazano w bloku 105. Moduł przechwytujący 30 klienta określa na podstawie lokalizatora URL czy informacja odpowiadająca żądaniu pochodzącemu z przeglądarki była wcześniej zapamiętana w pamięci pośredniczącej klienta w pierwszym komputerze 5. Jeżeli informacja odpowiadająca lokalizatorowi URL nie była wcześniej zapamiętana w pamięci pośredniczącej klienta wykonywana jest przez moduł przechwytujący 30 klienta operacja przedstawiona w. bloku 106. Moduł przechwytujący 30 klienta przesyła żądanie przez zewnętrzne łącze komunikacyjne 35 do modułu przechwytującego 40 serwera.

Jeżeli jednakże po sprawdzeniu transmisji z przeglądarki, jak pokazano w bloku 105, istnieje wejście pośredniczące klienta, które odpowiada transmisji z przeglądarki to w najprostszym wykonaniu ta informacja będzie dostarczona do przeglądarki jako strumień danych HTTR Jednakże, jak przedstawiono na fig. 3, realizowane jest to, co jest tu określane jako sprawdzenie koherentności przedziału czasu w wejściu pośredniczącym odpowiadającym transmisji z przeglądarki. Ta operacja jest przedstawiona w bloku 110 na fig. 3.

Koherentność przedziału czasu dla modułu przechwytującego 30 klienta może być zdefiniowana przez użytkownika i jest to okres czasu, w którym może istnieć wejście pośrednie, nim stanie się nieaktualne i również, gdy istnieje musi być odświeżane przez żądanie od serwera odpowiadające transmisji z przeglądarki. Sprawdzenie przedziału czasu koherencji przedstawione w bloku 110 może być wykonane przez porównanie bieżącej daty i czasu z sumą SDT wejścia pośredniczącego odpowiadającą transmisji z przeglądarki, a okres kohe

180 570 rencji jest określany przez użytkownika. Jeżeli bieżąca data i czas są większe niż ta suma to informacja zapamiętana w pamięci pośredniczącej odpowiadająca transmisji pochodzącej z przeglądarki staje się nieaktualna i przyjmowana jest gałąź nie z bloku 110. Jednakże, jeżeli bieżąca data i czas są większe niż suma SDT plus zdefiniowany przez użytkownika przedział koherencji to przyjmowana jest gałąź tak z bloku 110 i jak pokazano w bloku 111 i wejście pośredniczące jest dostarczane do przeglądarki jako strumień danych HTTP. W ten sposób zamyka się transmisję pochodzącą z przeglądarki przez moduł przechwytujący 30 klienta w bloku 100 na fig. 3.

Jeżeli sprawdzenie przedziału koherentności przedstawione w bloku 110 wykazuje, że wejście pośredniczące umieszczone w pierwszym komputerze 5 jest nieaktualne, przekazywane jest do modułu przechwytującego 40 serwera sprawdzenia koherentności wejścia pośredniczącego umieszczonego w drugim komputerze 6. Ta operacja jest przedstawiona w bloku 112 na fig. 3. Jest to wykonane przez dostarczenie przez zewnętrzne łącze komunikacyjne 35 do modułu przechwytującego 40 serwera przedziału koherencji dla określonego modułu przechwytującego 30 klienta żądania pochodzącego z przeglądarki 10 i unikalnego wskaźnika zawartości pamięci pośredniczącej klienta odpowiadającego URL transmisji pochodzącej z przeglądarki. Korzystnie, ten unikalny wskaźnik powstaje w wyniku cyklicznej kontroli nadmiarowej CRC dla wejścia pośredniczącego.

Na fig. 5 przedstawiono sieć działań modułu przechwytującego 40 strony serwera w odpowiedzi na informację odebraną przez zewnętrzne łącze komunikacyjne 35 z modułu przechwytującego 30 klienta. Gdy moduł przechwytujący 40 strony serwera otrzymuje żądanie od modułu przechwytującego 30 klienta moduł przechwytujący 40 strony serwera odbiera wcześniej określony przedział czasu koherencji klienta, wartość kontrolna CRC wejścia pośredniczącego klienta i żądanie HTTP pochodzące z przeglądarki. Odebranie tej informacji jest pokazane w bloku 120 fig. 5.

Po odebraniu informacji z modułu przechwytującego 30 klienta, moduł przechwytujący 40 strony serwera sprawdza pamięć pośredniczącą serwera umieszczoną w drugim komputerze 6 dla stwierdzenia czy istnieje wejście pośredniczące serwera odpowiadające lokalizatorowi URL żądania HTTP pochodzącego z przeglądarki. Jeżeli po sprawdzeniu transmisji pochodzącej z przeglądarki, jak pokazano w bloku 125 moduł przechwytujący 40 strony serwera stwierdza, że istnieje wejście pośredniczące odpowiadające informacji żądanej w transmisji pochodzącej z przeglądarki to przyjmowana jest gałąź tak z bloku 125. Moduł przechwytujący 40 strony serwera porównuje następnie bieżącą datę i czas SSI modułu przechwytującego 40-strony serwera z sumą SDT wejścia pośredniczącego serwera odpowiadającą informacji żądanej w transmisji pochodzącej z przeglądarki i wcześniej określonym przedziałem czasu koherencji klienta otrzymanym z modułu przechwytującego 30 klienta. Jeżeli bieżącą data i czas są mniejsze niż suma SDT wejścia pośredniczącego serwera i przedziału koherencji to przyjmowana jest gałąź tak z bloku 130 z fig. 5. Moduł przechwytujący 40 strony serwera porównuje następnie wartość kontrolna CRC wejścia pośredniczącego serwera z wartością kontrolną CRC wejścia pośredniczącego klienta dla sprawdzenia czy wejścia pośredniczące są identyczne. Jeżeli dwa wejścia pośredniczące są identyczne, to przyjmowana jest gałąź tak z bloku 135 i jak pokazano w bloku 136 koherentna odpowiedź jest wysyłana do modułu przechwytującego 30 klienta.

Jeżeli warunek z bloku 135 określa, że wartości kontrolne CRC nie są równe to informacje zawarte w wejściu pośredniczącym klienta i w wejściu pośredniczącym serwera nie są identyczne i jak pokazano w bloku 137, moduł przechwytujący 40 strony serwera przesyła wejście pośredniczące serwera do pierwszego komputera 5 przez zewnętrzne łącze komunikacyjne 35. Przesyłając wejście pośredniczące serwera do modułu przechwytującego 30 klienta, moduł przechwytujący 40 strony serwera przetwarza wejście w specjalny protokół komunikacyjny, który zawiera wartości kontrolne CRC wejścia pośredniczącego serwera, dane wejścia pośredniczącego serwera i wiek wejścia pośredniczącego serwera. Wiek wejścia pośredniczącego serwera jest obliczany przez odejmowanie od bieżącej daty i czasu SDT wejścia pośredniczącego.

180 570

Na koniec, w odniesieniu do fig. 5, jeżeli albo suma SDT plus wstępnie określony przedział czasu koherencji klienta jest mniejszy niż bieżąca data i czas lub jeśli nie ma wejścia pośredniczącego odpowiadającego lokalizatora URL transmisji pochodzącej z przeglądarki, to odpowiednio przyjmowana jest ścieżka nie z bloku 130 lub ścieżka nie z bloku 125. Będzie więc wykonana operacja z bloku 126 i moduł przechwytujący 40 strony serwera prześle do serwera transmisję pochodzącą z przeglądarki jako strumień danych HTTP. Jeżeli moduł przechwytujący 40 strony serwera musi przesłać do serwera transmisję pochodzącą z przeglądarki jako strumień danych HTTP to moduł przechwytujący 40 strony serwera będzie wykonywał operacje z fig. 6.

Jak pokazano w bloku 140 na fig. 6 w odpowiedzi na transmisję pochodzącą z przeglądarki, moduł przechwytujący 40 strony serwera odbierze strumień danych HTTP z serwera 20. Na potwierdzenie strumienia danych HTTP, moduł przechwytujący 40 strony serwera obliczy wartości kontrolne CRC dla strumienia danych HTTP i chwilowo zapamięta strumień danych HTTP. Następnie, jak pokazano w bloku 145 moduł przechwytujący 40 strony serwera sprawdzi strumień danych HTTP i określi czy istnieje wejście pośredniczące serwera odpowiadające lokalizatorowi URL strumienia danych HTTP. Jeżeli takie wejście istnieje to wykonana jest ścieżka tak z bloku 145. Moduł przechwytujący 40 strony serwera porówna następnie ostatnio obliczoną wartość kontrolną CRC strumienia danych odebranego z serwera 20 z wartością kontrolną CRC wejścia pośredniczącego serwera odpowiadającego lokalizatorowi URL transmisji odpowiedzi pochodzącej z serwera jak pokazano w bloku 150. Jeżeli wartości kontrolne CRC są takie same to wykonana jest ścieżka tak z bloku 150. Moduł przechwytujący 40 strony serwera uaktualnia wejście SDT dla wejścia pośredniczącego serwera jak pokazano w bloku 151 i usuwa chwilowo pamiętany strumień danych HTTP odebranych przez serwer 20, jak pokazano w bloku 152. '

Jeżeli wynik porównania wartości kontrolnych CRC wskazuje, że wejście pośredniczące serwera jest inne niż strumień danych HTTP odebranych z serwera 20 to wykonana jest ścieżka nie z bloku 150. Moduł przechwytujący 40 strony serwera pobiera z wejścia pośredniczącego serwera istniejące dane, jak pokazano w bloku 153, a następnie, jak pokazano w bloku 154, uaktualnia wejście pośredniczące serwera nowymi informacjami. Jak pokazano w bloku 154 ta aktualizacja zawiera zapamiętanie w wejściu pośredniczącym serwera wartości kontrolne CRC transmisji serwera pamiętanej jako cześć wejścia pośrednicżącego bieżącą datę i czas jako wartość SDT dla wejścia pośredniczącego i zapamiętanie strumienia danych HTTP. W jednym z przypadków, gdy wejście pośredniczące serwera jest uaktualnione lub gdy wejście pośredniczące serwera jest identyczne ze strumieniem danych HTTP odebranych z serwera 20, moduł przechwytujący 40 strony serwera określa, czy wejście pośredniczące serwera jest identyczne z wejściem pośredniczącym klienta odpowiadającym transmisji pochodzącej z przeglądarki. Ta operacja jest pokazana w bloku 155.

Jeżeli moduł przechwytujący 40 strony serwera określa, że wejście pośredniczące odpowiadające odpowiedzi odebranej z serwera 20 nie istnieje, to wykonana jest ścieżka nie z bloku 145. Wejście pośredniczące serwera jest tworzone, jak pokazano w bloku 146, przez zapamiętanie lokalizatora URL w odpowiedzi z serwera, przez zapamiętanie strumienia danych HTTP i przez zapamiętanie jako wartość SDT bieżącej daty i czasu. Po utworzeniu wejścia pośredniczącego transmisji pochodzącej z przeglądarki, moduł przechwytujący 40 strony serwera porównuje następnie ponownie wartości kontrolne CRC wejścia pośredniczącego tego serwera z wartościami kontrolnymi CRC odpowiedniego wejścia pośredniczącego klienta, jak pokazano w bloku 155.

Jeżeli wynik porównania wejścia pośredniczącego serwera z wejściem pośredniczącym klienta wskazuje, że wejścia pośredniczące są identyczne to przyjęta jest ścieżka tak z bloku 155 i wykonane są operacje z bloku 156. W bloku 156 pokazano, że moduł przechwytujący 40 strony serwera przesyła odpowiedź koherentną do modułu przechwytującego 30 klienta. Moduł przechwytujący 40 strony serwera przetwarza żądanie wejścia pośredniczącego w specjalny strumień danych klient/serwer wysyłając odpowiedź koherentną i wysyłając wiek zero do modułu przejmującego klienta.

180 570

Jeżeli moduł przechwytujący 40 strony serwera określa, że wejście pośredniczące klienta nie jest identyczne z wejściem pośredniczącym serwera odpowiadającym transmisji pochodzącej z przeglądarki to przyjęta jest ścieżka nie z bloku 155 i wykonane są operacje z bloku 157. Jak pokazano w bloku 157 moduł przechwytujący 40 strony serwera przetwarza wejście pośredniczące serwera w specjalny strumień danych klient/serwer. Strumień danych zawiera wartości kontrolne CRC wejścia pośredniczącego serwera, strumień danych HTTP wejścia pośredniczącego serwera i wiek wejścia pośredniczącego, który jest ustawiony na zero. Ta specjalna transmisja klient/serwer jest następnie przesyłana przez zewnętrzne łącze komunikacyjne 35 do modułu przechwytującego 30 klienta.

Funkcje modułu przechwytującego 30 klienta po potwierdzeniu transmisji z modułu przechwytującego 40 strony serwera będzie opisana w odniesieniu do fig. 4. Jak pokazano w bloku 160 moduł przechwytujący 30 klienta odbiera lub uzyskuje specjalny strumień danych klient/serwer, który był przesłany zewnętrznym łączem komunikacyjnym 35. Moduł przechwytujący 30 klienta określa następnie jakiego typu odpowiedź odebrano od modułu przechwytującego 40 strony serwera, jak pokazano w bloku 165. Jeżeli moduł przechwytujący 40 strony serwera określi że wejście pośredniczące klienta jest koherentne, to jest wejście pośredniczące klienta i wejście pośredniczące serwera są identyczne, to wykonane są operacje pokazane w bloku 166. Jak pokazano w bloku 160 moduł przechwytujący 30 klienta uaktualnia czas SDT wejścia pośredniczącego klienta odpowiadającego transmisji pochodzącej z przeglądarki o różnicę pomiędzy bieżącą datą i czasem, a wiekiem odebranym z modułu przechwytującego 40 strony serwera. Tak więc bez synchronizacji zegarów pierwszego komputera 5 i drugiego komputera 6 sprawdza się koherencję czasową wejścia pośredniczącego pierwszego komputera 5, aby uwzględnić nowsze dane z drugiego komputera 6. Po uaktualnieniu wartości SDT dla wejścia pośredniczącego klienta odpowiadającego transmisji pochodzącej z przeglądarki moduł przechwytujący 30 klienta przesyła wejście pośredniczące klienta do przeglądarki 10 jako strumień danych HTTP. Ta operacja jest pokazana w bloku 174.

Jeżeli jednak moduł przechwytujący 30 klienta ustali, że odpowiedź jest typu danych lub strumienia danych to obierana jest ścieżka strumień z bloku 165 i wykonywana jest operacja 167. Moduł przechwytujący 30 klienta odbiera strumień danych HTTP i chwilowo zapamiętuje te dane. Następnie, jak pokazano w bloku 170 z fig. 4 moduł przechwytujący 30 klienta określa czy istnieje wejście pośredniczące odpowiadające transmisji pochodzącej z przeglądarki. Jeżeli wejście pośredniczące istnieje to obierana jest ścieżka tak z bloku 170 i jak pokazano w bloku 171, istniejące wejście pośredniczące jest usuwane. Moduł przechwytujący 30 klienta uaktualnia następnie wejście pośredniczące klienta odpowiadające transmisji pochodzącej z przeglądarki przez zapamiętanie wartości CRC strumienia HTTP odebranego z modułu przechwytującego 40 strony serwera, przez zapamiętanie jako wartości SDT różnicy pomiędzy bieżącą datą i czasem, a wiekiem odebranym z modułu przechwytującego 40 strony serwera i przez zapamiętanie strumienia danych HTTP. Ta operacja jest pokazana w bloku 172.

Jeżeli nie istnieje wejście pośredniczące odpowiadające transmisji pochodzącej z przeglądarki to obierana jest ścieżka nie z bloku 170. Wejście pośredniczące klienta jest tworzone przez wykonanie operacji przedstawionych w bloku 173. W bloku 173 moduł przechwytujący 30 klienta tworzy wejście pośredniczące klienta przez zapamiętanie UTL strumienia danych HTTP odebranych z modułu przechwytującego 40 strony serwera przez zapamiętanie wartości CRC strumienia danych HTTP odebranych z modułu przechwytującego 40 strony serwera i przez zapamiętanie strumienia danych HTTP. Moduł przechwytujący 30 klienta uaktualnia wartości SDT lub zapamiętuje wartości SDT przez odjecie od bieżącej daty i czasu wieku odebranego przez zewnętrzną linię komunikacyjną 35 z modułu przechwytującego 40 strony serwera.

Chociaż wejście pośredniczące klienta jest tworzone przez wykonanie operacji przedstawionych w blokach 176, 172, lub 173 moduł przechwytujący 30 klienta przesyła lub dostarcza wejście pośredniczące klienta do przeglądarki 10 jako strumień danych HTTP. Te operacje są pokazane w bloku 174 z fig. 4.

180 570

Wejście pośredniczące klienta i wejście pośredniczące serwera mogą być zrealizowane w pamięci lub pamięci masowej takiej jak twardy dysk, dyski CD-ROMS, optyczne lub w innych technikach pamięciowych. Ponadto, moduł przechwytujący klienta i moduł przechwytujący serwera mogą być wykonane w postaci sprzętowej, programowej lub w ich kombinacji.

Chociaż w przedstawianych przypadkach pamięci pośredniczące są umieszczane w pierwszym lub drugim komputerze 5 i 6, korzystne jest także, gdy pamięć pośrednicząca nie jest umieszczona w pierwszym komputerze 5 ale znajduje się po prostu po tej samej stronie zewnętrznej linii komunikacyjnej 35 jak komputer. Zatem sprzętowy element pośredniczący służący jako element pośredniczący klienta może być umieszczony na zewnątrz pierwszego komputera 5 i być z nim połączony szybką transmisją również, gdy element pośredniczący jest po tej samej stronie co pierwszy komputer 5.

W alternatywnym rozwiązaniu według wynalazku, moduł przechwytujący 40 strony serwera nie utrzymuje kopii strumienia danych HTTP odebranych z serwera 20, ale po prostu utrzymuje element katalogu dla transmisji. Element katalogu zawiera URL transmisji, wartości CRC obliczone dla strumienia danych HTTP i czas odbioru strumienia danych HTTP z serwera i wartości SDT dla transmisji, który może być przyjęty jako czas, w którym były obliczane wartości CRC. W takim przypadku, gdy moduł przechwytujący 30 klienta wysyła żądanie do modułu przechwytującego 40 strony serwera dla transmisji, która odpowiada lokalizatorowi URL, dla którego moduł przechwytujący 40 strony serwera utrzymuje wartości CRC i STD, następnie moduł przechwytujący 40 strony serwera sprawdza wartości CRC otrzymane z modułu przechwytującego 30 klienta dla określenia czy odpowiada on wartości CRC ostatniego strumienia danych HTTP dla określonego lokalizatora URL. Jeżeli tak, to wysyłana jest koherentna odpowiedź do modułu przechwytującego 30 klienta. Jeżeli nie, to moduł przechwytujący 40 strony serwera przesyła strumień danych HTTP otrzymany z modułu przechwytującego 30 klienta do serwera 20 i odsyła do modułu przechwytującego 30 klienta odpowiedź otrzymaną z serwera 20.

Figury 7, 8, 9 i 10 przedstawiają sieć działań operacji wykonywanych przez moduł przechwytujący 30 klienta i moduł przechwytujący 40 strony serwera w innym rozwiązaniu według wynalazku, które wykorzystuje różnicowanie dla ograniczenia danych przesyłanych przez zewnętrzne łącze komunikacyjne 35. Jak pokazano na fig. 7 blok 200 ilustruje potwierdzenie przez moduł przechwytujący 30 klienta żądania HTTP z przeglądarki 10. Jak pokazano w bloku 205, moduł przechwytujący 30 klienta sprawdza przejęte żądanie HTTP z przeglądarki 10 dla stwierdzenia, czy jest to żądanie do wspólnego interfejsu przejścia (CGI). Jeżeli nie jest to żądanie do interfejsu to moduł przechwytujący 30 klienta przepuszcza żądanie do modułu przechwytującego 40 strony serwera jak pokazano na fig. 3 do 6 i przedstawiono w bloku 206 z fig. 7.

Jeżeli jednakże transmisja pochodząca z przeglądarki odpowiada żądaniu interfejsu CGI to obierana jest ścieżka tak z bloku 205. Jak pokazano w bloku 205, moduł przechwytujący 30 klient/serwer określa, czy istnieje bazowe wejście pośredniczące klienta odpowiadające strumieniowi danych HTTP, który był poprzednio dostarczony do przeglądarki w odpowiedzi na odpowiednie żądanie interfejsu CGI. To sprawdzenie żądania interfejsu CGI może być wykonane przez porównanie lokalizatora. URL transmisji pochodzącej z przeglądarki z lokalizatorem URL zapamiętanym w bazowym wejściu pośredniczącym klienta.

Bazowe wejście pośredniczące klienta może być inicjalizowane przez zapamiętanie pierwszego strumienia danych HTTP.odebranego przez moduł przechwytujący 30 klienta, który ma być dostarczony do przeglądarki 10 dla danego lokalizatora URL. To bazowe wejście pośredniczące może być utrzymywane przez wiele żądań lub sesji przeglądarki 10. Bazowe wejście pośredniczące klienta może być aktualizowane jak pokazano na fig. 7, 8, 9 i 10. Jeżeli istnieje bazowe wejście pośredniczące klienta odpowiadające lokalizatorowi URL dla transmisji pochodzącej z przeglądarki, to wartość CRC, która ma być wysłana do modułu przechwytującego 40 strony serwera przez zewnętrzne łącze komunikacyjne 35 jest ustalana jako równa wartość CRC dla bazowego wejścia pośredniczącego klienta, jak pokazano w bloku 211 z fig. 7. Jeżeli nie istnieje bazowe wejście pośredniczące klienta, to obierana jest

180 570 ścieżka nie z bloku 210 z fig. 7 i wartość CRC dla żądania, która ma być wysłana przez zewnętrzne łącze komunikacyjne 35 do modułu przechwytującego 40 strony serwera jest kasowane. Ta operacja jest przedstawiona w bloku 212 z fig. 7.

Blok 213 przedstawia operacje wysyłania żądania interfejsu CGI do modułu przechwytującego 40 strony serwera przez zewnętrzne łącze komunikacyjne 35. Jak przedstawiono w bloku 213 moduł przechwytujący 30 klienta przesyła żądanie HTTP i żądanie wartości CRC, które albo zostało ustalone na zero, jeżeli nie istnieje bazowe wejście pośredniczące klienta dla lokalizatora URL żądania interfejsu CGI lub zostało ustalone jako wartość CRC bazowego wejścia pośredniczącego klienta, jeżeli wejście istnieje. Tak wiec moduł przechwytujący 30 klienta przekształca żądanie interfejsu CGI na specjalny protokół klient/serwer, przesyła specjalną transmisję klient/serwer, która ma być odebrana przez moduł przechwytujący 40 strony serwera, przez zewnętrzne łącze komunikacyjne 35.

Działania podjęte przez moduł przechwytujący 40 strony serwera, gdy odebrane jest żądanie interfejsu CGI jest przedstawione na fig. 9. Potwierdzenie żądania interfejsu CGI przez moduł przechwytujący 40 strony serwera jest pokazane w bloku 220. Gdy moduł przechwytujący 40 strony serwera odbiera żądanie interfejsu CGI zapamiętuje on kopię wartości CRC i żądania HTTP. Jak pokazano w bloku 221 moduł przechwytujący 40 strony serwera przesyła żądanie HTTP do serwera 20.

Gdy moduł przechwytujący 40 strony serwera odbiera odpowiedź na żądanie HTTP odpowiadające transmisji pochodzącej z przeglądarki, lub żądanie interfejsu CGI, moduł przechwytujący 40 strony serwera odbiera tą odpowiedź jako strumień danych HTTP, jak pokazano w bloku 230 z fig. 10. Moduł przechwytujący 40 strony serwera zapamiętuje strumień danych HTTP i oblicza wartość CRC dla strumienia danych HTTP odebranych z serwera 20. Moduł przechwytujący 40 strony serwera zeruje także wartości różnicowe dla inicjalizacji różnicy danych. Moduł przechwytujący 40 strony serwera określa następnie, czy odpowiedź otrzymana jako transmisja pochodzącą z serwera jest odpowiedzią na żądanie interfejsu CGI, jak pokazano w bloku 235. Jeśli tak, to obierana jest ścieżka nie z bloku 235 z fig. 10 i realizowane są operacje w bloku 236 dla wysłania strumienia danych HTTP do modułu przejmującego klienta. Jak pokazano w bloku 236 ta operacja może polegać na tworzeniu elementu pośredniczącego, co pokazano na fig. 3 do 6. Jeżeli odpowiedź odebrana w bloku 230 jest odpowiedzią na żądanie interfejsu CGI to obierana jest ścieżka tak z bloku 235 i moduł przechwytujący 40 strony serwera określa następnie czy istnieje bazowe wejście pośredniczące serwera dla odpowiedzi interfejsu CGI, jak pokazano w bloku 240.

Bazowe wejście pośredniczące serwera może być utworzone, gdy moduł przechwytujący 40 strony serwera pierwszy raz odbiera odpowiedź na żądanie interfejsu CGI. W tym przypadku wynik warunku przedstawionego w bloku 240 będzie powodował obranie ścieżki nie z bloku 240. Moduł przechwytujący 40 strony serwera będzie następnie tworzył bazowe wejście pośredniczące serwera odpowiadające żądaniu interfejsu CGI przez zapamiętanie lokalizatora URL dla interfejsu CGI, strumienia danych HTTP dla odpowiedzi na żądanie interfejsu CGI i wartości CRC dla strumienia danych HTTP. Ta operacja jest przedstawiona w bloku 241. Dla zgodności z koherentnym systemem tworzenia elementu pośredniczącego opisanego na fig. 3 do 6 bazowe wejście pośredniczące serwera może także zawierać wartości SDT. Termin forma bazowa interfejsu CGI serwera odnosi się tutaj do bazowego wejścia pośredniczącego serwera odpowiadającego żądaniu interfejsu CGI otrzymanemu z przeglądarki 10.

Jeżeli istnieje bazowe wejście pośredniczące serwera odpowiadające żądaniu interfejsu CGI to obierana jest ścieżka tak z bloku 240. Moduł przechwytujący 40 strony serwera porównuje wartość CRC bazowego wejścia pośredniczącego serwera z wartościami CRC odpowiedzi otrzymanej z serwera 20. Te operacje są przedstawione w bloku 245 z fig. 10. Jeżeli wartości CRC są takie same to moduł przechwytujący 40 strony serwera określa czy wartości CRC bazowego wejścia pośredniczącego serwera odpowiada wartości CRC bazowego wejścia pośredniczącego klienta. Jeżeli te dwie wartości są takie same to bazowe wejście pośredniczące klienta, bazowe wejście pośredniczące serwera i odpowiedź otrzymana z serwera 20, wszystkie zawierają ten sam strumień danych HTTP. Porównanie bazowego wejścia pośredniczącego serwera i bazowego wejścia pośredniczącego klienta jest przedstawione w bloku 250.

180 570

Jeżeli oba bazowe wejścia pośredniczące są takie same to moduł przejmujący strony serwera nie potrzebuje przesyłać bazowego wejścia pośredniczącego do modułu przechwytującego 30 klienta, a więc jak pokazano w bloku 251, strumień danych HTTP, który ma być przesłany do modułu przechwytującego 30 klienta jest zerowany. Moduł przechwytujący 40 strony serwera będzie następnie przetwarzał strumień danych HTTP odebrany z serwera 20 w specjalny protokół komunikacyjny klient/serwer przez przesłanie wartości CRC strumienia danych HTTP zapamiętanego w bazowym wejściu pośredniczącym serwera, odpowiadającego żądaniu interfejsu CGI, wyzerowany strumień danych HTTP i wyzerowana różnica danych dla wskazania, że odpowiedź na żądanie interfejsu CGI była identyczna z bazowym wejściem pośredniczącym klienta, jak pokazano w bloku 252.

Wracając do bloku 245, jeżeli wartość CRC dla bazowego wejścia pośredniczącego serwera odpowiadającego żądaniu interfejsu CGI jest różna niż wartość CRC dla odpowiedzi otrzymanej z serwera w odpowiedzi na żądanie interfejsu CGI pochodzące z przeglądarki to obierana jest ścieżka nie z bloku 245. Moduł przechwytujący 40 strony serwera będzie następnie wykonywał operacje przedstawione w bloku 246. Moduł przechwytujący 40 strony serwera porównuje przejętą odpowiedź interfejsu CGI do bazowego wejścia pośredniczącego serwera odpowiadającą przejętemu żądaniu interfejsu CGI lub bazowej formie interfejsu CGI serwera.

To porównanie przejętej odpowiedzi interfejsu CGI z bazową formą CGI serwera daje różnicę danych interfejsu CGI, która odpowiada różnicy pomiędzy przejętą odpowiedzią interfejsu CGI i formą bazową interfejsu CGI serwera. Różnicowanie może być wykonane dowolnym sposobem pozwalającym określić różnicę pomiędzy formą podstawową a formą zmodyfikowaną.

Moduł przechwytujący 40 strony serwera określa następnie czy forma bazowa interfejsu CGI serwera wymaga aktualizacji, jak pokazano w bloku 247. To określenie może być wykonane przez ustalenie, czy średnia różnica danych pomiędzy przejętą odpowiedzią interfejsu CGI i formą bazową interfejsu CGI serwera jest powyżej wstępnie ustalonego progu. Inne sposoby określenia czy bazowe wejście pośredniczące serwera odpowiadające żądaniu interfejsu CGI powinno być aktualizowane mogą zawierać koherentność czasu, tak jak przedstawiono na fig. 3 do 6 lub inne sposoby pozwalające określić, czy różnica danych wzrosła w takim stopniu, że przebazowanie dla utworzenia nowego bazowego wejścia pośredniczącego może poprawić parametry systemu.

Jeżeli przebazowanie nie jest wymagane to obierana jest ścieżka nie z bloku 247 i moduł przechwytujący 40 strony serwera będzie następnie wykonywał operacje przedstawione w bloku 250 dla określenia czy wartość CRC bazowego wejścia pośredniczącego klienta jest taka sama jak wartość CRC bazowego wejścia pośredniczącego serwera lub forma bazowa interfejsu CGI serwera jest identyczna z formą bazową interfejsu CGI klienta, które są wejściami pośredniczącymi serwera i klienta, które odpowiadają określonemu żądaniu interfejsu CGI z transmisji pochodzącej z przeglądarki. Jeżeli formy bazowe są takie same to klient nie potrzebuje być przebazowany i strumień informacji HTTP jest zerowany, jak przedstawiono w bloku 251. Moduł przechwytujący 40 strony serwera będzie następnie wysyłał różnicę odpowiedzi do modułu przechwytującego 30 klienta przez wysłanie wartości CRC bazowego wejścia pośredniczącego serwera odpowiadającego żądaniu interfejsu CGI (to jest wartości CRC formy bazowej interfejsu CGI serwera), przez wysłanie wyzerowanego strumienia danych HTTP który odpowiada danym bazowym i przez wysłanie różnicy danych określonych w bloku 246. Te operacje sąponownie pokazane jako blok 252 z fig. 10.

Jeżeli moduł przechwytujący 40 strony serwera określi, że wartości CRC nie są takie same dla formy bazowej CGI klienta i formy bazowej interfejsu CGI serwera to klient powinien się przebazować. Operacja przebazowania klienta zawiera wysłanie formy bazowej interfejsu CGI serwera do modułu przechwytującego 30 klienta. Dla wykonania tej operacji moduł przechwytujący 40 strony serwera ustala, strumień danych HTTP jakie mają być przesłane do modułu przechwytującego 30 klienta, jako równy formie bazowej interfejsu CGI serwera. Ta operacja jest przedstawiona w bloku 253. Moduł przechwytujący 40 strony serwera przekształca strumień danych HTTP odebranych z serwera w specjalny protokół klient/serwer

180 570 przez przesłanie wartości CRC formy bazowej interfejsu CGI, strumienia danych HTTP odpowiadającego formie bazowej interfejsu CGI serwera i przesłaniu różnicy danych pomiędzy formą bazową interfejsu CGI, a odpowiedzią odebraną z serwera, jak pokazano w bloku 252. Ta informacja jest następnie przesyłana przez zewnętrzne łącze komunikacyjne 35 do modułu przechwytującego 30 klienta.

Wracając do bloku 247, jeżeli wymagane jest przebazowanie serwera to obierana jest ścieżka tak z bloku 247. Jak pokazano w bloku 248 moduł przechwytujący 40 strony serwera aktualizuje bazowe wejście pośredniczące serwera odpowiadające transmisji pochodzącej z przeglądarki ze strumieniem danych HTTP otrzymanym z serwera. Wartość CRC odpowiedzi jest także aktualizowana, a różnica danych interfejsu CGI jest zerowana. Moduł przechwytujący 40 strony serwera porównuje następnie wartość CRC nowego wejścia pośredniczącego serwera, jak pokazano w bloku 250 i kończy przesyłanie jak opisano powyżej.

Działania modułu przechwytującego 30 klienta po potwierdzeniu odpowiedzi modułu przechwytującego 40 strony serwera są pokazane na fig. 8. Potwierdzenie odpowiedzi modułu przechwytującego 40 strony serwera przez moduł przechwytujący 30 klienta jest przedstawione w bloku 260. Jak pokazano w bloku 265 moduł przechwytujący 30 klienta określa, czy odpowiedź jest odpowiedziąna żądanie interfejsu CGI. Jeżeli odpowiedź nie jest odpowiedzią na żądanie interfejsu CGI to moduł przechwytujący 30 klienta wykonuje operacje w bloku 267, które mogą zawierać operacje tworzenia elementu pośredniczącego pokazane na fig. 3 do 6. Jeżeli jednak odpowiedź jest odpowiedzią na żądanie interfejsu CGI to obierana jest ścieżka tak z bloku 265. Moduł przechwytujący 30 klienta zapamiętuje dane strumienia danych HTTP, dane różnicy i wartość CRC uzyskaną ze specjalnego strumienia danych klient/serwer przesyłanego przez zewnętrzne łącze komunikacyjne. Te operacje są przedstawi one w bloku 266 na fig. 8.

Moduł przechwytujący 30 klienta określa, czy istnieje bazowe wejście pośredniczące klienta odpowiadające przejętemu żądaniu interfejsu CGI, które zawiera formę bazową CGI klienta. To badanie jest pokazane w bloku 270 i może być wykonane przez sprawdzenie lokalizatora URL żądania HTTP lub odpowiedzi HTTP. Jeżeli istnieje forma bazowa interfejsu CGI klienta to obierana jest ścieżka tak z bloku 270. Moduł przechwytujący 30 klienta porównuje następnie wartości CRC otrzymane przez zewnętrzne łącze komunikacyjne z wartościami CRC formy bazowej interfejsu CGI klienta, jak pokazano w bloku 275. Jeżeli są one różne, to obierana jest ścieżka nie z bloku 275 i klient przebazowuje się uaktualniając formę bazową interfejsu CGI przez zamianę bazowego wejścia pośredniczącego klienta odpowiadającego lokalizatora URL żądania interfejsu CGI z transmisji pochodzącej z przeglądarki ze strumieniem danych HTTP otrzymanym przez zewnętrzne łącze komunikacyjne 35 z modułu przechwytującego 40 strony serwera. Bazowe wejście pośredniczące klienta także jest uaktualnione w stosunku do wartości CRC dla strumienia danych HTTP. Te operacje są przedstawione w bloku 276 na fig. 8.

Jeżeli wartość CRC otrzymana przez zewnętrzne łącze komunikacyjne 35 jest taka sama jak wartość CRC formy bazowej interfejsu CGI to forma bazowa interfejsu CGI serwera modułu przejmującego strony serwera jest taka sama jak forma bazowa interfejsu CGI klienta modułu przechwytującego 30 strony klienta i obierana jest ścieżka tak z bloku 275.

Jeśli formy bazowe są takie same lub klient jest przebazowywany, operacje przedstawione w bloku 277 są wykonywane przez moduł przechwytujący 30 klienta. Blok 277 przedstawia odtwarzanie przez moduł przechwytujący 30 klienta strumienia danych HTTP odpowiadającego transmisji z serwera 20 ze specjalnego strumienia danych klient/serwer otrzymanego przez zewnętrzne łącze komunikacyjne 35, przez łączenie formy bazowej interfejsu CGI klienta z różnicą danych interfejsu CGI otrzymaną przez zewnętrzne łącze komunikacyjne 35 dla utworzenia strumienia danych HTTP odpowiadającego przejętej odpowiedzi interfejsu CGI. Jak pokazano w bloku 278 ta odpowiedź jest następnie dostarczana do przeglądarki jako strumień danych HTTP.

Jeżeli nie istnieje forma bazowa interfejsu CGI w odpowiadającym lokalizatorze URL klienta żądaniu interfejsu CGI to obierana jest ścieżka nie z bloku 270 z fig. 8. Jak pokazano w bloku 271 moduł przechwytujący 30 klienta tworzy bazowe wejście pośredniczące

180 570 klienta odpowiadające lokalizatorowi URL żądania interfejsu CGI, przez zapamiętanie lokalizatora URL, wartości CRC strumienia danych HTTP, odebranego przez zewnętrzne łącze komunikacyjne 35 z modułu przechwytującego 40 strony serwera i aktualnych danych strumienia danych HTTP. Zapamiętując te informacje tworzy bazowe wejście pośredniczące klienta odpowiadające przejętemu żądaniu interfejsu CGI, a więc tworzy formę bazową interfejsu CGI klienta. Moduł przechwytujący. 30 klienta może następnie wykonać operacje z bloku 277 przez odtworzenie strumienia danych HTTP przez dodawanie lub łączenie formy bazowej interfejsu CGI klienta ż. różnicą danych interfejsu CGI, które mogły zostać wyzerowane.

Przedstawiona technika różnicowania może także być zastosowana do danych nie będących danymi interfejsu CGI. W takim przypadku moduł przechwytujący 40 strony serwera może potrzebować utworzyć wiele bazowych wejść pośredniczących serwera dla umożliwienia, aby moduły przechwytujące 30 przeglądarek dołączone do serwera mogły mieć różne formy bazowe. Moduł przechwytujący 40 strony serwera może następnie porównać wartości CRC otrzymane z modułu przechwytującego 30 strony klienta z wartościami CRC każdej wcześniej utworzonej formy bazowego serwera aż do uzyskania zgodności. Moduł przechwytujący 40 strony serwera może następnie opcjonalnie przebazować moduł przechwytujący 30 klienta lub po prostu dostarczyć dane różnicowe do modułu przechwytującego 30 klienta. Tak więc metodologie różnicowania opisane tu w odniesieniu do żądania interfejsu CGI mogą również być stosowane do dowolnego żądania lub odpowiedzi HTTP.

Dla ograniczenia pamięci lub wymagań dotyczących zapamiętywania i stosowania sposobów tworzenia elementów pośredniczących opisanych powyżej można stosować następujące korzystne sposoby różnicowania żądań nie będących żądaniami interfejsu CGI. W tym korzystnym wykonaniu moduł przechwytujący strony serwera oblicza różnicę pomiędzy formą bazową serwera odpowiadającą żądaniu i strumieniowi danych HTTP odpowiedzi z serwera. Te dane różnicowe są następnie zapamiętywane w module przechwytującym strony serwera. Forma bazowa serwera jest następnie aktualizowana przez zastępowanie formy bazowej nową odpowiedzią serwera z uwzględnieniem aktualizacji wartości CRC formy bazowej: Jednakże zamiast odrzucenia starej wartości CRC, wartości CRC poprzednich form bazowych są zapamiętywane jako dane różnicowe. Poprzednie generacje danych różnicowych i wartości CRS są następnie selektywnie przesyłane do modułu przejmującego strony klienta oparty na wartości CRC formy bazowej klienta odpowiadającej żądaniu nieodpowładającemu interfejsu CGI.

Jako przykład sposobu różnicowania danych nie będących danymi interfejsu CGI, gdy moduł przechwytujący strony serwera odbiera żądanie danych nie będących danymi interfejsu CGI temu żądaniu powinna towarzyszyć wartość CRC formy bazowej umieszczonej w module przejmującym strony klienta odpowiadające lokalizatorowi URL żądania danych nie będących danymi interfejsu CGI. Gdy moduł przechwytujący strony serwera odebrał odpowiedź od serwera, może obliczyć wartość CRC odpowiedzi. Moduł przechwytujący strony serwera oblicza następnie różnicę pomiędzy odpowiedzią i formą bazową serwera dla lokalizatora URL i zapamiętuje różnice danych. Moduł przechwytujący strony serwera uaktualnia formę bazową serwera z danymi odpowiedzi i archiwizuje wartość CRC poprzedniej formy bazowej i różnicę danych pomiędzy odpowiedzią i’starą formą bazową. Moduł przechwytujący strony serwera porównuje następnie wartość CRC formy bazowej klienta z wartością CRC formy bazowej serwera i dowolna zapamiętaną lub zarchiwizowaną wartością CRC dla określenia czy zaistniała zgodność. Jeżeli nie ma zgodności, odpowiedź jest po prostu wysyłana do modułu przechwytującego strony klienta.

Jeżeli istnieje zgodność to dane różnicowe odpowiadające zgodnym wartością CRC i kolejne dane różnicowe włączając w to bieżące dane różnicowe są przesyłane do modułu przechwytującego strony klienta. Moduł przechwytujący strony klienta dołącza dane różnicowe do formy bazowej klienta, dla odtworzenia odpowiedzi. Tak więc jeżeli istnieje zgodność wartości CRC z wartością CRC formy bazowej starszej o trzy generacje to trzy zestawy danych różnicowych powinny być wysłane do modułu przechwytującego strony klienta,

180 570 a rekonstrukcja odpowiedzi powinna być wykonana przez dołączenie trzech kolejnych zestawów danych różnicowych do formy bazowej klienta. Jeżeli jednakże liczba zestawów danych różnicowych lub rozmiar zestawów danych różnicowych wymaganych to rekonstrukcja odpowiedzi jest tak duża, że przesłanie rzeczywistej odpowiedzi wymaga mniejszego transferu danych to sama odpowiedź może być przesłana przez moduł przechwytujący strony serwera. W każdym przypadku po rekonstrukcji lub odebraniu odpowiedzi moduł przechwytujący strony klienta powinien uaktualnić formę bazową klienta dla żądania lokalizatora URL z danymi odpowiedzi i uaktualnić wartość CRC z wartością CRC odpowiedzi. Ponieważ forma bazowa klienta jest uaktualniana za każdym razem, gdy jest odbierana odpowiedź dla określonego lokalizatora URL, element pośredniczący klienta opisany powyżej może być stosowany jako element pośredniczący dla formy bazowej klienta, eliminując przez to potrzebę oddzielnego elementu pośredniczącego form bazowych klienta, jeżeli stosuje się różnicowanie dla żądań nie będących w zgodzie z interfejsem CGI.

Dodatkowe oszczędności w transmisji mogą być uzyskane na bazie redundancji bezstanowego protokółu komunikacyjnego takiego jak HTTP. W takim protokole klient przesyła informacje o sobie do serwera za każdym razem, gdy inicjowana jest transmisja. Podobnie serwer podaje klientowi specjalne informacje o sobie, gdy inicjowana jest odpowiedź.

W alternatywnym przykładzie wykonania wynalazku, pierwszy komputer 5 przesyła do drugiego komputera 6 specjalne informacje komputerowe odpowiadające zdefiniowanym charakterystykom komputera. Drugi komputer 6 zapamiętuje te specjalne informacje komputerowe. Następnie pierwszy komputer 5 usuwa te specjalne informacje komputerowe z kolejnych transmisji pochodzących z przeglądarki przed transmisją przez zewnętrzne łącze komunikacyjne 35. Drugi komputer 6 odtwarza następnie oryginalne transmisje pochodzące z przeglądarki przez łączenie zapamiętanych specjalnych informacji komputerowych z kolejnymi transmisjami odbieranymi przez zewnętrzne łącze komunikacyjne 35, dla utworzenia strumienia danych HTTP.

Oprócz usunięcia specjalnych informacji komputerowych z transmisji pochodzących z przeglądarki te specjalne informacje komputerowe mogą być także usunięte z transmisji pochodzących z serwera. W takim przypadku drugi komputer 6 z fig. 2 dostarcza do pierwszego komputera 5 przez zewnętrzne łącze komunikacyjne 35 specjalne informacje komputerowe odpowiadające zdefiniowanym charakterystykom drugiego komputera 6. Pierwszy komputer 5 zapamiętuje te specjalne informacje dla uzyskania informacji nagłówkowych serwera w kolejnych transmisjach, drugi komputer 6 usuwa te specjalne informacje komputerowe z kolejnych transmisji pochodzących z serwera i przesyła pozostałą część transmisji pochodzącej z serwera przez zewnętrzne łącze komunikacyjne 35. Pierwszy komputer 5 odbiera transmisje przez zewnętrzne łącze komunikacyjne i odtwarza oryginalne transmisje pochodzące z serwera przez łączenie informacji nagłówkowych serwera ze strumieniem specjalnych danych klient/serwer odbieranym przez zewnętrzne łącze komunikacyjne, dla utworzenia strumienia danych HTTP. W obu przypadkach operacje usuwania specjalnych informacji komputerowych i zapamiętywania informacji dla tworzenia albo informacji nagłówkowych serwera, albo informacji nagłówkowych klienta są wykonywane przez moduł przechwytujący 30 strony klienta, albo przez moduł przechwytujący 40 strony serwera zależnie od tego, czy operacja jest wykonywana na pierwszym komputerze 5 czy na drugim komputerze 6.

W rozwiązaniu według wynalazku przeglądarka 10 może komunikować się z modułem przechwytującym 30 strony klienta wykorzystując Protokół Kontroli Transmisji/Protokół Internetowy (TCP/IP). Protokół TCP może także być używany do komunikacji pomiędzy modułem przechwytującym 30 strony klienta a modułem przechwytującym 40 strony serwera przez zewnętrzne łącze komunikacyjne 35. Na koniec, protokół TCP może być używany do komunikacji pomiędzy modułem przechwytującym 40 strony serwera, a serwerem 20. Chociaż protokół TCP może być używany do komunikacji pomiędzy różnymi składnikami tworzącymi system, protokół HTTP nie daje jednak najskuteczniejszych środków dla komunikacji przez zewnętrzne łącze komunikacyjne. Dla poprawy parametrów zewnętrznego łącza

180 570 komunikacyjnego 35, tworzy się gniazda wirtualne, które są używane w połączeniu pomiędzy przeglądarka, a modułem przechwytującym 30 strony klienta i pomiędzy modułem przechwytującym 40 strony serwera, a serwerem 20. Działanie tego gniazda wirtualnego będzie opisane w odniesieniu do figur 11 do 17.

Figura 11 przedstawia schemat blokowy jednego z możliwych wykonań wynalazku wykorzystującym koncepcje gniazda wirtualnego. Jak pokazano na fig. 11 pierwszy komputer 5 i drugi komputer 6 sąpołączone przez zewnętrzne łącze komunikacyjne 35. Przeglądarka 10 ma wiele rzeczywistych gniazd, które łączą przeglądarkę 10 z modułem przechwytującym 30 strony klienta. Jak pokazano na fig. 11 pierwsze rzeczywiste gniazdo jest oznaczone jako 65a na przeglądarce 10, a odpowiadającym gniazdem jest 65b na module przechwytującym 30 strony klienta. To pierwsze rzeczywiste gniazdo jest gniazdem połączenia TCP realizującego protokół TCP, przez które żądania przeglądarki 10 są dalej łączone z modułem przechwytującym 30 strony klienta.

Gdy przeglądarka 10 żąda nowego połączenia TCP komunikacja zachodzi przez realne gniazdo 65a, które jest odbierane przez realne gniazdo 65b. Moduł przechwytujący 30 strony klienta będzie następnie tworzył kolejne rzeczywiste gniazdo dla komunikacji z przeglądarką 10. Jak pokazano na fig. 11, wiele rzeczywistych gniazd jest tworzone na przeglądarce 10 odpowiadających realnym gniazdom tworzonym na module przechwytującym 30 strony klienta. Te realne gniazda są oznaczone jako 60a do 64a na przeglądarce i 60b do 64b na module przechwytującym 30 strony klienta. Te realne gniazda są elementami, przez które przeglądarka komunikuje się z modułem przechwytującym 30 strony klienta. Po utworzeniu realnych gniazd 60a do 64a i 60b do 64b transmisje przez te gniazda są multipleksowane na realne gniazdo 36a, które zapewnia dostęp modułu przechwytującego 30 strony klienta do zewnętrznego łącza komunikacyjnego 35. Rzeczywiste gniazda 36a i 36b są tworzone, gdy żądanie jest przesyłane przez rzeczywiste gniazdo 37a pierwszego komputera 5 do rzeczywistego gniazda 37b drugiego komputera 6. Po potwierdzeniu żądanego połączenia przez rzeczywiste gniazdo 37b tworzone są rzeczy wiste gniazda 36a i 36b. Gniazda 37a i 37b działają jak pierwsze rzeczywiste gniazda dla komunikacji między modułem przechwytującym strony klienta i modułem przejmującym strony serwera i mogą być wykorzystywane tylko dla ustanowienia połączenia pomiędzy dwoma modułami przedstawianymi przez gniazda 36a i 36b. Każde z tych rzeczywistych gniazd działa pod standardowymi protokołami TCP/IP. Gdy transmisje są odbierane przez drugi komputer 6 przez zewnętrzne łącze komunikacyjne 35 są one odbierane w rzeczywistym gnieździe 36b. Moduł przechwytujący 40 strony serwera demultipleksuje następnie transmisje odebrane na gnieździe 36b i dostarcza je na odpowiednie gniazdo dla transmisji do serwera 20. Tak więc, na przykład transmisje przez gniazdo 60a do gniazda 60b dla żądania informacji ze specjalnego lokalizatora URL będą multipleksowane na gniazdo 36a, odebrane na gnieździe 36b, demultipleksowane przez moduł przechwytujący 40 strony serwera i przesyłane z gniazda 60c do gniazda 60d na serwerze 20. Podobnie transmisje pojawiające się na gnieździe 61a są odbierane przez gniazdo 61b multipleksowane przez moduł przechwytujący 30 strony klienta i przesyłane z gniazda 36a do gniazda 36b, gdzie moduł przechwytujący 40 strony serwera demultipleksuje transmisję i przesyła ją z gniazda 61c do gniazda 61 d. Tak transmisje przez gniazda 60a i 60b, 61a i 61b, 62a i 62b, 63a i 63b oraz 64a i 64b są przesyłane przez odpowiednie gniazda pomiędzy modułem przechwytującym 40 strony serwera a serwerem 20 przez gniazda 60c i 60d, 61 c i 6Id, 62c i 62d, 63c i 63d i 64c oraz 64d.

W podobny sposób odpowiedzi na żądanie z przeglądarki 10 przez serwer 20 są także przesyłane przez gniazda połączone z serwerem 20 do modułu przechwytującego 40 strony serwera i przez zewnętrzne łącze komunikacyjne 35 do modułu przechwytującego 30 strony klienta, a następnie do przeglądarki 10. Tak więc na przykład odpowiedź pochodząca z serwera 20 może być przesłana przez gniazdo 60d do gniazda 60c i multipleksowana przez moduł przechwytujący 40 strony serwera do gniazda 36b, skąd jest przesyłana przez zewnętrzne łącze komunikacyjne 35 do gniazda 36a. Moduł przechwytujący 30 strony klienta następnie

180 570 demultipleksuje transmisję i podaje ją do gniazda 60b dla przesłania do gniazda 60a na przeglądarce 10. Podobna linia komunikacyjna jest ustalana dla każdego gniazda używanego przez przeglądarkę 10 lub serwer 20. Rozwiązanie według wynalazku zostało opisane w odniesieniu do czterech połączeń między gniazdami pomiędzy przeglądarką 10 i serwerem 20, przy czym dla zapewnienia komunikacji pomiędzy przeglądarką 10 i serwerem 20 może być otwarta dowolna liczba gniazd.

Figura 12 przedstawia schemat blokowy systemu gniazda wirtualnego w module przechwytującym 30 strony klienta i w module przechwytującym 40 strony serwera. Zewnętrzne do tych modułów rzeczywiste gniazda pomiędzy modułem przechwytującym 30 strony klienta i przeglądarką 10 oraz modułem przechwytującym 40 strony serwera i serwerem 20 funkcjonują jako normalne gniazda TCP/IP. Tak więc użycie gniazd wirtualnych jest przezroczyste dla przeglądarki 10 i serwera 20.

Szczegółowy opis rozwiązania będzie przedstawiony w odniesieniu do schematu blokowego z fig. 12 i sieci działań z figur 13 do 17. Fig. 13 przedstawia sieć działań dla zarządzającego gniazdami oznaczonymi jako blok 68 na fig. 12. Na fig. 13 blok 300 przedstawia tworzenie rzeczywistego zarządzającego gniazdami 68 modułu przechwytującego 30 strony klienta. Po utworzeniu rzeczywistego zarządzającego gniazdami 68, tworzy on pierwsze rzeczywiste gniazdo pokazane jako gniazdo 65b na fig. 12. Tworzenie tego pierwszego rzeczywistego gniazda pokazane jest jako blok 300 na fig. 13. Po utworzeniu pierwszego rzeczywistego gniazda 65b zarządzający gniazdami 68 umieszczony w module przechwytującym 30 strony klienta nazywany także zarządzającym gniazdami klienta, czeka na zdarzenie na pierwszym rzeczywistym gnieździe 65b, jak pokazano w bloku 102 na fig. 13. Gdy zdarzenie jest odebrane na pierwszym rzeczywistym gnieździe 65b rzeczywisty zarządzający gniazdami 68 bada zdarzenie i w oparciu o to badanie przyjmuje jedną z pięciu ścieżek wychodzących w bloku 305 na fig. 13.

Jeżeli rzeczywiste gniazdo jest utworzone w odpowiedzi na żądanie komunikacyjne odebrane na pierwszym rzeczywistym gnieździe 65b, to jak pokazano na ścieżce z bloku 305 do bloku 306 z fig. 13, rzeczywisty zarządzający gniazdami 68 dodaje rzeczywiste gniazdo do rzeczywistej listy zdarzeń i tworzy następnie simpleksowe wirtualne gniazdo jak pokazano w bloku 307. W przypadku modułu przechwytującego strony klienta rzeczywisty zarządzający gniazdami inicjuje funkcję aplikacyjną, która realizuje funkcję modułu przechwytującego strony klienta dla utworzonego gniazda wirtualnego, jak pokazano w bloku 308 z fig. 13.

Stosowany tutaj termin gniazdo simpleksowe lub wirtualne gniazdo simpleksowe odnosi się do gniazda, które łączy się bezpośrednio albo z jednym gniazdem, albo z jedną aplikacją. Stosowany tutaj termin gniazdo multipleksowe odnosi się do gniazda, które łączy się z wieloma innymi gniazdami. Tak więc gniazdo multipleksowe realizuje funkcje multipleksowania lub demultipleksowania, a gniazdo simpleksowe wykonuje połączenie jeden na jeden. Tak więc, na przykład wykonując funkcję z bloków 306 do 308 z fig. 13 zarządzający gniazdami 68 powinien, w odpowiedzi na pierwsze żądanie odebrane przez pierwsze rzeczywiste gniazdo 65b, utworzyć rzeczywiste gniazdo 60b, wirtualne gniazdo simpleksowe 70 i zainicjować funkcję przejmującą strony klienta w aplikacji 80. Podobnie, dla kolejnych zdarzeń gdzie tworzone jest gniazdo rzeczywiste, rzeczywisty zarządzający gniazdami 68 powinien utworzyć rzeczywiste gniazda 6Ib, 62b, 63b lub 64b i wirtualne gniazda simpleksowe 71, 72, 73, lub 74 i zainicjować funkcje CSI odpowiadającą utworzonym rzeczywistym i wirtualnym gniazdom oznaczonym jako bloki 81, 82, 83, lub 84 na fig. 12.

Działanie funkcji przejmującej strony klienta będzie opisane w odniesieniu do rzeczywistego gniazda 60b, wirtualnego gniazda simpleksowego 70 i funkcji przejmującej strony klienta 80, przedstawionych na fig. 12. Blok 325 z fig. 14 przedstawia tworzenie funkcji przejmującej strony klienta 80. Po utworzeniu, funkcja przejmująca strony klienta 80 oczekuje na zdarzenie na wirtualnym gnieździe simpleksowym 70, jak pokazano w bloku 326. Ta operacja oczekiwania jest wykonywana przez realizację wirtualnej funkcji wybierania opisanej na fig. 16-4. Po potwierdzeniu zdarzenia, jest ono badane, jak pokazano w bloku 330.

180 570

Jeżeli zdarzeniem jest zamknięcie gniazda wirtualnego, to funkcja przejmująca strony klienta 80 usuwa gniazdo simpleksowe 70 jak pokazano w bloku 349 i kończy działanie jak pokazano w bloku 350 z fig. 14.

Jeżeli zdarzeniem jest potwierdzenie danych, to przyjmowana jest ścieżka z bloku 330 do bloku 331, a funkcja przejmująca strony klienta 80 odbiera transmisję pochodzącą z przeglądarki z wirtualnego gniazda simpleksowego 70, przez wykonanie wirtualnej operacji odebrania opisanej tutaj w odniesieniu do fig. 16-3. Funkcja przejmująca strony klienta wykonuje następnie opisane powyżej działania modułu przechwytującego strony klienta (patrz na przykład fig. 3 i 7), które są pokazane w bloku 332. Funkcja przechwytująca strony klienta 80 tworzy następnie wirtualne gniazdo multipleksowe 90, dołączone do rzeczywistego gniazda 36a w module przechwytującym 30 strony klienta. Rzeczywiste gniazdo 36a jest dołączone do rzeczywistego gniazda 36b w module przechwytującym 40 strony serwera. Tworzenie wirtualnego gniazda multipleksowego jest przedstawione w bloku 333 fig. 14 i wykonane przez realizację wirtualnie utworzonej operacji opisanej tutaj w odniesieniu do fig. 16-1. Blok 334 przedstawia wysyłanie informacji otrzymanej z przeglądarki przez rzeczywiste gniazdo 60b i wirtualne gniazdo simpleksowe 70 po utworzeniu funkcji przechwytującej strony klienta 80 dla transmisji przeglądarki. Ta transmisja oczekuje w kolejce do wirtualnego gniazda multipleksowego 90 wykonując wirtualną operację wysyłania opisaną w odniesieniu do fig. 16-2. Funkcja przechwytująca strony klienta 80 po kolejkowaniu żądania do wirtualnego gniazda multipleksowego 90 usuwa dane kolejkowane w wirtualnym gnieździe multipleksowym 90, jak pokazano w bloku 335 z fig. 14, a następnie oczekuje na zdarzenie na wirtualnym gnieździe multipleksowym, jak pokazano w bloku 336. Wirtualna funkcja jest realizowana przez wykonanie wirtualnej operacji usuwania opisanej w odniesieniu do fig. 17-1, która pobiera dane z kolejki do wirtualnego gniazda multipleksowego i dostarcza dane do rzeczywistego gniazda 36a. Operacja oczekiwania może być wykonana przez realizację wirtualnej funkcji wybierania opisanej na fig. 16-4. W tym punkcie moduł przechwytujący strony klienta przejmuje transmisję pochodzącą z przeglądarki i przesyła transmisję do modułu przechwytującego strony serwera przez zewnętrzne łącze komunikacyjne 35.

Figura 13 przedstawia sieć działań zarządzającego gniazdami albo w module przechwytującym 40 strony serwera, albo w module przechwytującym 30 strony klienta. Rzeczywisty zarządzający gniazdami w module przejmującym strony serwera lub zarządzający gniazdami serwera, pokazany jako blok 69 na fig. 12 wykonuje te same funkcje co zarządzający gniazdami klienta pokazany jako blok 68. Tworząc pierwsze rzeczywiste gniazdo, jak pokazano w bloku-301 w module przechwytującym 30 strony klienta tworzy dobrze znany port 37b dla odbierania żądań dla gniazd od modułu przechwytującego 30 strony klienta związanych z modułem przechwytującym 40 strony serwera. Gdy zachodzi rzeczywiste zdarzenie na gnieździe 36b, w module przechwytującym 40 strony serwera, jest ono badane w bloku 305. W tym przypadku zdarzeniem jest potwierdzenie danych z rzeczywistego gniazda 36a, więc przyjmowana jest ścieżka z bloku 305 do bloku 320 na fig. 13. Dane odebrane na rzeczywistym gnieździe 36b są badane i w przypadku, gdy dane są transmisją pochodzącą z przeglądarki przesyłaną przez moduł przechwytujący 30 strony klienta, musi być utworzone nowe gniazdo wirtualne w module przechwytującym 40 strony serwera. Przyjmowana jest wiec ścieżka z bloku 320 do bloku 321 fig. 13. Zarządzający gniazdami serwera 69 wykonuje następnie operacje pokazane w bloku 321, w bloku 322, w bloku 323 i w bloku 324 z fig. 13. Zarządzający gniazdami serwera 69 tworzy wirtualne gniazdo multipleksowe 95, jak pokazano w bloku 321, anuluje zegar działania gniazda multipleksowego, jak pokazano w bloku 322 i inicjuje aplikację funkcji przechwytującej strony serwera, jak pokazano w bloku 323 fig. 13 i bloku 85 fig. 12. Dane odebrane na rzeczywistym gnieździe 36b, są następnie kolejkowane do wirtualnego gniazda multipleksowego 95 i sygnalizowane jest zdarzenie wirtualne.

Tworzenie funkcji przejmującej strony serwera, jak pokazano w bloku 323, jest pokazane jako .blok 360 na fig. 15.

Po utworzeniu funkcji przechwytującej strony serwera 85, funkcja otrzymuje dane z wirtualnego gniazda multipleksowego 95, które były wysłane z modułu przechwytującego

180 570 strony klienta i odpowiadają transmisji pochodzącej z przeglądarki. Ta operacja jest pokazana jako blok 361 z fig. 15. Po odebraniu danych z modułu przechwytującego 30 strony klienta, funkcja przechwytująca strony serwera 85, przetwarza dane, jak opisano powyżej dla modułu przechwytującego 40 strony serwera. Wykonanie działań strony serwera, jest pokazane w bloku 362 (patrz na przykład fig. 5 i 9). Po przetworzeniu informacji funkcja przechwytująca strony serwera, tworzy wirtualne gniazdo simpleksowe 75, wykonując tworzenie witrualne, co jest przedstawione w odniesieniu do fig. 16-1. Ta operacja jest pokazana jako blok 363 z fig. 15. Funkcja przechwytująca strony serwera 85 wysyła następnie transmisję pochodzącą z przeglądarki wirtualnego gniazda simpleksowego 75, jak pokazano w bloku 364, przez wykonanie wirtualnego wysłania, co jest opisane w odniesieniu do fig. 16-2. Funkcja przechwytująca strony serwera 85 wykonuje następnie wirtualne skasowanie usuniętych danych kolejkowanych w wirtualnym gnieździe simpleksowym 75 do rzeczywistego gniazda 60c i czeka na wydarzenie w wirtualnym gnieździe simpleksowym 75. Wirtualna operacja usunięcia jest opisana w odniesieniu do fig. 17-1. Operacje wysłania i usunięcia są pokazane w blokach 364 i 365 z fig. 15. Operacja oczekiwania może być realizowana przez wykonanie wirtualnej funkcji wyboru opisanej na fig. 16-4. Gdy funkcja przechwytująca strony serwera 85 tworzy wirtualne gniazdo simpleksowe 75, tworzone jest także odpowiednie gniazdo rzeczywiste 60c. Przez wysłanie transmisji pochodzącej z przeglądarki do wirtualnego gniazda simpleksowego 75 funkcja przechwytująca strony serwera 85 przesyła transmisję pochodzącą z przeglądarki do serwera.

Gdy moduł przechwytujący 40 strony serwera odbiera odpowiedź z serwera na rzeczywistym gnieździe 60c, zachodzi zdarzenie rzeczywiste i zarządzający gniazdami serwera 69 opuszcza blok 302 z fig. 13 i bada zdarzenie, które zachodzi na rzeczywistym gnieździe 60c, jak pokazano w bloku 305. W danym przypadku będą to dane dla istniejącego gniazda wirtualnego i będzie przyjęta ścieżka z bloku 320 na fig. 13 do bloku 324. Dane odebrane na rzeczywistym gnieździe 60c są kolejkowane do wirtualnego gniazda 75 i zdarzenie wirtualne jest sygnalizowane. Gdy jest sygnalizowane zdarzenie wirtualne funkcja przechwytująca strony serwera 85 opuszcza blok 366 z fig. 15 i bada zdarzenie, jak pokazano w bloku 370. Jeżeli zdarzeniem jest gniazdo zamknięte, to wystąpił błąd i błędny komunikat jest tworzony jako odpowiedź, jak pokazano w bloku 375 z fig. 15. Jednakże, jeżeli zdarzeniem jest potwierdzenie danych, to będzie przyjęta ścieżka z bloku 370 do bloku 371 i funkcja przechwytująca strony serwera 85 wykonuje wirtualny odbiór, jak opisano w odniesieniu do fig. 16-3, dla uzyskania odpowiedzi serwera z wirtualnego gniazda simpleksowego 75, jak pokazano w bloku 371. Funkcja przechwytująca strony serwera 85 wykonuje następnie wirtualne zamkniecie wirtualnego gniazda simpleksowego 75, jak pokazano w bloku 372 i opisano w odniesieniu do fig. 17-2 i przetwarza odpowiedź, jak opisano powyżej dla modułu przechwytującego strony serwera i pokazano w bloku 373 (patrz na przykład fig. 6 i 10).

Czy ścieżką wyjściową z bloku 370 z fig. 15 jest ścieżka błędu do bloku 375 czy ścieżka danych do bloku 371, w bloku 374 wirtualne gniazdo simpleksowe 75 jest usuwane. Funkcja przechwytująca strony serwera 85 wykonuje następnie wirtualną operację wysyłania do wirtualnego gniazda multipleksowego 95, dla przesłania transmisji pochodzącej z serwera do modułu przechwytującego 30 strony klienta, jak pokazano w bloku 376. Funkcja przechwytująca strony serwera 85 wykonuje następnie wirtualną operację usuwania, dla usunięcia danych kolejkowanych w wirtualnym gnieździe 95. Te operacje są pokazane w bloku 377. Funkcja przechwytująca strony serwera 85 wykonuje następnie wirtualną operację zamykania dla zamknięcia wirtualnego gniazda multipleksowego 95, jak pokazano w bloku 378 z fig. 15. Na koniec funkcja przechwytująca strony serwera 85 usuwa wirtualne gniazdo i kończy zadanie jak pokazano w blokach 379 i 380.

Funkcja przechwytująca strony serwera 85 wykonuje wirtualne operacje wysłania i usunięcia do wirtualnego gniazda multipleksowego 95. Te zdarzenia wyzwalające dzieją się na rzeczywistym gnieździe 36a a zarządzający gniazdami klienta 68 opuszcza blok 302 i bada zdarzenie jak pokazano w bloku 305, ponieważ dane są odbierane na rzeczywistym gnieździe

180 570

36a, przyjmowana jest ścieżka z bloku 305 do bloku 320 z fig. 13 i dane są kolejkowane do wirtualnego gniazda multipleksowego 90. Dlatego, gdy rzeczywiste gniazdo 36a odbiera odpowiedź serwera z rzeczywistego gniazda 36b poprzez zewnętrzne łącze komunikacyjne 35, ta informacja jest demultipleksowana i podawana na odpowiednie gniazdo wirtualne. Potwierdzenie danych powoduje powstanie zdarzenia wirtualnego, jak pokazano w bloku 324 fig. 13 i blok 336 fig. 14 powinien zostać opuszczony, a funkcja przechwytująca strony klienta 80 powinna zbadać zdarzenie jak pokazano w bloku 340 fig. 14.

Jeżeli zdarzeniem jest odpowiedź gniazdo zamknięte, to obierana jest ścieżka z bloku 340 do bloku 345 fig. 14 i funkcja przechwytująca strony klienta 80 tworzy komunikat błędu jako odpowiedź i przechodzi do bloku 344 z fig. 14. Jeżeli wydarzeniem jest odebranie danych, to obierana jest ścieżka z bloku 340 do bloku 341 fig. 14 i funkcja przechwytująca strony klienta 80 wykonuje wirtualną operację odebrania dla odebrania odpowiedzi z wirtualnego gniazda multipleksowego 90. Ta operacja odbioru jest przedstawiona w bloku 341 fig. 14. Po odebraniu danych z wirtualnego gniazda multipleksowego 90 funkcja przechwytująca strony klienta 80 wykonuje wirtualną operację zamknięcia wirtualnego gniazda multipleksowego 90, jak pokazano w bloku 342. Funkcja przechwytująca strony klienta 80 przetwarza następnie odpowiedź, jak opisano powyżej dla modułu przechwytującego 30 strony klienta, jak pokazano w bloku 343 (patrz na przykład fig. 4 i 8). Operacje bloku 344 są następnie wykonywane niezależnie od tego, którą ścieżką wykonano wyjście z bloku 340. Funkcja przechwytująca strony klienta 80 kasuje wirtualne gniazdo multipleksowe, jak pokazano w bloku 344 i następnie wykonuje wirtualną operację przesyłania, dla przesłania odpowiedzi do przeglądarki przez wirtualne gniazdo simpleksowe 70, jak pokazano w bloku 346. Gdy operacja przesyłania wirtualnego jest zakończona, funkcja przechwytująca strony klienta 80 wykonuje wirtualną operację usuwania dla usunięcia danych kolejkowanych w wirtualnym gnieździe simpleksowym, jak pokazano w bloku 347 do rzeczywistego gniazda 60b, a następnie wykonuje wirtualną operację zamykania, dla zamknięcia wirtualnego gniazda simpleksowego, jak pokazano w bloku 348. Po zamknięciu wirtualnego gniazda simpleksowego dla funkcji przechwytującej strony klienta 80, wirtualne gniazdo simpleksowe jest kasowane, a funkcja przechwytująca strony klienta kończy działanie, jak pokazano w blokach 349 i 350 z fig. 14.

Jest oczywiste, że wynalazek został opisany w odniesieniu do jednego szczególnego przypadku tworzenia gniazd wirtualnych simpleksowego i multipleksowego i funkcji przechwytujących strony klienta i serwera, to wiele takich funkcji może być tworzonych w jednym module przechwytującym strony klienta i strony serwera. Odpowiednio, moduł przechwytujący strony klienta i moduł przechwytujący strony serwera mogą utworzyć połączenie TCP/IP pomiędzy modułem przechwytującym 30 strony klienta i modułem przechwytującym 40 strony serwera, a następnie multipleksować na złączu wiele transmisji pochodzących z przeglądarki lub serwera, podczas utrzymywania połączenia TCP/IP.

Działanie funkcji zarządzającego gniazdami klienta i zarządzającego gniazdami serwera może być lepiej zrozumiane w odniesieniu do fig. 16-1 do 16-4 i fig. 17-1 i 17-2, które przedstawiają sieć działań operacji wykonywanych przez moduł przechwytujący strony klienta i moduł przechwytujący strony serwera, gdy wirtualnie tworzy, wirtualnie wysyła, wirtualnie odbiera, wirtualnie wybiera, wirtualnie usuwa, lub wirtualnie zamyka, operacje wykonywane jak pokazano w sieciach działań na fig. 14 i 15. Gdy wykonywana jest operacja tworzenia wirtualnego, jak pokazano w bloku 333 z fig. 14 i bloku 363 fig. 15, operacje rozpoczynające wykonywane są w bloku 400 z fig. 16- 1. Zarządzający gniazdami określa następnie, czy wymagane jest rzeczywiste gniazdo, jak pokazano w bloku 405. Jeżeli rzeczywiste gniazdo już istnieje, tak jak gdy tworzone, tworzy wirtualne gniazdo multipleksowe, które ma być dołączone do istniejących rzeczywistych gniazd, następnie gdy przyjęta jest ścieżka nie z bloku 405 i gniazdo wirtualne jest dołączone do gniazda rzeczywistego, jak pokazano w bloku 409. Jeżeli jednak rzeczywiste gniazdo jest wymagane, to przyjęta jest ścieżka tak z bloku 405. Jak pokazano w bloku 406, rzeczywiste gniazdo jest tworzone. Gniazdo rzeczywiste jest następnie dodawane do listy zdarzeń, jak pokazano w bloku 408, dla monitorowania,

180 570 jak pokazano w bloku 302 z fig. 13. Po utworzeniu rzeczywistego gniazda i wykonaniu połączeń, gniazdo wirtualne jest następnie dołączane do gniazda rzeczywistego, jak pokazano w bloku 409 i operacja tworzenia jest zakończona, jak pokazano w bloku 410.

Dla wykonania wirtualnej operacji wysyłania przedstawionej w blokach 334 i 346 z fig. 14 lub blokach 364, 376 , z fig. 15, rozpoczęcie operacji jest wykonywane w bloku 420 z fig. 16-2. Dane są dodawane do kolejki gniazda wirtualnego, jak pokazano w bloku 427 i gdy to jest wykonane, operacja wysyłania kończy się jak pokazano w bloku 428. .

Wirtualna operacja odbierania przedstawiona w blokach 331 i 341 z fig. 14 i blokach 361 i 371 z fig. 15 jest wykonywana i rozpoczyna się w bloku 430 z fig. 16-3. Jak pokazano w bloku 435, kolejka gniazda wirtualnego jest przyjęta do określenia, czy jakieś dane znajdują się w kolejce gniazda wirtualnego. Jeżeli dane znajdują się w kolejce gniazda wirtualnego, to przyjęta jest ścieżka tak z bloku 435 i dane są odsyłane do funkcji wywołującej operację odbierania, jak pokazano w bloku 436. Jeżeli nie ma danych w kolejce gniazda wirtualnego i gniazdo nie jest oznaczone jako zamykane, to przyjęta jest ścieżka nie z bloku decyzyjnego 440 i nic nie jest zwracane, jak pokazano w bloku 441. Jednakże, jeśli nie ma danych w kolejce, a gniazdo jest oznaczone jako zamykane, to przyjęta jest ścieżka tak z bloku 440 i gniazdo jest oznaczane jako zamknięte, jak pokazano w bloku 442 i odpowiedź zamkniętego gniazda jest zwracana do operacji żądającej odbioru, jak pokazano w bloku 443.

Wirtualna operacja wybierania wykonywana w blokach 326 i 336 z fig. 14 i bloku 366 z fig. 15, jest wykonywana przez realizację operacji rozpoczynających w bloku 445 z fig. 16-4. Jak widać w bloku 446, najpierw jest określane, czy dane lub wirtualna operacja zamykania oczekuje w wybranym gnieździe wirtualnym. Jeżeli nie ma danych lub wirtualne zamykanie oczekuje, to przyjęta jest ścieżka nie z bloku 446 i proces oczekuje na zdarzenie wirtualne na wybranym gnieździe wirtualnym, jak pokazano w bloku 447 i kończy się po odebraniu takiego zdarzenia, jak pokazano w bloku 448. Jeżeli dane lub wirtualne zamykanie oczekują na wybrane gniazdo wirtualne, a zdarzenie wirtualne już się pojawiło to przyjęta jest ścieżka tak z bloku 446 i proces się kończy, jak pokazano w bloku 448.

Wirtualna operacja usuwania przedstawiona w blokach 335 i 347 z fig. 14 i blokach 365 i 377 z fig. 15 jest wykonywana przez realizację operacji rozpoczynających się w bloku 450 z fig. 17-1. Gdy wezwana, wirtualna operacja usuwania ustala, czy są jakieś dane do usunięcia w kolejce gniazda wirtualnego, jak pokazano w bloku decyzyjnym 455. Jeżeli nie ma danych w kolejce gniazda wirtualnego, to operacja usuwania po prostu kończy się i wraca do funkcji wywołującej, jak pokazano na ścieżce nie z bloku 455. Jeżeli jednakże są dane w kolejce, to przyjęta jest ścieżka tak z bloku 455 i jest ustalane, czy kolejka gniazda wirtualnego jest do gniazda multipleksowego, jak pokazano w bloku 460. Jeżeli to jest gniazdo multipleksowe to nagłówek gniazda, który zawiera trzy bajty określające unikalny identyfikator dla gniazda i ilość danych w przekazie, jest dodawany do rzeczywistego bufora gniazda, jak pokazano w bloku 461. W każdym razie, jeżeli to jest gniazdo multipleksowe lub gniazdo simpleksowe, dane dla rzeczywistego gniazda są następnie przenoszone do rzeczywistego bufora gniazda, jak pokazano w bloku 462. Jeżeli bufor gniazda rzeczywistego jest pełny, to przyjęta jest ścieżka tak z bloku 465 i dane rzeczywistego bufora gniazda są przesłane do gniazda rzeczywistego, jak pokazano w bloku 466. Jeżeli rzeczywisty bufor nie jest pełny, to przyjęta jest ścieżka tak z bloku 465. Wirtualna funkcja usuwania bada następnie, czy nie ma innych danych w kolejce wirtualnego gniazda multipleksowego. Jeżeli odpowiedź jest pozytywna, to przyjęta jest ścieżka tak z bloku 470 i dane rzeczywistego bufora gniazda są przesłane, aż wirtualna operacja usuwania jest ponownie wezwana dla opróżnienia jednej lub innych kolejek gniazda wirtualnego. Jeżeli nie ma innych danych, lub po dodaniu danych z innych wirtualnych gniazd multipleksowych, operacja z bloku 466 jest wykonywana i dane z rzeczywistego bufora gniazda są przesłane do gniazda rzeczywistego. Po przesłaniu wszystkich danych, dane z kolejki wirtualnego gniazda odpowiadające funkcji, która wezwała wirtualną operację usuwania, są przesłane do gniazda rzeczywistego, jak pokazano w bloku 467.

Wirtualna operacja zamykania przedstawiona w blokach 342 i 348 z fig. 14 i blokach 372 i 378 z fig. 15 jest wykonywana przez realizację operacji rozpoczynających się w bloku

180 570

480 z fig. 17-2. Gdy wezwana, wirtualna operacja zamknięcia ustala, czy zamknięcie wirtualne ma dotyczyć wirtualnego gniazda multipleksowego, jak pokazano w bloku 485. Jeżeli to jest wirtualne gniazdo multipleksowe, to przyjęta jest ścieżka tak z bloku 485 i wskaźnik operacji zamknij jest dodany do kolejki gniazda wirtualnego. Czy zamkniecie wirtualne ma dotyczyć wirtualnego gniazda multipleksowego, czy nie, wirtualna operacja zamknięcia wzywa wirtualną operację usuwania, jak pokazano w bloku 487, a następnie odłącza od gniazda rzeczywistego, jak pokazano w bloku 488. Operacja następnie bada, czy zamkniecie wirtualne ma dotyczyć wirtualnego gniazda simpleksowego, jak pokazano w bloku 490, a jeśli nie, to przyjęta jest ścieżka nie do bloku 495. Ponieważ zamykanie dotyczy wirtualnego gniazda multipleksowego, blok 495 bada, czy to jest ostatnie wirtualne gniazdo multipleksowe, jeśli to jest ostatnie wirtualne gniazdo multipleksowe, ustawia zegar aktywności multipleksowej, jak pokazano w bloku 496, jeśli to nie jest ostatnie wirtualne gniazdo multipleksowe, to blok 496 jest pominięty.

Wracając do bloku 490, jeżeli zamknięcie wirtualne dotyczy wirtualnego gniazda simpleksowego, to odpowiednie gniazdo rzeczywiste jest usuwane z listy zdarzeń, jak pokazano w bloku 491 i gniazdo rzeczywiste jest zamykane i kasowane, jak pokazano w bloku 492. Czy gniazdo jest, wirtualnym gniazdem simpleksowym, czy multipleksowym, jest oznaczane jako zamknięte w bloku 497 i operacja zamykania kończy się w bloku 498.

Będzie teraz opisana fig. 13 w jej związku z -fig. 16- 1 do 16-4 i fig. 17-1 i 17-2. Gdy zachodzi zdarzenie rzeczywiste blok 302 z fig. 13 jest opuszczany i zarządzający gniazdami bada zdarzenie bazując na tym, jak zdarzenie powstało. Jeżeli zdarzeniem jest taktowanie nie pochodzące z zegara aktywności gniazda multipleksowego, który był ustawiony w bloku 496 z fig. 17-2, to obierana jest ścieżka z bloku 305 do bloku 312 z fig 13. Jak pokazano na fig. 13 operacje z bloków 312 i 313 są wykony wane przez zarządzającego gniazdami, polegające na zamknięciu multipleksowego gniazda rzeczywistego i skasowaniu multipleksowego gniazda rzeczywistego odpowiadającego gniazdu łączącemu moduł przechwytujący strony klienta z modułem przechwytującym strony serwera. Zarządzający gniazdami czeka następnie na kolejne zdarzenie rzeczywiste. Ten multipleksowy zegar zdarzeń jest ponownie nastawiany przez utworzenie multipleksowego gniazda wirtualnego, jak pokazano w bloku 322.

Jeżeli zdarzeniem zachodzącym w gnieździe rzeczywistym jest zamkniecie gniazda rzeczywistego, tak jak serwer wykonujący operacje zamykania na połączeniach gniazdowych pomiędzy serwerem a modułem przechwytującym strony serwera to obierana jest ścieżka z bloku 305 do bloku 309 na fig. 13. Zarządzający gniazdami usuwa gniazdo rzeczywiste z listy zdarzeń rzeczywistych, jak pokazano w bloku 309 i odłącza gniazdo wirtualne lub, w przypadku gniazd multipleksowych, gniazda od rzeczywistego gniazda lub gniazd, jak pokazano w bloku 310. Zarządzający gniazdami oznacza następnie gniazdo wirtualne jako zamykane i sygnalizuje zdarzenie wirtualne Ta operacja jest przedstawiona w bloku 311 i gdy wszystkie dane będą usunięte z kolejki gniazda wirtualnego, gniazdo wirtualne będzie zamknięte. Po oznaczeniu gniazda wirtualnego jako zamykane, zarządzający gniazdami określa następnie czy gniazdo rzeczywiste, które ma być zamknięte, jest czy nie jest gniazdem simpleksowym, jak pokazano w bloku decyzyjnym 315. Jeżeli gniazdem rzeczywistym, które ma być zamknięte jest gniazdo simpleksowe, to rzeczywiste gniazdo simpleksowe jest zamykane i kasowane, jak pokazano w bloku 316. Zarządzający gniazdami oczekuje następnie na kolejne zdarzenie rzeczywiste, jak pokazano w bloku 302.

Jeżeli to nie rzeczywiste gniazdo simpleksowe ma być zamknięte, to przyjęta jest ścieżka nie z bloku 315 i zarządzający gniazdami oczekuje na następne zdarzenie rzeczywiste. Tak wiec rzeczywiste gniazdo multipleksowe lub gniazdo dołączone do modułu przechwytującego strony klienta i do modułu przechwytującego strony serwera może być zamknięte tylko przez czas oczekiwania zegara aktywności gniazda multipleksowego, to pozwala na utrzymanie połączenia pomiędzy modułem przechwytującym strony klienta i modułem przechwytującym strony serwera tak że gdy ostatnia transmisja między modułami pojawi się po czasie określonym uprzednio przez użytkownika. W przypadku żądania kolejnego połączenia przez przeglądarkę przed odliczeniem czasu zegara aktywności gniazda multipleksowego,

180 570 transmisja może być wykonana bez ponownego wykonywania połączenia pomiędzy modułem przechwytującym strony klienta i modułem przechwytującym strony serwera i to eliminuje potrzebę nadmiaru zasobów, dla ponownego ustanowienia takiego połączenia.

Ostatnia ścieżka z fig. 13, jaka będzie opisana dotyczy stanu, gdy pojawia się rzeczywiste zdarzenie i zdarzeniem jest potwierdzenie danych na rzeczywistym gnieździe multipleksowym lub gniazdach 36a lub 36b na fig. 12. Gdy dane są odebrane na rzeczywistym gnieździe multipleksowym, te dane są badane i w przypadku, gdy zawierają wskaźnik operacji zamknięcia, taki jak ten dodawany do kolejki wirtualnej w bloku 486 z fig. 17-2, to wykonywana jest wirtualna operacja zamknięcia i przyjmowana jest ścieżka z bloku 320 do bloku 310. Zarządzający gniazdami odłącza od rzeczywistego gniazda wirtualne gniazdo multipleksowe oznaczone w danych odebranych w gnieździe rzeczywistym, jak pokazano w bloku 310, następnie oznacza gniazdo wirtualne jako zamykane i sygnalizuje zdarzenie wirtualne, jak pokazano w bloku 311. Ponieważ zamykane jest wirtualne gniazdo multipleksowe przyjmowana jest ścieżka nie z bloku 315, a zarządzający gniazdami czeka na następne zdarzenie rzeczywiste, jak pokazano w bloku 302.

Przez wykonywanie operacji opisanych na fig. 13 do 17, ustanawia się trwałe połączenie pomiędzy pierwszym komputerem i drugim komputerem przez zewnętrzne łącze komunikacyjne: Trwałe połączenie jest utrzymywane aż wszystkie transmisje przychodzące z przeglądarki będą zakończone i wiele transmisji przychodzących z przeglądarki jest przejętych i multipleksowanych na zewnętrzne łącze komunikacyjne, podczas gdy trwałe połączenie jest utrzymywane. Specjalny strumień danych klient/serwer może być następnie demultipleksowany dla utworzenia wielu strumieni danych HTTP i wiele strumieni danych HTTP jest dostarczanych do serwera. Trwałe połączenie jest także utrzymywane aż wszystkie transmisje przychodzące z serwera będą zakończone. Wiele transmisji przychodzących z serwera jest przejętych i multipleksowanych na zewnętrzne łącze komunikacyjne, podczas gdy trwałe połączenie jest utrzymywane. Ponadto specjalny strumień danych klient/serwer może być demultipleksowany dla utworzenia wielu strumieni danych HTTP i wiele strumieni danych HTTP jest dostarczanych do serwera.

180 570

FIG.1

STAN TECHNIKI )°______ TCP/IP _________

Przeglądarka WWW	15	Serwer WWW

FIG.2

-----------,__J I_______________I K \ '5 \

180 570

FIG.3

100

180 570

160

180 570

120

Odbierz żądanie od modułu przejmującego strony klienta (CSI) zawierające przedział kohorencji,CRC i dane HTTP

FIG.5

Prześlij żądanie HTTP do serwera

Prześlij „koherentną odpowiedź do CSI

Prześlij „strumień odpowiedzi do CSI zawierający CRC wejścia SSI, wiek wejścia SSI, i dane HTTP wejścia SSI

180 570

180 570

200

FIG .7

Odbierz żądanie HTTP z przeglądarki

Nie

Ustaw CRC dla wysłania do SSI jako zero

212

206

Wyślij żądanie HTTP do SSI

213

Wyślij żądanie CGI do SSI zawierające żądanie HTTP i CRC bazowego wejścia pośredniczącego klienta

180 570

260

Odbierz z SSI odpowiedź na żądanie CGI zawierające typ odpowiedzi i CRC formy bazowej serwera

265

266

Tak jest to odp. n zadanie CGI

267

Nie Puść odpowiedź HTTP do przeglądarki

Odbierz odpowiedź i zapamiętaj dane HTTP, dane różnicowe CGI i CRC

Tak

275

270

Tak

277 i

276

Ni forma CRC zy klienta zgadza się z forma CRC serwera

Przebazuj bazową pamięć pośredniczącą * klienta przez zapamiętanie danych HTTP odebranych z SSI i CRC odetkanego z SSI stn. wejście ośredniczące klienta dla żądania CGI

Odtwórz odpowiedź HTTP z serwera WWW przez dołączenie danych różnicowych CGI do to rm) bazowej klienta danych HTTP dla utworzenia strumienia danych HTTP ł 27B

Wyślij Jako strumień danych HTTP, odtworzoną odpowiedź do przeglądarki

Nie

271

Utwórz bazowe wejście podręczne klienta przez zapamiętanie URL żądania CGI,CRC danych HTTP z SSI i danych HTTP

180 570

FIG. 9

220

Odbierz żądanie CGI z CSI zawierające CRC bazowego wejścia pośredniczącego klienta i dane HTTP żądania _υ 221

Wyślij żądanieCGI do serwera WWW

FIG.10

230

FIG. 10A FIG?

10B

Odbierz odpowiedź z serwera i zapamiętaj dane HTTP, CRC danych HTTP i zerowe dane różnicowe CGI

FIG.10A

180 570

FIG.10B

252

Wyślij odpowiedź do CSI CRC bazowego wejścia pośredniczą* cego SSI,danych HTTPi danych różnicowych CGI

180 570

FIG.11

I---------------------------i

180 570

FIG.12

180 570

180 570

Fig. 13 B

180 570

180 570

180 570

FIG. 16-1

400

420

427

Oodaj dane do kolejki gniazda wirtualnego

428

180 570

FIG.16-3 FIG.16-4

430

Zaznacz gniazdo „Zamknięte

443

445 '-------------------------Wybieraj] > /

Powrót

Zamknięte';

_________________z_____Λ

180 570

NIE

450

455 sa dane w kolejce

TAK

460

461 (jest gniazdo multipleksów

NIEl .

TAK Przesuń nagłówek >11!^ gniazda do rzeczywistego bufora

462

Przesuń dane gniazda wirtualnego do rzeczy- < wistego bufora ^/</465 Rzeczywisty^, bufor jest pełny^

NIE

470

TAK

466 ^/sąjakieś > dane w innych \kolejkachy ^x 7 /

TAK

Wyślij dane rzeczy- N|£ wistego bufora ---*

467

Fig.17-1

180 570

Departament Wydawnictw UP RP. Nakład 70 egz. Cena 6,00 zł.

Claims (10)

1. Zastrzeżenia patentowe

   1. Sposób komunikacji w systemie klient/serwer zawierającym pierwszą aplikację w pierwszym komputerze, która komunikuje się z drugą aplikacją w drugim komputerze, odległym od pierwszego komputera, przy czym pierwsza i druga aplikacje używają niezależnego protokołu komunikacyjnego klient/serwer do komunikacji między klientem a serwerem, zaś na zewnętrznym łączu telekomunikacyjnym występuje co najmniej jeden segment komunikatu między pierwszą aplikacją w pierwszym komputerze, a drugą aplikacją w drugim komputerze, znamienny tym, że przechwytuje się w niezależnym protokole komunikacyjnym klient/serwer komunikat, inicjowany przez pierwszą aplikację przed przesłaniem komunikatu zewnętrznym łączem telekomunikacyjnym, dokonuje się konwersji komunikatu inicjowanego przez pierwszą aplikację na specyficzny protokół komunikacyjny klient/serwer i przesyła się, po konwersji, komunikat przez zewnętrzne łącze telekomunikacyjne w postaci specyficznego strumienia danych klient/serwer, po czym odbiera się komunikat transmitowany przez łącze zewnętrzne, dokonuje się konwersji komunikatu, odebranego przez zewnętrzne łącze telekomunikacyjne, ze specyficznego protokołu komunikacyjnego klient/serwer na niezależny protokół komunikacyjny klient/serwer, i dostarcza się komunikat inicjowany przez pierwszą aplikację do drugiej aplikacji w niezależnym protokole komunikacyjnym klient/serwer.
2. 2. Sposób według zastrz. 1, znamienny tym, że jako niezależny protokół komunikacji klient/serwer stosuje się hipertekstowy protokół transmisyjny (HTTP) zaś jako komunikat inicjowany przez pierwszy komputer stosuje się strumień danych HTTP.
3. 3. Sposób według zastrz. 2, znamienny tym, że gdy pierwszym komputerem jest klient odległy, to jako pierwszą aplikację stosuje się aplikację przeglądarki sieciowej, zaś gdy drugim komputerem jest serwer, to jako drugą aplikację stosuje się aplikację serwerową sieci.
4. 4. Sposób według zastrz. 2, znamienny tym, że gdy pierwszym komputerem jest serwer, to jako pierwszą aplikację stosuje się aplikację serwerową sieci, zaś gdy drugim komputerem jest klient odległy, to jako drugą aplikację stosuje się aplikację przeglądarki sieciowej.
5. 5. Sposób według zastrz. 3, znamienny tym, że gdy inicjowany przez przeglądarkę sieciową komunikat odpowiada na żądanie wspólnego interfejsu przejścia (CGI), to przepytuje się przechwycone żądanie interfejsu CGI dla określenia, czy istnieje pozycja podręcznej bazy klienta odpowiadająca przechwyconemu żądaniu interfejsu CGI i zapewniająca podstawowy format interfejsu CGI klienta, i przepytuje się przechwycone żądanie interfejsu CGI dla określenia, czy istnieje pozycja podręcznej bazy serwera odpowiadająca przechwyconemu żądaniu interfejsu CGI i zapewniająca podstawowy format interfejsu CGI serwera, po czym przechowuje się strumień danych HTTP odebranych z serwera sieciowego w odpowiedzi na inicjowany przez przeglądarkę sieciową komunikat, który jest skierowanym do interfejsu CGI żądaniem rezydentnej pamięci podręcznej rezydującej w drugim komputerze, dotyczącym utworzenia pozycji podstawowej pamięci podręcznej serwera, przechowuje się strumień danych HTTP przeznaczony dla przeglądarki sieciowej w odpowiedzi na komunikat inicjowany przez przeglądarkę sieciową, który jest skierowanym do interfejsu CGI żądaniem rezydentnej pamięci podręcznej w pierwszym komputerze, dotyczącym utworzenia pozycji podstawowej pamięci podręcznej klienta, i przechwytuje się strumień danych HTTP odpowiadający inicjowanemu przez serwer sieciowy komunikatowi w odpowiedzi na przechwycone żądanie interfejsu CGI, przed przesłaniem strumienia danych HTTP do zewnętrznego łącza telekomunikacyjnego, po czym porównuje się przechwyconą odpowiedź interfejsu CGI z podstawowym formatem interfejsu CGI serwera, dla otrzymania danych różnicowych interfejsu CGI odpowiadających różnicy między przechwyconą odpowiedzią interfejsu CGI a podstawowym formatem interfejsu CGI serwera, wysyła się dane różnicowe interfejsu CGI do przeglądarki

   180 570 sieciowej w pierwszym komputerze przez zewnętrzne łącze telekomunikacyjne jako specyficzny strumień danych klient/serwer i zbiera się specyficzny strumień danych klient/serwer przesyłanych przez zewnętrzne łącze telekomunikacyjne, który był wysłany przez drugi komputer, przy czym w trakcie konwersji komunikatu odebranego odtwarza się strumień danych HTTP, odpowiadający komunikatowi od serwera sieciowego, ze specyficznego strumienia danych klient/serwer odebranego przez zewnętrzne łącze telekomunikacyjne poprzez połączenie podstawowego formatu interfejsu CGI klienta i danych różnicowych interfejsu CGI otrzymanych zewnętrznym łączem komunikacyjnym, przy utworzeniu strumienia danych HTTP odpowiadającego przechwyconej odpowiedzi interfejsu CGI, zaś w trakcie dostarczania komunikatu inicjowanego dostarcza się komunikat inicjowany przez serwer sieciowy do przeglądarki sieciowej jako strumień danych HTTP.
6. 6. Sposób według zastrz. 3, znamienny tym, że następnie zestawia się trwałe połączenie miedzy pierwszym komputerem a drugim komputerem przez zewnętrzne łącze telekomunikacyjne i utrzymuje się trwałe połączenie aż do zakończenia komunikacji zainicjowanej przez przeglądarkę sieciową, przy czym w trakcie przechwytywania komunikatu przechwytuje się wiele komunikatów inicjowanych przez przeglądarkę sieciową i zwielokrotnia się je na zewnętrznym łączu telekomunikacyjnym przy utrzymywaniu połączenia trwałego.
7. 7. Sposób według zastrz. 3, znamienny tym, że następnie dostarcza się do drugiego komputera, przez zewnętrzne łącze telekomunikacyjne, specyficzną informację komputerową odpowiadającą zadanym parametrom charakterystycznym pierwszego komputera, i przechowuje się specyficzną informację komputerową odpowiadającą zadanym parametrom charakterystycznym pierwszego komputera z wprowadzeniem informacji nagłówkowej przeglądarki, przy czym w trakcie konwersji komunikatu inicjowanego usuwa się specyficzną informację komputerową z komunikatu inicjowanego przez przeglądarkę sieciową, zaś w trakcie konwersji komunikatu odebranego łączy się informacje nagłówkową przeglądarki ze specyficznym strumieniem danych klient/serwer tworząc strumień danych HTTP.
8. 8. Sposób według zastrz. 3, znamienny tym, że następnie wychwytuje się strumień danych HTTP odpowiadający komunikatowi inicjowanemu przez serwer sieciowy przed przesłaniem strumienia danych HTTP zewnętrznym łączem telekomunikacyjnym, dokonuje się konwersji strumienia danych HTTP, inicjowanego przez serwer sieciowy, z protokołu HTTP na specyficzny protokół komunikacyjny klient/serwer, i przesyła się, po konwersji, inicjowany przez serwer sieciowy komunikat do przeglądarki sieciowej przez zewnętrzne łącze telekomunikacyjne w postaci specyficznego strumienia danych klient/serwer, po czym odbiera się specyficzny strumień danych klient/serwer przesyłany przez zewnętrzne łącze telekomunikacyjne oraz realizuje się odbudowę strumienia danych HTTP odpowiadającego komunikatowi od serwera sieciowego ze specyficznego strumienia danych klient/serwer, odebranego przez zewnętrzne łącze telekomunikacyjne poprzez konwersję specyficznego strumienia danych klient/serwer, odebranego w specyficznym protokole komunikacyjnym klient/serwer na strumień danych HTTP i dostarcza się komunikat inicjowany przez serwer sieciowy do przeglądarki sieciowej jako strumień danych HTTP.
9. 9. Urządzenie do komunikacji w systemie klient/serwer, w którym pierwsza aplikacja w jednym komputerze jest połączona poprzez łącze komunikacyjne z aplikacją w drugim komputerze, znamienne tym, że zawiera w pierwszym komputerze (5), włączony między pierwszą aplikację (10) a zewnętrzne łącze telekomunikacyjne (35), pierwszy moduł przechwytujący (30) do przechwytywania komunikatu w niezależnym protokole komunikacyjnym klient/serwer, inicjowanego przez pierwszą aplikację (10) przed przesłaniem komunikatu zewnętrznym łączem telekomunikacyjnym (35), konwersji inicjowanego komunikatu na specyficzny protokół komunikacyjny klient/serwer i przesyłania, po konwersji, komunikatu do drugiego komputera (6) zewnętrznym łączem telekomunikacyjnym (35) w postaci specyficznego strumienia danych klient/serwer, oraz w drugim komputerze (6), włączony między zewnętrzne łącze telekomunikacyjne (35) a drugą aplikację (20), drugi moduł przechwytujący (40) do odbierania komunikatów transmitowanych przez telekomunikacyjne łącze zewnętrzne (35), konwersji komunikatu ze specyficznego protokołu komunikacyjnego klient/serwer na

   180 570 niezależny protokół komunikacyjny klient/serwer i dostarczenia komunikatu po konwersji do drugiej aplikacji (20).
10. 10. Produkt programu komputerowego do komunikacji w systemie klient/serwer, który jest przechowywany na czytelnym dla komputera nośniku pamięciowym i zawiera wiele elementów z kodem oprogramowania do implementacji systemu po załadowaniu produktu do komputera, znamienny tym, że zawiera odczytywalne komputerowo elementy kodu programowego przechwytywania przez pierwszy komputer (5) komunikatu w niezależnym protokole komunikacyjnym klient/serwer, inicjowanego przez pierwszą aplikację (10), przed przesłaniem komunikatu zewnętrznym łączem telekomunikacyjnym (35), odczytywalne komputerowo elementy kodu programowego konwersji przez pierwszy komputer (5) komunikatu inicjowanego na specyficzny protokół komunikacyjny klient/serwer, odczytywalne komputerowo elementy kodu programowego przesłania, po konwersji, przez pierwszy komputer (5) komunikatu do drugiego komputera (6) przez zewnętrzne łącze telekomunikacyjne (35) w postaci specyficznego strumienia danych klient/serwer, odczytywalne komputerowo elementy odbierania przez drugi komputer (6) komunikatów przesyłanych przez zewnętrzne łącze telekomunikacyjne (35), odczytywalne komputerowo elementy konwersji przez drugi komputer (6) komunikatu ze specyficznego protokołu łączności komunikacyjnego klient/serwer na niezależny protokół komunikacyjny klient/serwer i odczytywalne komputerowo elementy dostarczania przez drugi komputer (6) komunikatu po konwersji do drugiej aplikacji (20).

    * * *