EP1419455A1 - Procede et systeme permettant de fournir des informations a des fournisseurs de contenus concernant la maniere dont leurs utilisateurs accedent a l'internet - Google Patents

Procede et systeme permettant de fournir des informations a des fournisseurs de contenus concernant la maniere dont leurs utilisateurs accedent a l'internet

Info

Publication number
EP1419455A1
EP1419455A1 EP01964022A EP01964022A EP1419455A1 EP 1419455 A1 EP1419455 A1 EP 1419455A1 EP 01964022 A EP01964022 A EP 01964022A EP 01964022 A EP01964022 A EP 01964022A EP 1419455 A1 EP1419455 A1 EP 1419455A1
Authority
EP
European Patent Office
Prior art keywords
database
information
content provider
given
network
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP01964022A
Other languages
German (de)
English (en)
Other versions
EP1419455A4 (fr
Inventor
Rizwan S. Dhanidina
John Josef Kloninger
Kyle Rose
Ravi Sundaram
Yoav Yerushalmi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Akamai Technologies Inc
Original Assignee
Akamai Technologies Inc
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 Akamai Technologies Inc filed Critical Akamai Technologies Inc
Publication of EP1419455A1 publication Critical patent/EP1419455A1/fr
Publication of EP1419455A4 publication Critical patent/EP1419455A4/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/02Marketing; Price estimation or determination; Fundraising
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/953Querying, e.g. by the use of web search engines
    • G06F16/9537Spatial or temporal dependent retrieval, e.g. spatiotemporal queries
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/52Network services specially adapted for the location of the user terminal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/535Tracking the activity of the user
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the present invention relates generally to knowledge delivery systems that enable content providers to more intelligently serve content and control assets on their Web sites. Description of the Related Art
  • Information gathering generally falls into two categories: user-declared information and anonymous information gathering.
  • the former is the most effective way to learn about user preferences and demographics, but it is often burdened by signficant levels of inaccuracy due to false user information submission or an incomplete collection of profiles compared to the entire Internet population.
  • Anonymous information gathering is more comprehensive in that it can encomass the analysis of a great amount, if not all, of the Internet without being dependent upon user input.
  • IP Internet Protocol
  • CIDR Classless InterDomain Routing
  • CDNs Well-managed content delivery networks
  • a CDN has the ability to gather, verify and enhance information about how end users access the Internet.
  • the present invention provides an information access and retrieval method, system and/or managed service for accurately identifying, among other access attributes, the geographic location from which users access a Web site and the network origin of a user's request.
  • the invention is implemented as an information retrieval system within or as an adjunct to a content provider application platform (e.g., a Web server, an application server, or the like) to provide geo-approximation and bandwidth characterization with respect to a given end user access request.
  • a content provider application platform e.g., a Web server, an application server, or the like
  • the inventive functionality delivers given metrics, for example: an ISO standard two- letter country code of the request origin, a state or region code of countries, the network origin of a user's access, network type (e.g., dial-up, DSL, cable modem, etc.), and other metrics of interest including, without limitation, Designated Marketing Area (DMA), Metropolitan Statistical Area (MSA), Primary Metropolitan Statistical Area (PMSA), longitude, latitude, FIPS, time zone, and the like.
  • DMA Designated Marketing Area
  • MSA Metropolitan Statistical Area
  • PMSA Primary Metropolitan Statistical Area
  • longitude latitude
  • FIPS time zone
  • the invention is a managed service that combines a software client with connectivity to a content delivery network (or other third party source) for receiving a database associating IP CIDR blocks with given access metrics.
  • content providers implement the service by installing an application programming interface (API) and access "engine” directly onto a web or application server platform.
  • An instance of the database preferably is stored locally at the application server platform.
  • API application programming interface
  • a query is made through the API to the engine.
  • the query triggers a lookup in the database to associate the user's IP address to an appropriate metric, such as country code (and region code, etc.).
  • the country code and other network information output can then be used for custom content functionality based on what applications the provider is using.
  • the engine sets-up and maintains secure connectivity to one or more database update processes, which are preferably maintained and managed by a third party such as an Internet CDNSP. On a periodic basis, the engine downloads the latest mapping database from the CDN or other third party provider) to ensure that the data for the server is as up-to-date as possible.
  • a third party such as an Internet CDNSP.
  • FIG. 1 is a simplified block diagram of the components of the information delivery system of the present invention.
  • Figure 2 is a simplified diagram illustrating how an end user request is processed at a Web server that has been provisioned with the information delivery system of the present invention.
  • Figure 3 is a block diagram illustrating in more detail the components of the information delivery system of the present invention.
  • the information delivery system of the present invention preferably leverages off of end user access data compiled by an Internet content delivery network (ICDN).
  • ICDN Internet content delivery network
  • a conventional CDN is implemented as a combination of a content delivery infrastructure, a request-routing mechanism, and a distribution infrastructure.
  • the content delivery infrastructure usually comprises a set of "surrogate" origin servers that are located at strategic locations (e.g., Internet network access points, and the like) for delivering copies of content to requesting end users.
  • the request-routing mechanism allocates servers in the content delivery infrastructure to requesting clients in a way that, for web content delivery, minimizes a given client's response time and, for streaming media delivery, provides for the highest quality.
  • the distribution infrastructure consists of on-demand or push-based mechanisms that move content from the origin server to the surrogates.
  • a CDN service provider may organize sets of surrogate origin servers as a "region."
  • an ICDN region typically comprises a set of one or more content servers that share a common backend, e.g., a LAN, and that are located at or near an Internet access point.
  • a typical ICDN region may be colocated within an Internet Service Provider Point of Presence (PoP).
  • PoP Internet Service Provider Point of Presence
  • a representative ICDN content server is a Pentium-based caching appliance running an operating system (e.g., Linux, Windows NT, Windows 2000) and having suitable RAM and disk storage for ICDN applications and content delivery network content (e.g., HTTP content, streaming media and applications).
  • the ICDN typically also includes network agents that monitor the network as well as the server loads. These network agents are typically collocated at third party data centers. Map maker software receives data generated from the network agents and periodically creates maps that dynamically associate IP addresses (e.g., the IP addresses of client-side local name servers) with the ICDN regions.
  • Akamai FreeFlow In one type of service offering, known as Akamai FreeFlow, from Akamai Technologies, Inc.
  • requests for content that has been tagged for delivery from the ICDN are directed to the "best" region (using a map-driven DNS request routing mechanism) and to a content server within the region that is not overloaded and that is likely to host the requested content.
  • a well-managed ICDN constantly monitors and maps the Internet and the billions of IP addresses that connect all of the computers and users operating on the Web everyday.
  • the CDNSP has the ability to gather, verify and enhance information about how end users access the Internet.
  • the CDNSP populates and constantly updates a database that contains geo-location and other end user access information.
  • the database associates IP-to-geo-location data for the entire public Internet, or for any given portion thereof.
  • IP address data in the database may be collected from various sources, e.g., CDN name server lookup entries, network provider data, sample IP address to geography resolutions generated from testing, public registration data including domain registries (e.g., APNIC, ARIN, RIPE databases), commercial third party information sources, and the like.
  • the database stores data about groups of IP addresses, although this is not a limitation.
  • the database groupings associate user IP addresses and network information with CIDR blocks.
  • the techniques for data assembly, compilation, and updating are outside the scope of the present invention. It is assumed, however, that the database is available to the information delivery system and is continually updated on a periodic basis (e.g., every few hours, every few days, or the like).
  • the invention provides an information delivery system for access and retrieval of such database information by a content provider.
  • the delivery system of the invention may be implemented in whole or in part by a third party service provider (e.g., by the CDNSP) as a "managed" service offering or it may be implemented as a standalone
  • the database stores information associating IP address blocks with given geo- and network data including, without limitation, one or more of the following attributes: country code, region (e.g., state (e.g., US/non-AOL only) or province (e.g.,
  • IP address space is represented in the database, and at least country code information is always associated with a valid IP address. If an IP address is in reserved IP space, preferably every attribute has a return value of "reserved.” Preferably, all other elements in the database, including region code, are optional and may or may not be associated with an IP address.
  • the information delivery system 100 of the present invention preferably includes three (3) primary components: an application programming interface (API), an engine (sometimes called a Facilitator), and a database update process or daemon.
  • API application programming interface
  • engine sometimes called a Facilitator
  • database update process or daemon a database update process or daemon.
  • each content provider uses an API and an engine, and a given engine can establish and maintain connections to one or more database update processes.
  • One or more update processes can maintain communications with multiple engines, including engines from different content providers.
  • the database may be deemed to be part of the information delivery system or simply an adjunct thereto.
  • the API 102 and engine 1,04 components of the information delivery system 100 are implemented within the execution environment of a content provider platform 108, such as a server.
  • Platform 108 is assumed to be a system, machine, application, program or execution thread of a given application that has the capability of using geo- and/or network data obtained from an instance 106 of the database, which is conveniently hosted in a cache 110 or other suitable storage of the application platform 108.
  • Representative platforms include Web servers, application servers, database servers, legacy systems, and the like.
  • the given application can be any functionality that can leverage individual user access as described in more detail below.
  • the API is code that is integrated into the application and is used to make queries to the engine.
  • the engine is responsible for responding to requests from the API and, in response thereto, retrieving the requested geo-data from the database and returning it to the API for delivery back to and use by the requesting application.
  • the engine also operates as a daemon or system agent (i.e., a background task) that provides management of a connection between the API and the database update process, which itself may be a daemon or system agent.
  • a daemon or system agent i.e., a background task
  • multiple instances of the database daemon preferably execute on servers throughout the CDN so that a given engine has the ability to obtain the update information even if a particular update process fails or the connection between the engine and an update process fails.
  • the CDN periodically generates the IP-to-geo-location maps that are transferred (e.g., via ftp) to the database update daemon(s) and, thus, to the engine(s) operated by the content
  • the information delivery system of the present invention is implemented as software in commodity hardware running an operating system.
  • the processes are shown as separate and distinct for illustrative and discussion purposes, given functionalities may be integrated into one or more processes, modules, routines, execution threads, or other known programming constructs.
  • the API may be suitably combined with the engine.
  • One or more of the processes typically include other sub-processes or functions.
  • FIG. 2 illustrates the basic operation of the information delivery system. It is assumed that end user 200 interacts with Web server 202 over network 204, which may be the Internet. Web server 202 has been provisioned with the API 206, the engine 208, and a local instance of the database 210 within the content provider execution environment 205. As described above, the content delivery network (CDN) manages the database update processes 212. hi operation, the user request for the Web site reaches the Web server. This is step (1). At step (2), the Web server uses the integrated API 206 to send the user's IP address to the engine 208. If the engine does not have the user's geographic and network data stored locally in the database 210 or cannot otherwise obtain it, the engine retrieves that data from the knowledge base stored on the CDN.
  • CDN content delivery network
  • step (3) There may be many reasons why the engine cannot obtain the data locally. The data may not be present. The database itself may have been corrupted. The machine on which the database resides may not have sufficient memory.
  • the engine has obtained the data from either the local database or from a remote instance.
  • the engine 208 sends the user data back to the integrated API 206.
  • the Web server selects customized content for delivery to the user based on the geo-location and/or network data provided.
  • the local instance of the database 210 is updated periodically to ensure that the Web server application has the most up-to-date information.
  • the invention (whether a managed service or a standalone product) preferably is architected using three (3) subsystems or components that interact with a Web site's application environment: ChentAPI 300, Facilitator 302 (the "engine"), and a Datad (the “database update”) process 304.
  • ChentAPI is a piece of code that is integrated into a customer application to make queries to the service, specifically the Facilitator.
  • the Facilitator is a process that runs in the customer environment and is responsible for establishing and managing connections between the customer application and the CDN, specifically one or more Datad processes.
  • the Facilitator is also responsible for listening and responding to requests from the ChentAPI.
  • the Datad is the process that preferably runs in multiple locations on the CDNSP 's network.
  • the primary purpose of the Datad component is to respond to queries from Facilitator processes in an authenticated, secure, and highly available way, and to manage updates to the database that is stored, preferably on the same servers as Datad processes.
  • database queries are serviced by the Facilitator locally if at all possible to avoid network transport, but this is not always possible for the reasons discussed above.
  • ChentAPI 300 is source code that is integrated into the customer Web and/or application servers to make queries to the Facilitator.
  • the application programming interface may be implemented as C code, as a Perl script, as a Java class, or the like, as is described below.
  • Facilitator 302 preferably is a deamon process that runs directly on the customer web or application server.
  • the basic function of the Facilitator is to be queried by instances of the ChentAPI and to handle all of the complexities of fetching the answers.
  • Facilitator in particular, is responsible for several functions. First, upon starting up, Facilitator retrieves a list of optimal Datad processes to which to connect. This retrieval may be accomplished using a global load balancing infrastructure or any other convenient mechanism provided by the CDN.
  • Facilitator retrieves IP addresses of a given number of Datad processes that have (or can be shown to have) good connectivity to the Facilitator.
  • the Facilitator preferably makes a connection to each of the returned Datad servers (or to some given subset), and it may then use a selection algorithm to elect an optimal Datad server, e.g., by setting preferred priorities based on average response times from each Datad server.
  • the Facilitator is responsible for requesting authentication and authorization, as well as securing communication between the content provider application and the CDNSP network.
  • the authentication and authorization step preferably involves the Facilitator sending a license certificate to the Datad process to which it is connecting.
  • a negotiation process between the Facilitator and the Datad process begins to secure communications over the network, namely, the transfer of a given database response (if the database is not available locally and/or not current) as well as to facilitate the periodic transfers of the database update(s).
  • the Facilitator begins listening on a configured port for requests (preferably over UDP) being made by the ChentAPI. If communications between the ChentAPI and the Facilitator are not secure, they should reside on the same server.
  • the Datad preferably is a daemon process that runs on the CDNSP network or some other location network location remote from the Facilitator.
  • a Datad process also responds to queries from a customer application (through the API and Facilitator) if the Facilitator cannot service the query locally.
  • these servers possess databases of CDN-compiled information that may be queried through the service/ delivery system of the invention.
  • the Datad daemon is a multi-threaded application that receives and maintains TCP connections with multiple Facilitators.
  • the Datad daemon authenticates connection requests from Facilitators by verifying the license certificate received from each Facilitator.
  • the license certificate sent by the Facilitator to the Datad process preferably is a signed certificate using the Digital Signature Algorithm (DSA) or the like.
  • DSA Digital Signature Algorithm
  • a first type of request is a query for information about a specific IP address. This type of request is delivered, for example, when the Facilitator is unable to service the request using a local (Facilitator-side) instance of the database.
  • a second type of request is a request for a most current data file (i.e., a new instance of the database, or some portion thereof) that can then be used by Facilitator for localized data lookup. If the Datad server process has a more current data file then the querying Facilitator, the data file is sent over a secure TCP connection to the Facilitator. This is the database update function.
  • the Facilitator connects to and preferably maintains connectivity with one or more Datad processes, it is able to easily fail over to a good connection if a primary Datad process begins to fail. Also, as the Facilitator preferably has a weighting and prioritization capability, preferably it will always provide the preferred connection to the optimal Datad process. In the unlikely event that no Datad processes are available to the Facilitator, the ChentAPI returns a default answer based on a timeout parameter set in the API. Integration with a content provider's Web site or other application is straightforward.
  • the API is integrated into the provider's Web application to field user requests to the Web site.
  • the API submits a query to the engine for the IP address resolution.
  • the API parses the response to give the provider access to any of all of the metrics returned from the query.
  • the engine functions to retrieve the queries from Web applications enhanced with the API to conduct the IP address lookup and subsequent return of user access information. Further, the engine maintains the integrity of the database and facilitates the connectivity to the CDNSP or other network for retrieving the most up-to-date database instance. It also controls the backup functionality of direct connectivity to the database servers in the event the local server becomes unavailable or is not the provider's preferred configuration.
  • CDNs generate comprehensive databases that map IP addresses (or IP address blocks) to their corresponding geographic region of origin.
  • the inventive service offers a highly accurate database that is updated frequently.
  • providers can start managing their content distribution with data about user access including country of origin, region within a country (such as state), the network origin of the user request, such as AOL or AT&T, and the network type such as cable modem, DSL, dial-up or ISDN.
  • the API and engine provide optimized performance and reliability. They are easily integrated in Web application systems as well as custom provider- developed applications that utilize current Web design standards.
  • the invention is implemented as a managed service that directly connects to the CDN. This direct connectivity gives the provider access to the most up-to-date information that the CDN has available, as well as access to a backup data source if local database connectivity becomes unavailable.
  • the present invention has many applications, several of which are identified below.
  • the database is a knowledge base that enables network and content providers to more intelligently serve content and control assets.
  • the invention leverages the CDN's distributed network topology, vast reach (thousands of servers in hundreds of networks worldwide) and intelligent mapping technology to gather data about the end-user's geographic location and network point of origin.
  • the CDN constantly maps the Internet and collects useful real-time data. This network mapping data is made available through the invention to network and content providers who wish to improve the planning, design, maintenance and monitoring of their network assets and/or the effectiveness and targeting of their Web site content.
  • the invention provides an ideal source of geo-location and last mile bandwidth information based on knowledge of users' access points to the Web.
  • the database preferably covers all assigned, route-able addresses in the commercial Internet Protocol (IP) address space.
  • IP Internet Protocol
  • the applications for this data include, without limitation:
  • Web reporting analysis data can be matched with web reporting logs to provide enhanced geo- and bandwidth information on visitors to a site
  • the system does not make any attempt to collect any personally identifying information. Rather, the information delivery system provides anonymous information about how a user accesses the Internet, not user-specific information that identifies a person. Information preferably is reported once per visit.
  • the inventive technique does not download anything to the client nor does it attempt to collect anything from a client.
  • the invention does not track client usage or history between during or between sessions. Indeed, with the widespread use of DHCP and Firewalls, IP addresses generally do not provide an effective approach to tracking the behavior of an individual user or machine.
  • Implementation Details The remainder of the description details the technical elements of a preferred embodiment of the invention. This section contains a high-level description of the system operation, the API for the client, and instructions as to the behavior.
  • the invention preferably is provided through three subsystems:
  • Datad runs on the CDNSP network, preferably at a collocation facility that is near the customers who will use those servers. These machines preferably get full databases that include all the possible information that will be queried, and they can handle requests from multiple customers. A Datad machine verifies the authenticity of clients, and it ensures secure communication.
  • Facilitator is preferably a daemon that runs directly on the web server, or if not possible, on a machine within the firewall of the system.
  • the Facilitator machine can run in multiple modes, to be explained below, but its basic function is to be queried and to handle all the complexities of fetching the answers. It passes a license to the Datad, and it establishes multiple encrypted channels over which it will try to optimally get answers to queries. It also sets up a UDP listening port on which clients can pull data.
  • ChentAPI specifies how a content provider server talks to the Facilitator.
  • This API can be provided as source code, explanation of protocol, or dynamic objects that can be used.
  • the API can also be implemented as a program that is used in CGI scripts.
  • a site administrator preferably installs and runs the Facilitator on each of the site's web servers. If this is not possible, the administrator installs the Facilitator on a dedicated machine that is within the site's firewall. Preferably the Facilitator is not installed on an open machine.
  • the Database Daemon (Datad) is not installed on an open machine.
  • the database daemon preferably executes on the CDN or other third party network. This process is responsible for several functions: • Responding to queries: Queries are normally generated by a Facilitator. A connection is established (secure, authentic), and depending on the license that a customer is issued, different data maybe sent down based on query. The entire communication preferably is handled over TCP, using a protocol described in the following section. • Update data: The daemon also regularly contacts the CDN's update servers, and it may query to find out if new database information is available. This may include more accurate maps, and possibly more information for any particular IP address.
  • the daemon is also responsible for accumulating information about the kind of queries being made, and preferably it makes summaries available through a query function, as well as logging this data to a statistics file.
  • the daemon preferably achieves the lookups by downloading map files and database files.
  • the map file is a lookup from an IP address to a database entry point (an integer).
  • the database preferably maps the entry point to a record that contains all known data about this IP block, preferably, e.g., Berkeley DB.
  • This server also executes a process that is responsible for making sure the Datad gets restarted if necessary (such as a failure or reboot).
  • Facilitator is responsible for making sure the Datad gets restarted if necessary (such as a failure or reboot).
  • the Facilitator is responsible for being the interface the clients use to fetch the data.
  • the Facilitator is configured upon installation and operates in several modes:
  • CDNPlatform Mode In this mode, the Facilitator maintains secure connections open to the CDN through which it transmits queries.
  • Hybrid Mode In this mode, the Facilitator sets up a local Facilitator that has the database stored locally but then regularly gets updates to the data from the CDN. This way, whenever the data changes the Facilitator downloads updates. Response times are fast, however, because all the data is local.
  • Facilitator preferably resolves a special domain name to receive a list of IP addresses (for the Datad process) that it should contact.
  • this list is set up on the CDN DNS servers to pick the correct set of machines for this client.
  • a TCP connection is opened to each Datad server (or to a given subset), and negotiations for an encryption key start. This includes transmission of given license information.
  • a listener thread is created that listens on a specific UDP port for API queries that come in. When a query arrives (using the UDP protocol), it is parsed. Then, intelligence is applied to communicate this query to a queue associated with the best TCP connection.
  • pending queries will be sent through a connection (preferably using TCP protocol) and when a response arrives, it is sent back to the client, preferably using the UDP protocol. Preferably all queries are responded to, and no timeouts are included here. However, when a TCP connection gets slow or has problems, it will not be used. As TCP connections get bad or die, the Facilitator is responsible for refreshing, fixing, or, if appropriate, giving up on them. ChentAPI
  • the client API is simply specified, preferably as a UDP-based query-response system, with a timeout.
  • the querying entity sets up a socket to communicate with the Facilitator, forms a query packet (based on the UDP protocol), and sends it to the server. It then polls the socket for a response and either gets it in time, or times out (at which point a default action is taken). Protocols
  • TCP is used to contact the CDN servers to allow negotiations, authorization and connection setup to be performed once, and then queries are made afterwards .
  • a TCP connection first needs to be established.
  • the license is used and encryption/authentication is enabled.
  • a client introduces itself to the server, key negotiation is established (for a secure communication between the two), and options are passed through.
  • UDP is used for the regular query-response that is made with every connection.
  • the querying entity sets up a socket from which it will send a query to Facilitator, and on which it waits for the response.
  • the content provider preferably runs the Facilitator on each of its Web servers. It may also need to place a hole through its firewall for outgoing TCP connections to some port.
  • the content provider may need to obtain and install the license on each of their machines.
  • the content provider needs to configure the Facilitator and inform the CDNSP of the IP address of the Facilitator so that the CDN may map it to the best Datad servers.
  • License The content provider receives from the CDNSP a license, which preferably specifies information about their operating system, machine configuration, name, expiration date, and the content provider's secret key. This information preferably is signed with the CDNSP 's public key.
  • the API is used to perform a lookup by calling the cdnsp_ip_lookup function, using the following parameters:
  • the arguments to this function are: addr An Internet family address (ipv4) that specifies the address being queried. If that is not available, you may also pass in the 32-bit number.
  • buffer A pointer that is set to the buffer which will contain the result of this function.
  • len An argument/result. It will contain the length of the buffer on calling, and will return the length of the data on result. Please note that if the buffer is too short, you will get an error.
  • timeout Is the amount of time for which the function should block waiting on an answer. If this time expires, buffer will contain the default answer instead, and the return code will indicate so.
  • the result codes for this function can be any possible value, but constants are used to indicate the meaning. A value of zero is a success code, while any other value is an error.
  • the resulting buffer will contain the IP resolution answer.
  • This answer preferably is encoded as a list of entries separated via a null character, and terminated with a null character. Multiple values for an attribute are separated by a plus (+) character. Each entry is an attribute/value pair separated by an equals sign.
  • a convenience function is provided. This function is not required, but it is useful for retrieving a specific attribute regularly (e.g. country_code) using the following parameters: cdnsp_attr_get(const char *attr, const char *buffer, const size_t bufferjen, char **result)
  • Perl API The API is used to perform a lookup in the following manner:
  • $buffer cdnsp_ip_lookup( ⁇ ip>, ⁇ timeout>)
  • the arguments to this function are: ip An Internet family address (ipv4) that specifies the address being queried. If that is not available, you may also pass in the 32-bit number.
  • timeout Is the amount of time (in ms) for which the function should block waiting on an answer. If this time expires, buffer will contain the default answer instead, and the return code will indicate so.
  • the resulting buffer will contain the IP resolution answer.
  • This answer preferably is encoded as a list of entries separated via a null character, and terminated with a null character. Multiple values for an attribute are separated by a plus (+) character. Each entry is an attribute/value pair separated by an equals sign.
  • a convenience function is provided. This function is not required, but it is useful for retrieving a specific attribute regularly (e.g. country_code) using the following parameters:
  • $country cdnsp_attr_get(buffer, ⁇ attr>)
  • the arguments to this function are: attr A null-terminated string indicating the name of the attribute desired, buffer The buffer filled by cdnsp_ip_lookup ($buffer in the above example)
  • the instantiator accepts the following: CdnData(String, int) - As in the example from above
  • CdnData (hietAddress, int) - Instead of string, use an InetAddress class CdnData (InetAddress) - Similar to the above, but the default timeout is used
  • CdnData (byte[] , int) - Instead of a string obj ect, pass in a 4 byte array which represents the IP address in network byte order.
  • CdnData (byte[]) - Similar to the above, but the default timeout is used.
  • JavaDemo.results[x][0] is the attribute
  • JavaDemo.results[x][l] is the value associated with the attributes.
  • set_cdn_server(String ip) get_cdn_server(), set_cdn_port(int port), get_cdn_port(), and set_cdn_server_and_port(String ip, int port) are provided.
  • the argument to set_cdn_server is the IP address of a new Facilitator against which to perform queries; the argument to set_cdn_port is the Port of the new Facilitator against which to perform queries.
  • the set_cdn_server_and_port function sets both the IP and the Port of the new Facilitator, and it retains both the IP and the Port of the current Facilitator if it fails to set either.
  • the get_cdn_server function returns the IP address of the current Facilitator; the get_cdn_port function returns the Port of the current Facilitator.
  • the following provides representative metrics from the database.
  • MSA States : Cities
  • PA Allentown-Bethlehem-Easton
  • GMT+1 GMT+1 : APO/FPO (Central Europe)
  • Representative software and hardware configurations are as follows.
  • For the Facilitator server (assuming 512 MB RAM and 500 MB free disk space): Sun Solaris 2.6 or above running on Sun Ultra 5; Linux Red Hat 6.1 or above running on Pentium 233 Mhz PC; FreeBSD 3.4 or above running on Pentium 233 Mhz PC.
  • ClientAPI For the ClientAPI (assuming 64 MB RAM): SunSolaris 2.6 or above running on Sun Ultra 5; Linux Red Hat 6.1 or above running on Pentium 233 Mhz PC; FreeBSD 3.4 or above running on Pentium 233 Mhz PC, server; Microsoft Windows NT 4.0 running on Pentium 233 Mhz PC.
  • the preferred software requirements for the API Windows - Microsoft Virtual Studio 6 or Borland C++ Builder 5; Java - JDK 1.2 or above; Perl - Perl 5.0 or above.
  • the daemon runs on commodity PC hardware running Linux OS. Having thus described our invention, what we now claim is set forth below.

Abstract

L'invention concerne un système et un procédé permettant d'identifier de manière précise la situation géographique depuis laquelle des utilisateurs accèdent à un site web et l'origine de réseau d'une demande d'utilisateur. L'utilisateur final (200) interagit avec le serveur web (202) sur le réseau (204) qui peut être le réseau Internet. Le serveur web (202) est pourvu de l'interface de programme d'application API (206), du moteur (208) et d'une instance locale de la base de données (210) à l'intérieur de l'environnement (205) d'exécution du fournisseur de contenu. Le réseau de délivrance du contenu CDN administre des processus (212) de mise à jour de données. Durant l'utilisation, la requête du site web par l'utilisateur atteint le serveur web (202) qui utilise l'API (206) pour envoyer l'adresse IP de l'utilisateur au moteur (208). Si le moteur (208) ne possède pas les données géographiques et les données de réseau de l'utilisateur stockées localement dans la base de données (210) ou ne peut pas les obtenir, le moteur (208) extrait les données de la base de connaissances stockée sur le réseau de délivrance du contenu CDN.
EP01964022A 2000-08-18 2001-08-15 Procede et systeme permettant de fournir des informations a des fournisseurs de contenus concernant la maniere dont leurs utilisateurs accedent a l'internet Withdrawn EP1419455A4 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US22640500P 2000-08-18 2000-08-18
US226405P 2000-08-18
PCT/US2001/025491 WO2002017139A1 (fr) 2000-08-18 2001-08-15 Procede et systeme permettant de fournir des informations a des fournisseurs de contenus concernant la maniere dont leurs utilisateurs accedent a l'internet

Publications (2)

Publication Number Publication Date
EP1419455A1 true EP1419455A1 (fr) 2004-05-19
EP1419455A4 EP1419455A4 (fr) 2004-12-15

Family

ID=22848779

Family Applications (1)

Application Number Title Priority Date Filing Date
EP01964022A Withdrawn EP1419455A4 (fr) 2000-08-18 2001-08-15 Procede et systeme permettant de fournir des informations a des fournisseurs de contenus concernant la maniere dont leurs utilisateurs accedent a l'internet

Country Status (3)

Country Link
EP (1) EP1419455A4 (fr)
AU (1) AU2001284922A1 (fr)
WO (1) WO2002017139A1 (fr)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7685311B2 (en) 1999-05-03 2010-03-23 Digital Envoy, Inc. Geo-intelligent traffic reporter
US6757740B1 (en) 1999-05-03 2004-06-29 Digital Envoy, Inc. Systems and methods for determining collecting and using geographic locations of internet users
US7844729B1 (en) 1999-05-03 2010-11-30 Digital Envoy, Inc. Geo-intelligent traffic manager
US6684250B2 (en) 2000-04-03 2004-01-27 Quova, Inc. Method and apparatus for estimating a geographic location of a networked entity
CN101227311B (zh) * 2008-02-03 2010-12-01 腾讯科技(深圳)有限公司 互联网信息发布系统和发布方法
US20100214976A1 (en) 2008-02-06 2010-08-26 Medio Systems, Inc. Operator cloud for mobile internet services
US8443107B2 (en) 2009-11-11 2013-05-14 Digital Envoy, Inc. Method, computer program product and electronic device for hyper-local geo-targeting
US9537869B2 (en) * 2011-02-11 2017-01-03 Blue Cedar Networks, Inc. Geographical restrictions for application usage on a mobile device

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999034305A1 (fr) * 1997-12-24 1999-07-08 America Online, Inc. Localisation de clients et de serveurs
US5944790A (en) * 1996-07-19 1999-08-31 Lucent Technologies Inc. Method and apparatus for providing a web site having a home page that automatically adapts to user language and customs
WO2000022495A2 (fr) * 1998-10-15 2000-04-20 Liquid Audio, Inc. Determination territoriale de l'emplacement d'un ordinateur a distance dans un reseau longue distance en vue d'une remise conditionnelle de produits numerises
US6108703A (en) * 1998-07-14 2000-08-22 Massachusetts Institute Of Technology Global hosting system
EP1039265A1 (fr) * 1999-03-23 2000-09-27 Sony International (Europe) GmbH Système et méthode pour la gestion automatique d' information de location géographique
WO2000067450A1 (fr) * 1999-05-03 2000-11-09 Digital Envoy, Inc. Systemes et procedes permettant de determiner, d'obtenir et d'utiliser la localisation geographique des utilisateurs internet

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6272343B1 (en) * 1998-10-13 2001-08-07 Tellus Technology, Inc. Method and apparatus for fast signal acquisition of preferred wireless channel
US6243746B1 (en) * 1998-12-04 2001-06-05 Sun Microsystems, Inc. Method and implementation for using computer network topology objects

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5944790A (en) * 1996-07-19 1999-08-31 Lucent Technologies Inc. Method and apparatus for providing a web site having a home page that automatically adapts to user language and customs
WO1999034305A1 (fr) * 1997-12-24 1999-07-08 America Online, Inc. Localisation de clients et de serveurs
US6108703A (en) * 1998-07-14 2000-08-22 Massachusetts Institute Of Technology Global hosting system
WO2000022495A2 (fr) * 1998-10-15 2000-04-20 Liquid Audio, Inc. Determination territoriale de l'emplacement d'un ordinateur a distance dans un reseau longue distance en vue d'une remise conditionnelle de produits numerises
EP1039265A1 (fr) * 1999-03-23 2000-09-27 Sony International (Europe) GmbH Système et méthode pour la gestion automatique d' information de location géographique
WO2000067450A1 (fr) * 1999-05-03 2000-11-09 Digital Envoy, Inc. Systemes et procedes permettant de determiner, d'obtenir et d'utiliser la localisation geographique des utilisateurs internet

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
"GLRS (Geographic Location Resolution Server)"[Online] 15 August 2000 (2000-08-15), XP002162124 Retrieved from the Internet: URL:http://web.archive.org/web/20000815111 358/glrs.networldmap.com> [retrieved on 2004-10-01] *
"InfoSplit Java API"[Online] 16 August 2000 (2000-08-16), XP002299118 Retrieved from the Internet: URL:http://web.archive.org/web/20000816003 707/www.infosplit.com/pages/developers.htm l> [retrieved on 2004-10-01] *
"SPOT (Systematic Position Online Targetter)" DIGITAL ENVOY, [Online] 27 November 1999 (1999-11-27), XP002298987 Retrieved from the Internet: URL:http://web.archive.org/web/19991127165 432/digitalenvoy.com/products/products.hm> [retrieved on 2004-10-01] *
See also references of WO0217139A1 *

Also Published As

Publication number Publication date
WO2002017139A1 (fr) 2002-02-28
AU2001284922A1 (en) 2002-03-04
EP1419455A4 (fr) 2004-12-15

Similar Documents

Publication Publication Date Title
CN102047242B (zh) 内容管理
JP4968975B2 (ja) 分散型コンピュータネットワークにおけるコンテンツ配信方法
RU2364925C2 (ru) Бесшовное обнаружение установленных на рабочей станции удаленных приложений из экстрасети
CN108270882B (zh) 域名的解析方法和装置、存储介质、电子装置
US8903950B2 (en) Personalized content delivery using peer-to-peer precaching
US9251112B2 (en) Managing content delivery network service providers
US8825849B2 (en) Distributed data collection and aggregation
US7984186B2 (en) Method, system, and apparatus for discovering user agent DNS settings
US20120173677A1 (en) Request routing
US8156223B2 (en) Distribution of binary executables and content from peer locations/machines
EP1716466B1 (fr) Presentation d'une vue fusionnee d'acces rapide d'applications a distance en provenance d'une pluralite de fournisseurs
CA2501568A1 (fr) Service web de recherche d'application a distance
AU2004279168A2 (en) A web service for remote application discovery
KR20030022806A (ko) 콘텐트 교환 장치
WO2008130946A2 (fr) Procédés et systèmes discrets permettant la collecte d'information transmise sur un réseau
US7584261B1 (en) Distribution of binary executables and content from peer locations/machines
KR20030022805A (ko) 콘텐트 추적
WO2002017139A1 (fr) Procede et systeme permettant de fournir des informations a des fournisseurs de contenus concernant la maniere dont leurs utilisateurs accedent a l'internet
KR20030076224A (ko) 클라이언트측의 전체적인 상태 체크
JP4185315B2 (ja) ネットワーク上の端末位置特定方法及びネットワークシステム
KR20030051431A (ko) 클라이언트측 어드레스 라우팅 분석 방법
NANO Network resource identification
WO2009128820A1 (fr) Procédés et systèmes discrets de collecte d’informations transmises sur un réseau
AU2004279175A1 (en) Presenting a merged view of remote application shortcuts from multiple providers

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20030626

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

RIN1 Information on inventor provided before grant (corrected)

Inventor name: YERUSHALMI, YOAV

Inventor name: SUNDARAM, RAVI

Inventor name: ROSE, KYLE

Inventor name: KLONINGER, JOHN, JOSEF

Inventor name: DHANIDINA, RIZWAN, S.

A4 Supplementary search report drawn up and despatched

Effective date: 20041028

17Q First examination report despatched

Effective date: 20050614

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20070123