PEER -TO-PEER CONTENT DELIVERY NETWORK, METHOD, AND MANAGERBACKGROUND OF THE INVENTIONFIELD OF THE INVENTIONThe present invention generally relates to content delivery network and associatedmethodology that provides a media compliance engine. The media compliance engine accordingto the present invention operates by way of local gateway servers, which utilize peer-to-peernetworks and multiple data origins (clouds) to optimize the delivery of media and streamline thereporting process. The media compliance engine according to the present invention matchesrequests from streaming providers with an optimized data source and network. By doing this themedia compliance engine can minimize bandwidth consumption, licensing, and reporting costs.
SUMMARY OF THE INVENTIONThe present invention provides a peer to peer Content Delivery Network (CDN) that canbe added to any existing standard content delivery network, or server configuration without anychanges to back end systems. The peer to peer CDN according to the present invention iscreated when the end user installs a local peer to peer gateway server on the client machine. Thegateway server receives request(s) from the media consuming client via encrypted orunencrypted connections (e.g. HTTP, HTTPS, Secure Socket, and/or Socket).
The local gateway server acts as a peer on the peer-to-peer network and has an encryptedcache for storing data for delivery to other peers or for local delivery to a data consuming client.
The local gateway server can also pull resources from a related remote data source (e.g. a serveror other CDN). The consuming client would only need to pass a single request to the gatewayserver, and the gateway server manages the resources and network connection independently ofthe client. This type of setup enables the delivery of media not only to stand alone desktopapplications but also to browsers and media players, and mobile applications that have standardweb browsers capabilities (e.g. HTTP, HTTPS, and/or Socket).
The present invention provides a peer-to-peer (P2P) gateway server that receivescommunication from a client on a local machine. The communication or request can beformatted as a standard HTTP request directed at the local gateway server which will beregistered under a local domain name. It is contemplated that the request(s) may be formatteddifferently if a new transfer protocol is created that references a reserved port where the gatewayserver would reside. In this case, the request would be formatted slightly differently (i.e. withoutthe HTTP prefix).
The invention provides a Resource Name Server (RNS), which RNS caches resourceURL's, and resource locations (i.e. IP addresses) and resolves resource requests with machineaddresses. The general process or methodology for an un-matched media type would be asfollows.1. Client sends a request for resources to the gateway server;2. The gateway server then sends the request to the RNS to resolve the resource requestwith a resource address;3. Once the resource request is matched with the optimal (least costly) resource locations,the resource location data is returned to the gateway server;4. The gateway then sends the request for resource data to the appropriate machines orserver clusters;5. The machines or service clusters then respond by serving the data that is requested tothe gateway server located on the local machine.6. The gateway process organizes and validates the data and then delivers the resources tothe client on the local machine.
The reader will note that in a traditional Client-Server relationship, a client requests datafrom a server and the server delivers data pursuant to client request. In a traditional unmanagedpeer-to-peer network each peer can act as both a server (i.e. a deliverer of data) and a client (i.e.a receiver of data). an unmanaged environment a request for data is passed from peer to peeruntil a file is located.
A managed peer to peer network has a centralized server that indexes resources. Thepeers in such a network report and register their availability, thus making it easier and quicker tolocate a resource. In a hybrid system a peer to peer network is used alongside a centralized datasource/indexing server to provide the low costs of peer delivery but the consistency and speed ofa centralized data source and in order to expedite resource delivery as in the managed peer topeer network. In this situation a mix of data origin server and peers deliver the data.
According to the present invention, the client is a stand-alone client, and the data requestoriginates and is consumed by a stand-alone client (browser, desktop or mobile application).
Unlike the networks prefaced hereinabove, the request for data does not originate with the peer,but with a stand-alone client as in a traditional client server relationship.
The gateway server receives the request and then resolves the request for a resource witha Resource Name Server (i.e. resource indexing server). The RNS responds with resourcelocations (IP address), which can be resource origins or peers. Given that the network is dataorigin agnostic, peer data is not managed by a central data server, but rather indexed on the RNSas requests are passed and cached at the gateway server.
Accordingly, in such a network the data source is separate from the resource indexingserver, thus allowing any request for data by a stand-alone client to be filled from the data originor a peer-to-peer (P2P) network, since the data within the P2P network is cached when therequest is sent from the stand-alone client.
BRIEF DESCRIPTION OF THE DRAWINGSOther features of our invention will become more evident from a consideration of thefollowing brief descriptions of illustrations of the subject invention:Figure No. 1 is a diagrammatic depiction of a fragmented arrangement for a data fileincluding rows of sub-stream packets and columns of validation packets.
Figure No. 2 is a first diagrammatic depiction of a system overview according to thepresent invention, showing a gateway server positioned intermediate a cloud of server clustersand a resource name server.
Figure No. 3 is a second diagrammatic depiction of a system overview according to thepresent invention, showing a gateway server positioned intermediate a cloud of server clustersand a resource name server.
Figure No. 4 is a diagrammatic depiction of a domain name server system overview.
Figure No. 5 is a diagrammatic depiction of a resource name server system overview.
Figure No. 6 is a diagrammatic depiction of a non-plug-in security measure overview.
Figure No. 7 is a diagrammatic depiction of a traditional client- server relationshipwhereby a client requests data and the server delivers data.
[[Figure]] No. 8 is a diagrammatic depiction of a peer-to-peer unmanaged networkoverview whereby each peer can act as both a server and a client where requests for data arepassed from peer to peer until a file is located.
Figure No. 9 is a diagrammatic depiction of a peer to peer managed network overview inwhich a centralized server indexes resources and in which the peers report and register theiravailability.
Figure No. 10 is a diagrammatic depiction of a peer to peer centralized hybrid networkoverview with which a peer to peer network is used alongside a centralized data source/indexingserver to provide the low costs of peer delivery but the consistency and speed of a centralizeddata source.
Figure No. 11 is a diagrammatic depiction of a peer to peer gateway server networkoverview.
Figure No. 12 is a diagrammatic depiction of how secure connections are structured viewa local server and browser.
Figure No. 13 is a diagrammatic depiction of how a local gateway server is validated viaa plug-in.
Figure No. 14 is a diagrammatic depiction of a resource indexing arrangement with aninitial request and no file matching.
Figure No. 15 is a diagrammatic depiction of a resource indexing arrangement withsubsequent request and no file matching.
Figure No. 16 is a diagrammatic depiction of a progressive cloud indexing arrangementwith an initial request.
Figure No. 17 is a diagrammatic depiction of a local resource indexing arrangement.
Figure No. 18 is a diagrammatic depiction of a first indexed resource request processingarrangement.
Figure No. 19 is a diagrammatic depiction of a second indexed resource requestprocessing arrangement.
Figure No. 20 is a diagrammatic depiction of a third indexed resource request processingarrangement.
Figure No. 21 is a diagrammatic depiction of a fourth indexed resource requestprocessing arrangement.
Figure No. 22 is a diagrammatic depiction of a sub-licensing, cloud deliveryarrangement.
Figure No. 23 is a diagrammatic depiction of a sub-licensing, peer-to-peer deliveryarrangement.
Figure No. 24 is a first diagrammatic depiction of a streaming provider requesting that asong be played on a mobile device according to the present invention.
Figure No. 25 is a second diagrammatic depiction of a streaming provider requesting thata song be played on a mobile device according to the present invention.
Figure No. 26 is a diagrammatic depiction of a gateway server enhanced system overviewaccording to the present invention.
Figure No. 27 is a diagrammatic depiction of a pre-recorded media queue arrangementaccording to the present invention.
Figure No. 28 is a diagrammatic depiction of a stream splitting arrangement according tothe present invention.
Figure No. 29 is a diagrammatic depiction of a MP3 file structure according to thepresent invention showing frame headers and audio frames of an audio stream.
Figure No. 30 is a diagrammatic depiction of state of the art methods for streaming radioover the Internet.
Figure No. 31 is a diagrammatic depiction of a system overview for advertisementintegration without audio mixing according to the present invention.
Figure No. 32 is a diagrammatic depiction of an advertisement marker arrangementaccording to the present invention.
Figure No. 33 is a diagrammatic depiction of methodology relating to routing HTTPrequests from browsers and/or other media-consuming clients.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT / METHODOLOGYReferencing the drawings now with more specificity, the present invention provides aContent Delivery Network and associated Methodology for Cloud Agnostic Peer-to-Peer DataStreaming. As discussed above, the invention comprises a peer-to-peer (P2P) gateway server asdepicted and referenced at 3. The P2P gateway server 3 receives communications (as at 200)from the client 2 on the local machine 101.
These requests may be formatted as standard HTTP requests directed at the local gatewayserver 3 which will be registered under a local domain name. While routing HTTP requests fromweb browsers and other devices may include the use of locally registered domain names andprotocols are viable methods, the following method is preferred when routing HTTP requestsfrom browsers and other media consuming clients.
The consuming client 2 is given a Fully Formatted domain name to the peer-to-peerremote servers 4 or Resource Name Servers 4. For the sake of simplicity, the reader willconsider the domain name www.rns_server.com. In order to request media 401 through thepeer-to-peer Content Delivery Network (CDN) as at 144, the client 2 contains a UniformRecourse Locator (URL) with RNS public domain name, and a GET variable with the location ofthe requested media, something of the formwww.rns_server.com?media=www.somemediasource.com/media.mp4&protocol=http.
When the RNS 4 receives the request it queries 404 two distinct data bases. The firstquery uses the requesting devices public Internet Protocol (IP) address to identify if any networkpeers 3 exist within the requesting devices local network 101. The second query searches theresource database to identify peers 3 with the requested media available for streaming (as at 200,207, 208, 209, and 210) within the peer-to-peer (P2P) CDN 144.
Based on the result of queries 404 the following things could happen. Firstly, if there isno registered peer on the local network the request is redirected as at 403 to the media's remotesource 104, and the P2P network 144 will not be utilized. If there is a registered peer 3 withinthe local network 101, the request is redirected as at 402 to the local network peer 3 along withthe resource location and availability data which was retrieved in the second query 404. Thelocal network peer 3 then handles the media stream (as at 200, 207, 208, 209, and 210).
The reader will thus appreciate that the Resource Name Server (RNS) as referenced at 4,is central to the practice of the present invention. The RNS 4 caches resource URL's andresource locations (IP addresses), and resolves resource requests with machine addresses (IPaddresses). The general process for an un-matched media type would be as follows. The client 2sends a request for resources (as at 200) to the gateway server 3.
The gateway server 3 then sends the request (as at 201) to the compartmented RNS 4 toresolve (as at 202) the incoming resource ID/URL request (as at 203) with a resource address (asat 204), which resource or IP address is then communicated back (as at 205) to the gatewayserver 3 as more particularly depicted in Figure No. 5. In other words, once the resource request203 is matched as at 202 with optimal (e.g. (a) most price efficient or (b) highest sound quality ofsource) resource locations 204, the resource location data or IP address(es) 204 are returned as at205 to the gateway server 3.
The gateway server 3 then sends (as at 206, 207, and 208) request(s) for resource data tothe appropriate machines (102 and/or 103) or server clusters as at 104. The machines