WO2004088953A1 - Procede et appareil pour l'acces aux donnees sur un reseau informatique - Google Patents

Procede et appareil pour l'acces aux donnees sur un reseau informatique Download PDF

Info

Publication number
WO2004088953A1
WO2004088953A1 PCT/GB2004/001329 GB2004001329W WO2004088953A1 WO 2004088953 A1 WO2004088953 A1 WO 2004088953A1 GB 2004001329 W GB2004001329 W GB 2004001329W WO 2004088953 A1 WO2004088953 A1 WO 2004088953A1
Authority
WO
WIPO (PCT)
Prior art keywords
resource
proxy
proxylet
server
http
Prior art date
Application number
PCT/GB2004/001329
Other languages
English (en)
Inventor
Steven Simpson
David Hutchison
Original Assignee
British Telecommunications Public Limited Company
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by British Telecommunications Public Limited Company filed Critical British Telecommunications Public Limited Company
Publication of WO2004088953A1 publication Critical patent/WO2004088953A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/30—Managing network names, e.g. use of aliases or nicknames
    • H04L61/301—Name conversion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/30—Managing network names, e.g. use of aliases or nicknames
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping

Definitions

  • the present invention relates to a method and apparatus for accessing data on a computer network.
  • it relates to a method of accessing a resource such as a document from a computer network by means of an identifier of the document, which identifier is independent of the current location of the document.
  • a Uniform Resource Locator is a well known example of a document identifier which specifies the location at which the document (or more generally the resource) is stored on the computer network.
  • Each URL expresses the name or address of a server which can provide the resource, the protocol used to talk to the server and a local reference to, identify the resource within the server. That is, a URL implies a mechanism and a location to obtain the corresponding resource.
  • a Uniform Resource Identifier (URI) is a more general term for a type of machine readable address and URLs can thus be said to be a subset of URIs.
  • RRC Request For Comments
  • IETF Internet Engineering Task Force
  • a URL adequately specifies a mechanism to obtain a resource from a computer network
  • resources may migrate. Webspace providers can withdraw from service, and website maintainers can choose an alternative host server. This may result in the URL of a resource changing, which then requires users to find out the new URL or else for a re- direction mechanism to be put in place.
  • resources may be replicated. Many important websites are often "mirrored" to reduce the load on servers, and to reduce response times to clients that are able to find the nearest mirror. However, this requires user interaction, and produces many distinct references to the same resource - which one should be given when identifying a resource?
  • Each URL may imply a location which may be convenient from one part of the network but inconvenient from another part.
  • conceptual collections of resources may be divided over several sites, causing the URL's of the component resources to vary arbitrarily, when it would be preferable to have a single schema for identifying the components regardless of their location or the necessary mechanism for communicating with the respective server to obtain the resource.
  • URN Uniform Resource Name
  • a URN is a persistent, location- independent resource identifier which identifies a resource, rather than explicitly locating it (or specifying what retrieval mechanism to use to retrieve it). This means that: i) a URN for a resource need never change and the resource can change location independently of the URN; ii) a resource identified by a single URN can exist at multiple locations simultaneously; iii) a collection of resources identified by a related class of URNs can be arbitrarily partitioned and spread over several physical locations.
  • URN resolution mechanism in order for a URN to be used to access a resource, some kind of URN resolution mechanism is required.
  • the IETF decided that exactly how this is done should not be prescribed so that many different methods could evolve to allow different types of URN to be resolved in different ways as appropriate. Nonetheless, the IETF have proposed a possible mechanism for resolving URNs which is set out in IETF's RFC's 2168 and 2169.
  • the proposed method involves the browser extracting parts of the URN and using them to form a query to the DNS system which, possibly after several look-ups in the DNS system, returns the location (essentially in the form of a URL) of one or more servers which can resolve the URN.
  • the browser should then contact the server offering the URN resolution service with the URN to be resolved and the contacted server will then perform the requested resolution (eg into one or more corresponding URL's).
  • the proposed resolution method requires new and specialised activities to be carried out at the client terminal. However, this requires each and every browser to be modified to permit such a resolution to occur.
  • the browser software will again need to be updated on each and every client device which wishes to take advantage of the increased functionality.
  • a method of accessing a resource stored on a server device from a client device comprising: transmitting from the client device to an intermediate device a naming identifier which identifies the resource without specifying an associated server device within the computer network; at said intermediate device, resolving the naming identifier into a corresponding at least one locating identifier which specifies the server device storing the resource; and requesting the server device specified by the locating identifier to transmit a copy of the resource to the client device.
  • the term intermediate device is used in a very broad sense to mean any device which is connected to the network other than the client device (the intermediate device may even be the server device on which the resource is stored) and thus includes specialised router devices and other server devices.
  • the intermediate device is itself a server device running an application which permits (typically small) programs to be dynamically loaded and run on the server device in response to a request from a remote device connected to the network; hereinafter, such an application shall be referred to as an Execution Environment for Proxylets (EEP) and the programs which are dynamically loaded and run shall be referred to as proxylets.
  • EEP Execution Environment for Proxylets
  • an EEP is provided as part of a programmable HTTP proxy which includes ports to which a proxylet can attach its own ports to form a mesh of interconnected HTTP-processing components (which includes proxylets). Some portion of the mesh traverses the EEP within the proxy, and components therein are dynamically loaded, and as a result this portion of the mesh may change over time. Dynamically loaded HTTP -processing components are proxylets. Such a programmable HTTP proxy is described in greater detail below. A discussion of the operation of an alternative EEP and example proxylets is given in co-pending UK patent application number 0226762.3 the contents of which are hereby incorporated herein by way of reference.
  • the programmable HTTP proxy which is described in greater detail below may include as part of a mesh HTTP-processing components which behave like proxylets (in that they have ports for receiving requests and transmitting responses, etc.) but which are not dynamically loadable.
  • any such component could be replaced by a dynamically loadable proxylet or vice versa, however in particular implementations it may be more convenient for a developer to simply perform certain more mundane housekeeping type functions with static components.
  • using dynamically loadable proxylets throughout has the advantage of enabling even mundane housekeeping functions to be enhanced dynamically by simply creating a newer updated proxylet to dynamically replace the old one without requiring downtime of the HTTP proxy.
  • the naming identifier is a URN and the intermediate device resolves the URN into one or more URLs.
  • the intermediate device may simply return the resulting URL(s) to the client device to permit the user (or possibly the browser application on behalf of the user without requiring user intervention - see the IETF's RFC's 2295 and 2296 for further details of how this might be implemented) to then initiate a request to the server (or any one of the servers) storing the desired resource requesting that the server transmit a copy of the resource to the client device.
  • the intermediate device automatically issues such a request to a corresponding server such that the client device automatically receives a copy of the resource without further interaction from the user.
  • the browser running on the ultimate client device preferably does not know the actual URL used to access the resource. This ensures that if a user bookmarks the resource or forwards it on to a third party, the URI used is the URN and not a corresponding URL. In the event that the URN is resolved into only a single URL, it is clearly trivial for the intermediate device to issue a request for the resource to the corresponding server.
  • the intermediate device preferably measures one or more metrics (such as, for example, the Round Trip Time) for each of the servers associated with the corresponding URLs and automatically issues a request to the server with the best measured score or scores (eg the shortest RTT) to transmit the resource to the intermediate device (which can then forward it on to the client device).
  • metrics such as, for example, the Round Trip Time
  • Figure 1 is a block diagram illustrating a computer network according to an embodiment of the present invention
  • Figure 2 is a signal diagram illustrating the signals passed between various components of the network of Figure 1 in carrying out a method embodying the present invention.
  • Figure 3 is a signal diagram illustrating the signals passed between various components of the network of Figure 1 in carrying out an alternative method embodying the present invention.
  • FIG. 1 is a block diagram of a computer network generally designated 10.
  • the network is shown to include a client device 100, an Internet Service Provider (ISP) facility 200, the Internet 300, a remote host server 400 and a proxylet repository server 500.
  • ISP Internet Service Provider
  • the ISP facility 200 there is a Local Area Network 210 a general server 220, a Domain Name Server (DNS) 230, and a programmable HTTP proxy server 240 and a router or gateway 250 connecting the ISP facility 200 to the Internet 300.
  • DNS Domain Name Server
  • FIG. 1 is a block diagram of a computer network generally designated 10.
  • the network is shown to include a client device 100, an Internet Service Provider (ISP) facility 200, the Internet 300, a remote host server 400 and a proxylet repository server 500.
  • ISP facility 200 there is a Local Area Network 210 a general server 220, a Domain Name Server (DNS) 230, and a programmable HTTP proxy server 240 and a router or gateway 250
  • URI Uniform Resource Identifier
  • the URI may be either a Uniform Resource Name (URN) or a Uniform Resource Locator (URL)).
  • the web browser generates a standard "GET" request based on the entered URI (in the case that the user enters a URN, the browser in this embodiment behaves in the same way as it does for the case that the user enters a URL (ie the browser "assumes" that the entered URN is in fact a URL - many common browsers currently available will not in fact do this and instead will generate an error - however, it is straightforward to modify a browser to have the enhanced functionality required for this purpose and having made this modification, no further modifications will be required to deal with new URN resolution proxylets which may be developed after modification of the browser software).
  • HTTP proxy server 240 located at the ISP facility 200 which is acting as a first-pass HTTP proxy server whose specialist functions are described below (note that it is common procedure for the browser of a client to communicate with a proxy rather than attempting to determine the IP address of the server corresponding to each URL input via the DNS system and then setting up a direct connection with the corresponding server itself, instead it directly communicates only with the proxy which is then responsible for determining the IP address of the corresponding server and setting up the direct connection, etc.).
  • An HTTP proxy acts as an HTTP server to browsers and other proxies (which are downstream of the proxy), and as a client to servers and other proxies (which are upstream).
  • a downstream entity normally must be somehow configured in order to make use of a proxy - most browsers have a configuration option to which the proxy's address is given, or accept a proxy configuration script which can determine the address more dynamically.
  • a browser can send its HTTP requests to the proxy.
  • the proxy may forward them on to a server that can provide the requested resource (and so it will also forward the responses from the server to the client), or forward them on to another proxy (and forward the corresponding responses back), or provide a response itself. It could also modify requests and responses that it forwards. This means that, provided that a browser will send resource requests through the proxy, the proxy can provide additional content-delivery services (such as caching) without any further extensions to the browser.
  • the programmable HTTP proxy server 240 includes, in the present embodiment, a URN identification component which, in the present embodiment, is a proxylet and examines incoming HTTP requests from the client device 100 and reacts in one of the following ways: i) if the request includes a URL, the URN identification component causes the programmable HTTP proxy server 240 to simply forward the request on to server 220 which is hosting a more conventional HTTP proxy (which provides caching services) which processes the request in a conventional manner (eg by contacting DNS server 230 if necessary to obtain the IP address of the server associated with the URL contained in the request and eventually obtaining and forwarding back to the URN identification proxylet a suitable response (eg a 200 OK response including the requested resource) which is then passed back to the client device 100); or ii) if the request includes a URN, the URN identification component passes the request for processing by a generic URN resolving component (which is a proxylet in the present embodiment) which is up-stream of the URN identification component.
  • the generic URN resolving component is so-called because it is not namespace-specific but rather it is namespace-independent. However, it may (and almost certainly will in practice) in turn call further, more specialised, namespace-specific URN-resolving components to complete the resolution of the URN (the generic URN resolving component loads such components into the EEP and hence are proxylets; the way in which proxylets are instantiated within the execution environment provided by the programmable HTTP proxy application of the present embodiment is discussed in greater detail below); having resolved the URN to identify an appropriate corresponding URL, in the present embodiment, a namespace-specific URN resolving proxylet retrieves the corresponding resource (or enough information to obtain it) and forwards it directly to the client device 100.
  • the present embodiment thus provides an HTTP proxy which forwards most requests onto other proxies and servers unchanged, but intercepts requests for URNs, and provides its own responses to them.
  • the proxy provides a Java environment in which it can execute Java subroutines called proxylets. Proxylets can be loaded in and executed while the proxy is running, so its capabilities can be augmented dynamically.
  • a proxylet acts as a miniature proxy - it accepts requests which the proxy has decided to supply, and provides corresponding responses. To achieve this, it can act as a client, talking to upstream entities, which may be other proxylets in the same (or even in another) proxy, or other proxies and servers which the proxy is configured to use.
  • a proxylet can also load other proxylets into its environment.
  • a generic URN-resolving proxylet also forms part of the present embodiment, and is placed in the proxy somehow (e.g. by the administrator of the proxy), so that it receives requests for URNs. It also maintains references to a set of namespace-specific proxylets which it has installed and placed upstream of itself, to which it can delegate certain interactions. This set is initially empty, but may grow or shrink over time. Each of these proxylets is associated with a URN NID, is expected to be able to generate a useful response to any request for URNs in that namespace, and has been downloaded from an address which can be derived from the NID according to some configured rule.
  • the generic URN-resolving proxylet When the generic URN-resolving proxylet receives a request for a URN (which should therefore be of the form urn: ⁇ nid>: ⁇ nss> as defined in IETF's RFC 2141, it extracts ⁇ nid>, and looks for an installed proxylet associated with ⁇ nid>. If present, it can immediately delegate the request to that proxylet, which is expected to provide a useful response because of its nid association. If such a proxylet is not present, the generic proxylet passes the nid through the configured rule to obtain the address of the proxylet, and attempts to download and install it in the set. If this fails, the generic proxylet may respond with an error, or delegate the request to some other configured upstream entity. If the installation succeeds, the generic proxylet can delegate to the new namespace-specific proxylet as before. The namespace-specific proxylet may make use of ⁇ nss> to complete the interaction.
  • the generic proxylet or the proxy may employ some policies to determine when to reinstall currently-loaded proxylets, in order to ensure that the latest resolvers are available.
  • FIG. 2 illustrates an example case of resolving a URN to obtain a copy of a resource located on Host server 400 (a so-called URN to Resource or N2R service).
  • the client device 100 sends a GET URN message 600 to the programmable HTTP proxy server 240.
  • the URN refers to an IETF RFC, a copy of which document is stored on the host server 400.
  • the URN identification proxylet determines that the GET request references a URN rather than a URL and thus passes the GET request to the generic URN resolving proxylet.
  • the generic URN resolving proxylet identifies the URN as being in respect of an IETF document and thus goes about loading in an appropriate proxylet for resolving that type of URN (in this case an IETF URN resolving proxylet). It does this by sending a GET "proxylet" HTTP request 605 to the proxylet repository server 500.
  • the proxylet repository server 500 has a copy of the requested proxylet and thus sends a "200 OK" HTTP response 610 which includes the requested proxylet (note in fact in the present embodiment, this request and response interaction may go through another proxy - eg the "normal" proxy server 220 - depending on the location of the proxylet repository server relative to the programmable proxy server and the way in which the programmable proxy has been configured. Also note that in the present implementation, this is done using the networking facilities provided in the Java programming language within thejava.net package including the well-known classes and interfaces such as URL, URLConnection and URLClassLoader, etc.).
  • the received proxylet When the requested IETF URN resolving proxylet is received at the programmable HTTP proxy server 240, the received proxylet is instantiated (and retained for future use) and the original GET URN request is passed to it for processing. The URN is then resolved, in the present example, into a single URL.
  • the IETF URN resolving proxylet then proceeds to send a GET "URL" HTTP request 615 to the host server 400 (again possibly via one or more additional proxies such as proxy 220).
  • the host server 400 Upon receipt of the GET "URL" HTTP request 615 at the host server 400, the host server 400 behaves in a conventional manner to retrieve the requested resource and sends it along with a "200 OK" HTTP response 620 back to the EEP server 240.
  • This type of method can be useful where there are a number of mirror sites and the user (or, in a preferred embodiment, the browser) wishes to select the best site from which to obtain the resource according to some predetermined metrics such as round trip time, etc., and is termed a URN to URLs or N2Ls service.
  • the client device sends a GET "URN" HTTP request 650 to the programmable HTTP proxy server 240.
  • This request is then passed to the URN identifying proxylet which determines that the request refers to a URN (as opposed to a URL) and therefore passes it to the generic URN resolving proxylet.
  • the generic URN resolving proxylet identifies the URN as being in respect of (for example) an ISSN document and thus goes about loading in an appropriate proxylet for resolving that type of URN (in this case an ISSN URN resolving proxylet). It does this by sending a GET "proxylet" HTTP request 655 to the proxylet repository server 500.
  • the proxylet repository server 500 has a copy of the requested proxylet and thus sends a "200 OK" HTTP response 660 which includes the requested proxylet (note that in the present implementation, this is done using the networking facilities provided in the Java programming language within the java.net package including the well-known classes and interfaces such as URL, URLConnection and URLClassLoader, etc.). If the generic URN resolving proxylet has recently loaded the ISSN URN resolving proxylet, it will probably be retained in the programmable HTTP proxy server and messages 655 and 660 are redundant and processing instead jumps immediately to the following stages (as indicated by arrow 665).
  • the original GET "URN" request is passed to it for resolution.
  • the resolution only proceeds as far as to obtain the corresponding one (or more) URLs which are then passed back (from the ISSN URN specific resolving proxylet via the generic URN resolving proxylet) to the client device 100 in a suitable "3XX HTTP redirection response" 670 (eg a "302 FOUND" redirection response where only a single URL is returned).
  • a single corresponding URL is obtained and sent to the client device 100.
  • the browser determines that only a single URL has been passed back and thus automatically sends out a "GET URL" HTTP request 675.
  • This passes to the programmable HTTP proxy server 240 which determines that the request relates to a URL and thus simply forwards the request on to a conventional HTTP proxy (located in the present embodiment in server 220) as another GET "URL" HTTP request 680.
  • the conventional HTTP proxy running on server 220 then processes the request and returns the desired resource back (via a "200 OK" HTTP response 685) to the URN identifying proxylet running on programmable HTTP proxy server 240, which in turn forwards the document on to the client device 100 via another "200 OK" HTTP response 690.
  • server 220 is also taken to have recently cached the requested document so that no additional messages need to be sent to the host server 400 containing the original version of the document. Since this method returns one or more corresponding URL's to the client device rather than the resource itself, this method is referred to as a URN to URL's service (N2Ls).
  • N2Ls URN to URL's service
  • namespace-specific proxylets In the present embodiment, four namespaces have been implemented as namespace- specific proxylets.
  • IETF namespace which identifies RFCs and Internet Drafts
  • an alternative IETF URN specific proxylet contains the addresses of several sites that hold RFCs and Internet Drafts, and downloads the requested document (as identified by the nss) from one of these sites, and provides it as the response. It will also try other sites if its initial choice is not forthcoming, and keeps track of response times to each site to help to choose one for future requests.
  • the proxylet wraps a configured prefix and suffix around the nss, to form a new URI. It then responds with a 302 redirection to instruct the browser to request the resource identified by that URI instead.
  • the proxylet forms part of an application-level overlay network which is assumed to have been established.
  • the participants of this overlay exchange information about mapping certain nss strings to URIs, and the metrics used to determine the overlay topology should favour mappings which produce URIs which are more favourable to the location of the namespace-specific resolver (e.g. the bandwidth between the proxy and the servers of those URIs is greater).
  • the proxy (which is assumed to be using HTTP version 1.1 or higher) returns a "300 MULTIPLE CHOICES" HTTP response including all of the obtained URLs.
  • the proxy prior to sending the 300 response first measures the Round Trip Time (RTT) to each server associated with the different URLs and includes this information with the response.
  • RTT Round Trip Time
  • the proxylet can first perform a RTT measurement of the different possible servers and then automatically contact the closest server, etc.
  • the functionality of the programmable HTTP proxy is deliberately somewhat limited and a conventional proxy is relied upon for providing conventional proxy services (eg caching) in respect of normal URLs.
  • a single proxy instead of having a separate programmable HTTP proxy and a conventional proxy, a single proxy can be used which performs both functions.
  • the functionality of the programmable HTTP proxy server 240 is provided by a programmable environment which at any moment consists of zero or more proxylet instances whose ports may be interconnected to form a mesh.
  • downstream is used to mean “towards the user agent” (ie towards the client device 100)
  • upstream is used to mean “towards the origin server” (eg host server 400).
  • DFP Downstream Facing Port
  • UFP Upstream Facing Port
  • UFP Upstream Facing Port
  • each proxylet instance has one or more DFP's through which HTTP requests may enter the proxylet instance, and corresponding responses leave.
  • the proxylet identifies its DFP numerically, ie O-(n-l), if there are n DFP's.
  • Each proxylet instance has zero or more UFP's, through which the proxylet instance may direct HTTP requests, and receive corresponding responses.
  • the proxylet may thus communicate either with other, upstream, proxylets or with other items connected to the network.
  • the proxylet may identify its UFPs by any arbitrary configuration.
  • the programming environment itself provides at least one UFP (the environment UFP(s)) to connect to one or more proxylet instances' DFPs, and drive HTTP interactions through the environment.
  • UFP the environment UFP(s)
  • proxylet instances' DFPs the programming environment
  • HTTP interactions through the environment.
  • a mesh When a mesh is configured, it must be provided with a subset of these, each identified to that particular mesh numerically from zero. Each mesh may be configured with a different subset if the proxy provides some other selection mechanism, eg. user identification by proxy authentication.
  • the execution environment additionally provides one or more DFPs (the environment DFPs) for connecting to some proxylet instances' UFPs and to service HTTP interactions forwarded through or generated by the environment.
  • DFPs the environment DFPs
  • a mesh When a mesh is configured, it is provided with a subset of these, each identified to that particular mesh numerically from zero. Each mesh may be configured with a different subset if the proxy provides some other selection mechanism.
  • Downstream of an environment's UFP(s) and upstream of the environment's DFP's are hidden components to translate HTTP messages between byte stream and data structures.
  • a UFP and a DFP may be connected together directly to form an identity mesh.
  • HttpRequestlnput This expresses a read-only HTTP request, including request line, header, content and footer. Calls to obtain parts of this may block until those parts have been read in from the network. Conversely, some parts may be readable as soon as they are available, despite other parts not arriving.
  • HttpResponseOutput This expresses a write-only HTTP response. It is effectively a placeholder for a response to be provided later. The caller must provide each part and indicate that it is complete.
  • HttpReactor This interface represents a channel: its implementation is a DFP; the holder of a reference to one is effectively a UFP.
  • a reactor has a single method which takes an HttpRequestlnput and an HttpResponseOutput (ie instantiations of object classes which implement these interfaces respectively). These represent an HTTP interaction from the point of view of the server (or other upstream entity looking back in a downstream direction).
  • a very simple reactor configured with a reference to another reactor may simply pass both the request and the response (or rather, the place-holder for the response) on to the other reactor, reducing the need to copy between a chain of reactors when no modifications are taking place.
  • the URN identification proxylet which has one DFP which is connected to the environment UFP which is provided by the programmable HTTP proxy 220.
  • the URN identification proxylet has a first and a second UFP.
  • the generic URN resolution proxylet which has one DFP which is connected to the second UFP of the URN identification proxylet.
  • the generic URN resolution proxylet has a first and a second UFP.
  • the generic URN resolution proxylet has a UFP per specific URN resolution proxylet connected to that specific proxylet's DFP. It ensures that the first UFP of each specific proxylet is connected to the same DFP to which its own first UFP is connected . It ensures that the second UFP of each specific proxylet is connected to the same DFP to which its own second UFP is connected
  • the first UFPs of both the URN identification proxylet and the generic URN resolution proxylet are connected (possibly via one or more further proxylets to perform housekeeping tasks such as, for example, to perform typical browser type functions of downloading a configuration script - such as an ECMAscript or a Javascript - to be executed to control the onward routing of HTTP requests) to the environment DFP whereby HTTP requests can be transmitted away from the programmable HTTP proxy to other elements in the network, and whereby incoming HTTP responses from other elements in the network can be passed back to whichever proxylet issued the corresponding request.
  • housekeeping tasks such as, for example, to perform typical browser type functions of downloading a configuration script - such as an ECMAscript or a Javascript - to be executed to control the onward routing of HTTP requests

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Un serveur de procuration de protocole HTTP (240) retransmet la majorité des requêtes vers d'autres mandataires et serveurs sans modification, mais intercepte les requêtes (600) pour des noms de ressource uniforme (URN) en provenance d'un dispositif client (100), et leur fournit ses propres réponses (625). Le serveur de procuration (240) fournit un environnement de type Java dans lequel il peut exécuter des sous-routines de type Java désignées petites procurations. Des requêtes peuvent être faites pour des petites procurations (605) et chargées (610) à partir d'un serveur de référentiel de petites procurations (500) et exécutées pendant le fonctionnement du serveur de procuration (240), de sorte que ses capacités peuvent être augmentées de manière dynamique. Une petite procuration fonctionne comme une procuration miniature: elle accepte des requêtes que le serveur de procuration décide de fournir, et doit fournir des réponses correspondantes. A cet effet, elle peut agir comme un client, en dialogue, avec des messages de requête d'obtention de localisateur URL HTTP (615) et (200) des réponses OK HTTP (620), avec des entités en amont, qui peuvent être d'autres petites procurations dans le même (ou même dans un autre) serveur de procuration, ou d'autres mandataires et serveurs (400) que la configuration du serveur de procuration lui permet d'utiliser. Une petite procuration peut également charger d'autres petites procurations dans son environnement.
PCT/GB2004/001329 2003-03-31 2004-03-26 Procede et appareil pour l'acces aux donnees sur un reseau informatique WO2004088953A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GBGB0307408.5A GB0307408D0 (en) 2003-03-31 2003-03-31 A method and apparatus for accessing data on a computer network
GB0307408.5 2003-03-31

Publications (1)

Publication Number Publication Date
WO2004088953A1 true WO2004088953A1 (fr) 2004-10-14

Family

ID=9955890

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2004/001329 WO2004088953A1 (fr) 2003-03-31 2004-03-26 Procede et appareil pour l'acces aux donnees sur un reseau informatique

Country Status (2)

Country Link
GB (1) GB0307408D0 (fr)
WO (1) WO2004088953A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006053851A1 (fr) * 2004-11-18 2006-05-26 International Business Machines Corporation Procede et systeme permettant d'augmenter des identifiants uniformes de ressources (uri) au moyen d'informations supplementaires
WO2008152023A2 (fr) * 2007-06-11 2008-12-18 Giesecke & Devrient Gmbh Accès à une ressource par commutation par un module de sécurité
CN104836821A (zh) * 2014-02-10 2015-08-12 腾讯科技（深圳）有限公司 一种基于路由器设备的网络加速方法、装置和设备

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001013601A1 (fr) * 1999-08-18 2001-02-22 Elisa Communications Oyj Procede permettant de reduire au minimum les retards lies a des services de resolution de nom

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001013601A1 (fr) * 1999-08-18 2001-02-22 Elisa Communications Oyj Procede permettant de reduire au minimum les retards lies a des services de resolution de nom

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
BHATTACHARJEE S ET AL: "Application-layer anycasting", INFOCOM '97. SIXTEENTH ANNUAL JOINT CONFERENCE OF THE IEEE COMPUTER AND COMMUNICATIONS SOCIETIES. DRIVING THE INFORMATION REVOLUTION., PROCEEDINGS IEEE KOBE, JAPAN 7-11 APRIL 1997, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 7 April 1997 (1997-04-07), pages 1388 - 1396, XP010251961, ISBN: 0-8186-7780-5 *
GHOSH A ET AL: "An infrastructure for application level active networking", COMPUTER NETWORKS, ELSEVIER SCIENCE PUBLISHERS B.V., AMSTERDAM, NL, vol. 36, no. 1, June 2001 (2001-06-01), pages 5 - 20, XP004304881, ISSN: 1389-1286 *
PAUL E. HOFFMAN, RON DANIEL JR.: "URN Resolution Overview, draft-ietf-uri-urn-res-descrip-00", IETF URI WORKING GROUP, INTERNET DRAFT, 21 October 1995 (1995-10-21), pages 1 - 4, XP002287468, Retrieved from the Internet <URL:http://ftp.ics.uci.edu/pub/ietf/uri/draft-ietf-uri-urn-res-descript-00.txt> [retrieved on 20040607] *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006053851A1 (fr) * 2004-11-18 2006-05-26 International Business Machines Corporation Procede et systeme permettant d'augmenter des identifiants uniformes de ressources (uri) au moyen d'informations supplementaires
WO2008152023A2 (fr) * 2007-06-11 2008-12-18 Giesecke & Devrient Gmbh Accès à une ressource par commutation par un module de sécurité
WO2008152023A3 (fr) * 2007-06-11 2009-02-19 Giesecke & Devrient Gmbh Accès à une ressource par commutation par un module de sécurité
CN104836821A (zh) * 2014-02-10 2015-08-12 腾讯科技（深圳）有限公司 一种基于路由器设备的网络加速方法、装置和设备
WO2015117570A1 (fr) * 2014-02-10 2015-08-13 Tencent Technology (Shenzhen) Company Limited Procédé, appareil et dispositif d'accélération de réseau basés sur un dispositif de routeur
US10491657B2 (en) 2014-02-10 2019-11-26 Tencent Technology (Shenzhen) Company Limited Network acceleration method, apparatus and device based on router device

Also Published As

Publication number Publication date
GB0307408D0 (en) 2003-05-07

Similar Documents

Publication Publication Date Title
US11611607B2 (en) System providing faster and more efficient data communication
US20210021692A1 (en) Translation of resource identifiers using popularity information upon client request
US10547585B2 (en) Content delivery network (CDN) content server request handling mechanism with metadata framework support
US7333990B1 (en) Dynamic reverse proxy
EP1355475B1 (fr) Amélioration d&#39;une page Web avec nouvelles fonctionalités pour services sur le web
WO2004088953A1 (fr) Procede et appareil pour l&#39;acces aux donnees sur un reseau informatique
JP2002334012A (ja) サービス要求処理方法及びその実施システム並びにその処理プログラムと記録媒体
US20120327931A1 (en) Gateways integrating name-based networks with host-based networks
API Configuration Description, Deployment, and Lifecycle Management

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase