Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/04—Protocols for data compression, e.g. ROHC
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/50—Network services
  • H04L67/56—Provisioning of proxy services
  • H04L67/565—Conversion or adaptation of application format or content
  • H04L67/5651—Reducing the amount or size of exchanged application data
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/50—Network services
  • H04L67/56—Provisioning of proxy services
  • H04L67/563—Data redirection of data network streams
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/50—Network services
  • H04L67/56—Provisioning of proxy services
  • H04L67/565—Conversion or adaptation of application format or content
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
  • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
  • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
  • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

• the invention relates to on-the-fly data compression tools used on networks, and in particular on the Internet. These tools aim to optimize the flow or “bandwidth” and thus increase the speed of information display at the level of the Internet customer.
• these tools allow a reduction in the loading time of content, that is to say a better perception of the quality of service (QoS) and also a reduction in costs when the connection is billed by volume.
• QoS quality of service
• Booster Web which respond to this problem, but none correspond to a real offer at the heart of the network, which can be easily applied to different types of users.
• Boosters with clients require the installation of a specific module on the client's workstation. This local module on plug'in will actually modify the structure of the messages exchanged between the client and the booster. Communication using the usual HTTP (Hypertext Transport Protocol) protocol is replaced by a proprietary protocol.
• HTTP Hypertext Transport Protocol
• TCP boosters modify the structure of messages, others are content to modify the logic for resuming TCP sending by adapting it to the response time of the network such as mobile phones for example.
• Clientless boosters do not modify http port 80 messages, they use standard headers. But it is then essential to declare them in the properties of browsers as we would for a classic cache. In addition, some boosters also have a "cache" function and others claim to comply with the ICP protocol (communication protocol between caches). These solutions therefore require intervention on the software installed on the user's computer and are therefore far from being transparent to the user. It is proposed according to the invention to resolve this drawback, that is to say to propose a tool and a method of compressing data on the fly which is transparent to the Internet user, that is to say which does not require intervention on the computer or the local network thereof.
• This object is achieved according to the invention thanks to a method of on-the-fly compression of data supplied by a server of a collective network such as the Internet in response to a request from a consultation terminal, in which method a data compression module, and a redirection module provided for receiving data supplied by the server and redirecting them to the compression module, this redirection module also being provided for receiving data from the compression module and redirecting them towards the consultation terminal, method according to which an indication concerning an aptitude for decompression of the terminal is examined in the request and a compression is performed in the compression module, on the data requested by the request and supplied by the server, which is adapted to the indications of suitability contained in the request.
• a device for compressing data on the fly in a collective network such as the Internet comprising a compression module and a redirection module, this redirection module being designed to receive data supplied by a server in response to a consultation request sent by a consultation terminal, and redirect this data to the compression module, this redirection module also being intended to receive data supplied back by the compression module and redirect them to the terminal of consultation, this device further including means for examining, in a request for consultation of data sent by a terminal, an indication concerning a decompression ability of the terminal considered, and means for controlling compression by the compression module which is adapted to the indication of capacity for decompression contained in the request.
• FIG. 1 is a simplified diagram of a data compression assembly according to the invention
• FIG. 2 is another simplified diagram of an assembly according to the invention.
• FIG. 3 shows in detail this same assembly according to the invention
• FIG. 4 shows in detail an iCAP server according to a variant of the invention
• FIG. 5 is a flowchart representative of a method according to a variant of the invention.
• FIG. 6 is a flowchart of data and instructions according to a variant of the invention.
• the device described below uses a data exchange protocol intended to allow modifications of content on the Internet, a protocol called iCAP - Internet Content Adaptation Protocol -.
• the device of FIG. 1 is architecture around two modules 10 and 20 of the iCAP type, namely a cache 10 of the client iCAP type and a content modification server 20, of the iCAP server type to
• proxy cache 10 configured in the browser of the user 30 (but it could just as easily be a proxy proxy operating in transparent mode in the context of an ISP - Internet Service Provider -).
• the cache 10 then sends an HTTP request to an original web server 40, containing this page.
• the web server 40 returns the requested page to cache 10.
• Cache 10 now acting as an iCAP client redirects this response to the aforementioned iCAP server 20, passing it the full page.
• the iCAP server 20 then processes this request by calling on a content modification service integrated into the server, then responds to cache 10 by returning the result of the processing: the modified page (or not as will be seen below).
• the cache 10 returns the response from the iCAP server 10 to the end user 30 and also stores this response.
• the cache 10 of the “iCAP client” type is currently available on the market in an industrial version.
• iCAP offers two main modes (“Request Modification” and “Response Modification”) which are based on the HTTP protocol.
• iCAP The role of iCAP is not to perform the content transformation itself. It is just limited to connecting "iCAP clients” (web caches, routers, etc.) with “iCAP servers”, the latter being responsible for the transformation.
• the iCAP forum http://www.i-cap.org was created in December 1999 under the leadership of the companies Network Appliance and Akamai. Its objective is to standardize, through the iCAP protocol (Internet Content Adaptation, Protocol), the exchanges between equipment representative of Web architectures (Web servers, caches, load balancers, routers ...) and content transformation systems .
• the ICAP 1.25 specification is the most recent. It has already been the subject of several implementations in the context of value-added file transformation services, here are some examples:
• iCAP Internet-Draft "iCAP the internet content adaptation protocol” http: //www.ietf.orq/internet-drafts/draft-elson-opes-icap-00 .txt) in the Open Proxy Extensible Services Working Group.
• iCAP Internet-Draft
• Anti-virus software publishers benefiting from their expertise in network solutions installing on FireWall (curtain of fire) or proxies (proxy) offer a port of their services on iCAP. We are also seeing the appearance of new commercial players in the field of content filtering.
• the main steps of the compression service are as follows: a) the client 30 sends a request to a Web server 40. This request possibly passes through redirection equipment, here the cache 10. b) the server 40 transmits its response to client 30 via cache 10. c) the redirection service 10 (iCAP client) redirects the response to the iCAP server 20. This server will be referred to below by the more general expression “compression module 20” in order to qualify the main function of this server. d) the response from the server 40 is if possible compressed and / or optimized by the compression module 20. e) the compression module 20 returns the request to the redirection module 10. f) the redirection module 10 returns the response to the client 30. g) the client browser 30 automatically decompresses the document received before displaying it.
• This compression system (without a specific client or local module - or plug-in -) offers the advantage of not intervening on the software installed on the user's computer 30 (or on the mobile phone or any other consultation terminal used).
• This compression service also does not modify the network and protocol layers, which avoids possible incompatibilities with other types of services or equipment that would be located between the compression service and the end user.
• FIGS 3 and 4 show in more detail the preferred device described here.
• the compression module 20 (or iCAP content transformation module) is broken down into an administrator module 22, a flow adapter module 23, and a service module or sub-module 25 dedicated specifically to compression tasks. Datas.
• the function of the flow adapter 23 is to adapt the content between the redirection module (iCAP client 10) and the service module 25.
• Such a stream adapter 23 is preferably provided to adapt the data streams also for a series of other additional service modules, implementing services other than compression, these modules can for example be content filtering modules or anti-virus filtering modules.
• the adapter 23 is located in the compression module 20, on the one hand, in the client 10 - server 20 direction, adapt the files so that they can be directly used for the file transformation services, and on the other hand, in the server 20 - client 10 direction, ensure the integrity of the transformed file and possibly its reconstruction.
• the adapter 23 makes it possible to formalize the exchanges between the redirection module 10 (iCAP client) and the service module 25 (file transformation service) by adapting the iCAP streams to make them compatible with the compression service module. 25, as well as with other modules corresponding to file transformation services, without it being necessary to develop an iCAP layer at the level of these services. This then makes it possible to define file transformation services, modular, scalable and independent of the iCAP layers.
• the present compression set is therefore capable of dynamically taking into account the particularities of customers and thus of adapting compression on the fly.
• the browser 30 announces, in the header of this request, all the characteristics qualifying this browser.
• the compression module 20 (iCAP server) will then test the existence of an "Accept-encoding" line in the http request. If this line does not exist, this means that the browser 30 does not accept any compressed page. The compression module 20 must then return the pages without modifying them.
• the server 20 must look at the value of the types of compressed elements which are accepted by browsers to choose a good encoder or submodule of compression.
• the service module 25 modifies the content of the header to be returned to the client 30, compresses the data, and returns it to the browser 30 via the redirection module 10.
• the service module 25 specifically carrying out the compression of content, therefore operates here natively in “response modification” mode.
• the procedure described here is carried out using a compression module 20 conforming to the architecture shown in FIG. 4, but comprising several service modules 25 integrated in the same server iCAP 20, these different service modules 25 each corresponding to a compression of a different type of object.
• the objects passed are, more generally, objects corresponding to the various http headers relating to the client 10, to the server 20, and to the content supplied.
• the compression module 20 searches in the request-client header for the string "Accept Encoding", making it possible to know whether the content can be compressed. If the value is not equal to "gzip” or “deflate” or if the chain does not exist, no compression is performed (go to point I below).
• the compression module 20 searches in this same header for a string “User-Agent” making it possible to know the minimum version of browser used by the client. If the value extracted is not at least equal to 4 (major version number of browsers), no compression is performed (go to point I).
• This operation fulfills a referral module function.
• the stream is redirected to a compression sub-module 25 most suitable for the type of declared content.
• a “Content-Type: text.html” indication in the data returned by the server indicates that the content is of type HTML - Hypertext Markup Language - (text).
• the first bytes of the content are compared with the following bytes: it may be that a poor implementation of a Web server 40 introduces coding errors and it is then necessary to ensure that the content is indeed text. If the content is not of HTML type, it is not modified (passage to point I below).
• the class diagram in Figure 6 shows the generalization and dependency links between server classes and specific service classes.
• the complete class diagram of a preferred iCAP zipper is the logical fusion of this diagram with that of an iCAP flow adapter as described above.
• the CicapServiceZip class is the child class of the ClcapService iCAP service class. It contains the functionality used for compressing objects.
• the CicapGlobalsService class is the abstract child class of the class of definitions of constants and variables common to the service classes. It is not instantiable.
• the CIcapErrorService class defines specific error constants for the service. It is not instantiable.
• the compression mechanisms provided by the service described here may act differently depending on the content to be processed.
• This service finds an immediate application for any Internet connectivity from mobile terminals (a PC - personal computer - or a PDA - pocket digital assistant - via a GPRS terminal - General Packet Radio Service - or CSD - Circuit Switched Data).
• mobile terminals a PC - personal computer - or a PDA - pocket digital assistant - via a GPRS terminal - General Packet Radio Service - or CSD - Circuit Switched Data.
• ISP Internet service provider
• This service also finds its effectiveness in the connections of nomadic users with their corporate Intranet. Indeed, it is through connections of PSTN (Switched Telephone Network) that they recover data from the Intranet, and, as such, compression on the fly offers a gain in relative bandwidth and a reduction in download time for new information.
• PSTN Switchched Telephone Network
• the iCAP or iCAP Zipper compressor described here has the primary advantage of saving bandwidth and improving the quality of service offered.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computer Security & Cryptography (AREA)
• Information Transfer Between Computers (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=28052133

Family Applications (1)

Country Status (4)

Families Citing this family (1)

Family Cites Families (2)

• 2002
  • 2002-04-05 FR FR0204248A patent/FR2838268A1/fr active Pending
• 2003
  • 2003-04-04 WO PCT/FR2003/001074 patent/WO2003085927A1/fr not_active Application Discontinuation
  • 2003-04-04 EP EP03740571A patent/EP1495619A1/de not_active Withdrawn
  • 2003-04-04 AU AU2003260725A patent/AU2003260725A1/en not_active Abandoned

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events