Proxy caching in a photosharing peer-to-peer network to improve guest image viewing performance

The technical field of proxy caching technology for improving the viewing performance of visitors' images in a picture sharing peer-to-peer network

[0001] The present invention relates to sharing digital images on a network, and more specifically to a method and system for improving visitor viewing performance of images stored on a peer-to-peer computer in a picture sharing peer-to-peer network.

Background technique

[0002] In the past few years, photo sharing has gradually been widely accepted by photo enthusiasts. Currently, there are many Web sites that allow users to upload digital images to the site so that they can be stored in a server and viewed by others via the Internet. Often times, the images are grouped to form an album page, so that for each individual image, the user can invite others to view the album page.

[0003] However, this method of picture sharing has some disadvantages. Specifically, users are required to upload digital images to the website, which may be time-consuming, and the website requires a huge storage capacity to store all users' images, which may become costly.

[0004] In order to solve these problems, the assignee of the present invention has developed a Web-based peer-to-peer picture sharing system, in which all workstations and computers (peer parties) in the network store images locally and serve as other users on the network. Server Ο The central website accessible to all peers provides additional functions, such as coordinating peers, providing peers with search functions, completing purchase orders, etc.

[0005] FIG. 1A is a block diagram illustrating a Web-based peer-to-peer picture sharing system. The peer-to-peer picture sharing system 20 includes a picture sharing P2P network 22, which includes a plurality of peer-to-peer servers 24 running peer-to-peer node software 26 and Web server software 28. Peer-to-peer and server software 24 and 26 enable computer users to share images with others in the network 22 through the Web browser 30 without uploading their pictures to a Web site. The innovative feature of the picture sharing P2P network 22 is that it provides a hybrid peer-to-peer architecture for common HTTP/Web browser configuration, which combines with the central proxy server 36 to coordinate the network communication of peers behind the firewall, thereby Other peers and visiting computers 32 not in the network 22 are allowed to access peers behind the firewall. The proxy server 36 provides support services to the peer 24 and provides a path through which the visiting computer 32 accesses the image from the peer server 24 via a standard Web browser 30. Allowing ordinary HTTP access to images residing on peer-to-peer servers behind firewalls is becoming more and more important, because virtually all businesses use firewalls, and the use of software firewalls installed on users home systems is also changing Got popular.

[0006] FIG. 1B is a schematic diagram illustrating a data path used when an image is provided from one of the peers 24 to a visiting computer 32 via the proxy server 36. The process starts when the visitor initiates a request to view an image from the Web browser 30 of the visiting computer 32, and the request is routed to the proxy server 36 via the path (A). The proxy server 36 then routes the request to the peer server 24 via path (B). The peer-to-peer server 24 serves the request and returns the image to the proxy server via path (C). The proxy server 36 then sends the image to the visiting computer 32 via path (D) for display.

[0007] One problem with routing images via the proxy server 36 is that it requires additional bandwidth. That is, the image must be moved twice; once from the peer-to-peer server 24 to the proxy server 36, and then the second time from the proxy server 36 to visit computing

machine32. In addition, path (C) generally has the longest waiting time, because the peer-to-peer server 24 usually resides in the user's home and is equipped with a cable modem or DSL, and its upstream speed (path C) is much slower than the downstream speed (path B). Therefore, because of the bandwidth limitation between the peer-to-peer server 24 and the proxy server 36 path (C), the user may experience a considerable delay when viewing images routed via the proxy server 36.

[0008] Therefore, there is a need for a method and system for reducing the amount of network communication between a peer-to-peer server and a proxy server (path (C)) in order to improve visitor image viewing performance. The present invention addresses such needs.

Summary of the invention

[0009] The present invention provides a method and system for providing images stored in a peer-to-peer computer to a requesting computer in a network picture sharing system, where the peer computer is coupled to, for example, the agent described above The server's picture sharing server. Some aspects of the present invention include: caching a copy of the image in the image sharing server; and in response to the image sharing server receiving a request from the requesting computer to view the image stored in the peer computer, sending the cached image from the image sharing server It is transmitted to the requesting computer, thereby eliminating the need to transfer the image from the peer computer to the image sharing server for each request for viewing the image. In the second aspect of the present invention, before providing the cached image to the requesting computer, the picture sharing server sends an HTTP request containing the timestamp of the cached image to the peer computer to determine whether the cached image has been modified since it was cached. Cached image. The peer computer then compares the timestamp of the cached image with the timestamp of the image stored on the peer, and sends a response to the image sharing server to indicate whether the image has been modified based on whether the two timestamps match. If the image has been modified, the modified image is cached on the image sharing server and provided to the requesting computer. In another aspect of the present invention, the image stored on the peer-to-peer computer is automatically synchronized with the image on the picture sharing server, so that the picture sharing server always sends The requester provides the latest version of the image.

[0010] According to the method and system disclosed herein, caching the image on the picture sharing server avoids the need to transmit the image from the peer computer to the picture sharing server (path (C)) for each request to view the image. Therefore, the present invention greatly reduces the network communication volume between the peer-to-peer computer and the picture sharing server, and improves the image viewing performance of the picture sharing network.

Description of the drawings

[0011] FIG. 1A is a block diagram illustrating a Web-based peer-to-peer environment.

FIG. 1B is a schematic diagram illustrating a data path used when an image is provided from a peer to a visiting computer via a proxy server;

[0012] FIG. 2 is a detailed block diagram of an improved picture sharing network according to a preferred embodiment of the present invention.

[0013] FIG. 3 is a flowchart illustrating a process for improving guest viewing performance of images stored on a peer-to-peer server in a picture sharing peer-to-peer network.

[0014] FIG. 4 is a flowchart illustrating a process in which a peer-to-peer server registers to a picture-sharing peer-to-peer network so that its service capabilities can be accessed through a firewall.

[0015] FIG. 5 is a schematic diagram illustrating the components of the proxy server and the flow between the requesting Web browser, the proxy server, and the peer server for the Web browser to have HTTP access rights to the peer server through the proxy server.

[0016] FIG. 6A is a schematic diagram illustrating the content of a peer-to-peer request packet.

[0017] FIG. 6B is a schematic diagram illustrating the content of a peer-to-peer response packet.

Detailed ways

[0018] The present invention relates to sharing digital images through a network, and more specifically, to a method and system for improving image viewing performance of visitors. The following description is given to enable those skilled in the art to implement and utilize the present invention, and the following description is provided in the context of a patent application and its needs. It will be easy for those skilled in the art to see various modifications to the preferred embodiments and general principles and features described herein. For example, although the preferred embodiment is implemented in the context of a peer-to-peer network, the same principles can be applied to a client-server environment in which a guest browser directly communicates with a computer system storing photo albums and images. Therefore, the present invention should not be limited to the illustrated embodiments, but should conform to the broadest scope consistent with the principles and features described herein.

[0019] The present invention provides a method and system for improving the viewing performance of a peer-to-peer picture sharing network, in which peer-to-peer servers store images of their users and are coupled to at least one picture sharing system server, such as a proxy server.

[0020] FIG. 2 is a detailed block diagram of an improved picture sharing network according to a preferred embodiment of the present invention. In addition to the components shown in FIG. 1A, each peer-to-peer server 42 also includes a peer-to-peer node application 44 operating in accordance with the present invention and a database 46 that stores images 48. As is well known in the art, the image 48 is usually stored on the hard disk of the hosting computer system, and the hosting operating system is assigned a timestamp 50 indicating the creation date or the modification date.

[0021] The proxy server 40 acts as a proxy for the distributed peer-to-peer server 42, which has a pre-established connection to the proxy server 40. The proxy server 40 enables the firewall-protected peer-to-peer server 42 so as to be able to implement incoming general HTTP access by establishing an outgoing connection from the firewall-protected peer server 42 and the proxy server 36. Then, the incoming Web traffic of the peer-to-peer server 42 protected by the firewall is sent to the proxy server 40. The proxy server 40 uses a dedicated protocol to multiplex the Web traffic to the peer-to-peer server 42, thereby enabling general Web traffic to flow to the peer-to-peer server 42 even in the presence of a firewall (not shown). In the case of multiple peer-to-peer servers 42 protected by firewalls, the proxy server 40 acts as a switchboard to receive incoming HTTP requests and send them to a suitable peer-to-peer server 42. The process of providing Web browsing through the firewall in the peer-to-peer network is described in further detail below with reference to FIGS. 4 to 6B. As used herein, the peer-to-peer server 24, proxy server 36, and access computer 32 may include any computing device that executes the components necessary for suitable software, such as PCs, workstations, mobile phones, and PDAs. In a preferred embodiment, a physical communication network It is the Internet, of course, any type of network can be used.

[0022] According to the present invention, the image 40 stored in the peer-to-peer server 42 requested for viewing by the visiting computer 32 is stored in the cache 52 of the proxy server 40 before or after the image is requested for the first time . Thereafter, subsequent requests for these images are served by the cache 52 of the proxy server instead of being retrieved from the hosting peer-to-peer server 42, thereby improving viewing performance. In addition, the proxy server 42 ensures that the cached image 48 is new by sending a request to the peer-to-peer server 42 to check whether the requested image 48 has been modified since it was cached. This is achieved by comparing the timestamp 50 of the cached image 48with the timestamp 50 of the image 40 stored on the peer-to-peer server 42. If the comparison of the timestamps indicates that the image 48 on the peer-to-peer server 42 has been modified, the peer-to-peer server 42 transmits the modified image to the proxy server 42 before the proxy server 42 provides the image to the requester.

[0023] By caching the image 48 on the proxy server 40, the present invention significantly reduces the transmission of the image 40 from the peer-to-peer server 42 to the proxy server 40 along the path (C) to meet the needs of each image request, thereby improving The viewing performance of the network is improved. Although a small amount of data is transferred between the proxy server 40 and the peer-to-peer server 42 in order to determine whether the proxy cache 52 is still new, this communication volume is often only a few bytes, compared to this for each image On request, it takes several kilobytes or several megabytes to transfer the image 40 from the peer-to-peer server 42 to the proxy server 40.

[0024] FIG. 3 is a flowchart illustrating a process for improving guest viewing performance of images stored on a peer-to-peer server in a picture sharing peer-to-peer network. Referring to FIGS. 2 and 3 at the same time, the process starts at step 60, when the visitor computer 32 sends a request to view the image 48 stored in the peer-to-peer server 42. The request is routed to the proxy server 40 via path (A). In step 62, the proxy server 40 checks whether a copy of the image 48' is stored in the cache 52 via the path (E). If the copy of the image 48' is not stored in the cache (cache miss), this may occur when the image is requested for the first time, then in step 64, the proxy server 40 will request the image via path (B) Send to a peer-to-peer server 42 hosting the requested image 48.

[0025] In step 68, the peer-to-peer server 42 retrieves the image 48 and transmits a copy of the image 48 to the proxy server 40 via path (C). In step 70, a copy of the image 48' is stored in the cache 52. In step 72, the proxy server 40 retrieves the cached image 48 via the path (F) and provides it to the requesting computer 32 via the path (E). In a preferred embodiment, the proxy server 40 streams the image 48' to the visiting computer 32 while downloading the image 48' from the peer-to-peer server 42, to further reduce the waiting time between the time of sending the request and the time of returning the image. .

[0026] Referring again to step 62, if there is an image 48 in the cache 52 (a cache hit), then in step 74, the proxy server 40 sends the cached image 48' to the peer server 42 via path time Stamp 50' request to determine whether the cached image 48' is still new, where the request is in the form of a standard HTTP "If-Modified-Since (whether it has been modified since time) header. In step 76, correct The peer-to-peer application 44 on the peer-to-peer server 42 compares the timestamp 50' of the cached image 48' with the timestamp 50 of the image 40 stored on the peer-to-peer server 42. If the time stamp of the image 48 stored on the peer-to-peer server 42 is If the timestamp 50 is different from (ie later than) the timestamp 50' of the cached image 48', the peer-to-peer server 42 determines that the image 48 on the peer-to-peer server 42 has been modified since it was cached. In step 68 In response, the peer-to-peer server 42 returns a copy of the image 48 via path (C).

[0027] If the peer-to-peer server 42 determines that the image 48 it has stored locally does not have a timestamp 50 that is later than the timestamp 50 sent by the proxy server 40 in step 76, then in step 78, the peer-to-peer server 42 acts as The response sends a 304 HTTP return code to the proxy server 40 via path (C) to indicate that the image has not been modified. The proxy server 40 then retrieves the image 48 from the cache 52 via the path (F), and provides it to the visiting computer 32 via step 72 via the path (D).

[0028] Over time, the peer-to-peer server 42 will be disconnected from the proxy server 40, especially in a home environment where users often turn off PCs they are not using. In this case, the proxy server 40 cannot communicate with the peer server 42 to determine whether the image 48 in the cache 52 is still valid. Therefore, before the peer-to-peer server 42 goes offline, the proxy server 40 needs an updated set of the latest images and the Web page components surrounding those images.

[0029] According to another aspect of the present invention, it is processed by a synchronization server 54 (FIG. 2) and a synchronization protocol. Referring to FIGS. 2 and 3 at the same time, in operation, the user can initiate a synchronization protocol between the peer server 42 and the synchronization server 54 in step 80 before disconnecting the peer server 42. In a preferred embodiment, the user interface of the peer node 44 displays peer-to-peer synchronization icons or menu items that the user can select. Alternatively, the user can be prompted to perform synchronization, where the user can choose to accept or decline the prompt.

[0030] Once synchronization is invoked, in step 82, the peer-to-peer server 42 uploads the time stamp 50 of all images 48 to the synchronization server 54 via path (C). In step 84, the synchronization server 54 compares the uploaded timestamp 50 with the timestamp 50' to determine whether the cached image 48 is the latest, and whether there are any missing images in the cache 52. In step

In step 86, the synchronization server 54 sends a request to the peer-to-peer server 42 for any images identified as modified or missing. In step 68, the peer-to-peer server 42 retrieves the requested image 48 and transmits it to the proxy server 40 via path (C).

[0031] In a preferred embodiment, synchronization is performed immediately upon user request. However, in alternative embodiments, synchronization can be performed automatically in the background. That is, the proxy server 40 can be synchronized with the peer-to-peer server 42 while the proxy server 40 provides images to the visiting computer 32. In this embodiment, synchronization can be performed when the peer-to-peer server 42 establishes a connection to the proxy server 40 for the first time. It is also possible to perform background synchronization when it is detected that the connection to the peer-to-peer server is idle. In either of the two background synchronization forms, until the user closes the peer-to-peer server 42 after the active conversation, the synchronization with the proxy server 44 may be completed.

[0032] In the preferred embodiment, the synchronization server 54 is a component of the proxy server 40. However, the synchronization server 54 can be separated from the proxy server 40 and run on a separate computer.

[0033] As can be seen in the figure, when the image does not exist in the cache 52 (this is usually the case when the image is requested for the first time) and the image in the cache 52 needs to be updated, only the image from the path (C) The peer-to-peer server 42 transmits to the proxy server 40. However, when the image is not requested for the first time, the image will be stored in the cache 52. The only data passed between the peer server 42 and the proxy server 40 via path (C) is the HTTP return code, which is only a few bytes. , Rather than the megabytes used to transmit images. Due to this reduction in the amount of communication between the peer-to-peer server 42 and the proxy server 40, for visitors, the image viewing performance of the P2P network is significantly improved.

[0034] FIG. 4 is a flowchart illustrating a process in which the peer-to-peer server 42 registers with the picture-sharing peer-to-peer network 22 to make its service capabilities accessible through the firewall 34. In a preferred embodiment, the P2P network 22 includes a plurality of proxy servers 40a-n (commonly referred to as a proxy server array 40), a peer-to-peer server table 70, a registration server 72, and a DNS server 74.

[0035] The registration process starts in step 100, where the peer node 44 passes its name to the registration server 72, the registration server 72 performs a check to ensure that the peer name is unique, and returns the agent assigned to it to the peer node 44 The name and IP address of the server 40. In step 102, the peer node 44 registers its proxy server name and proxy server IP address to the DSN server 74. The DNS server 74 maintains a table of all peer names and their corresponding proxy IP addresses. In step 104, the peer node 44 assigns the name and socket registration of the peer server to its proxy server 40.

[0036] In step 106, the user of the visiting computer 32 is notified that there is content (such as a photo) on the peer-to-peer server 42 for viewing. This notification can be implemented using a variety of methods, but in a preferred embodiment, the user is notified by email, where the email contains the URL of the content in the peer-to-peer server 42. In step 108, the user visiting the computer 32 receives the e-mail and clicks on the URL. Using the peer name in the URL, the visiting computer 32 contacts the DNS server 74 to determine the identity of the proxy server 40 to send the request. The DNS server 74 responds with the IP address of the proxy server 40 assigned to the peer server 42. Given the proxy IP address, in step 110, the Web browser 30 of the visiting computer 32 sends an HTTP request to the proxy server 40.

[0037] FIG. 5 is a diagram illustrating the components of the proxy server 40 and a request for the Web browser 30, the proxy server 40, and the peer server 42 to enable the Web browser 30 to have HTTP access rights to the peer server 42 through the proxy server 40 Schematic diagram of the inter-process. In a preferred embodiment, the proxy server 40 includes a plurality of servlet threads 150, a registration manager 152, a peer-to-peer manager 154, a peer-to-peer message box 156, and a peer-to-peer group manager thread 158.

[0038] The process starts at step 200, when the servlet thread 150 in the proxy server 40 receives an HTTP request in the form of a URL from the web browser 30. In step 202, the registration manager 152 checks the server table 70 (see Figure

4) Determine whether to register the peer-to-peer server identified in the request URL to the peer-to-peer server 42, and if so, return the corresponding peer-to-peer socket. In step 204, the servlet thread 150 creates a peer-to-peer request packet 160 according to the HTTP request, and then passes the packet to the peer-to-peer manager 154.

[0039] FIG. 6A is a schematic diagram illustrating the content of a peer-to-peer request packet 160. In the preferred embodiment, the peer-to-peer request packet 160 includes a message box ID 162, an HTTP URL 164, a plurality of HTTP headers 166, and an HTTP Post data field 168. The message box ID 162 is a unique identifier for associating the peer-to-peer request group 162, the peer-to-peer response group 170, and the peer-to-peer message box 156. The HTTP URL 164 is a URL requested from the visiting Web browser 30. The HTTP header 166 is the HTTP header in the original request from the visiting Web browser 30. The HTTP Post data field 168 contains corresponding data when the request is a POST command instead of a GET command.

[0040] Referring again to FIG. 5, in step 206, the peer-to-peer manager 154 looks up the socket connection to the peer-to-peer server 42 and delivers the peer-to-peer request packet 160 to the peer-to-peer server 42. In step 210, the servlet thread 150 obtains the peer-to-peer message box 156 from the peer-to-peer manager 154 and blocks to wait for the response packet to arrive at the peer-to-peer message box 156.

[0041] In step 212, the peer node 44 receives the request packet 160, converts the packet 160 into an HTTP request, and sends the HTTP request to the Web server 28. In step 214, the HTTP response is sent from the Web server 28 to the peer node 44, and then the peer node 44 extracts the HTTP header from the response, creates a peer response packet 170, and sends it back to the proxy server 40. In step 216, the rest of the HTTP response is divided into 2K blocks and sent to the proxy server 40 in a continuous peer-to-peer response packet 170. In the preferred embodiment, the peer node 44 inserts a routing address into each peer response packet 170. Note that there may be multiple threads processing requests from the proxy server 40. Therefore, the peer node 44 multiplexes these responses back to the proxy server 40 on the same response socket.

[0042] FIG. 6B is a schematic diagram illustrating the content of a peer-to-peer response packet 170. In the preferred embodiment, the peer response packet 170 contains a message box ID 172, a packet size 174, a packet type 176, and a payload field 178. The message box ID 172 is a unique identifier for associating the peer-to-peer request packet 162, the peer-to-peer response packet 170, and the peer-to-peer message box 156. The packet size 174 relates to the response to the peer request packet 160 being sent back to the proxy server 40 in a block. In the preferred embodiment, a packet size of 2K is used. The various packets are reorganized on the proxy server 40 to form a completed HTTP response, and then the HTTP response is returned to the visiting Web browser 30. The packet type 176 indicates the type of data returned in the payload field 178. Possible values include: [data, header, last packet]. The payload field 178 is the data part of the peer response packet 170.

[0043] Referring again to FIG. 5, in step 218, the proxy server 40 receives raw bytes on the response socket and passes them to the peer group manager 158 thread selected from the thread pool. In a preferred embodiment, there is only one peer-to-peer packet manager thread in the proxy server 40 corresponding to each peer that actively receives the request 158. In step 220, the peer-to-peer packet manager thread 158 waits until there are complete packets in its buffer, and then routes the complete peer-to-peer response packet 170 to the corresponding peer-to-peer message box 156. When the packet 170 arrives at the peer-to-peer message box 156, the corresponding servlet thread 150 wakes up and retrieves the complete peer-to-peer response packet 170. In step 242, the servlet thread 150 converts the peer-to-peer response packet 170 back to an HTTP response, and then sends the HTTP response back to the requesting Web browser 30. As discussed herein, the combination of the proxy server 40 and the peer node 44 enables the visiting web browser 30 to make HTTP access to the peer server 42 behind the firewall 34.

[0044] The present invention is described in terms of illustrated embodiments, and those skilled in the art will readily recognize that many variations are possible to these embodiments. For example, although the preferred embodiment is described in connection with a Web-based peer-to-peer network, those skilled in the art will readily recognize that the same principles can be applied where the client computer does not use a proxy.

A conventional client-server environment in which the management server communicates directly with the peer-to-peer server. Any changes should fall within the spirit and scope of the present invention. Therefore, those skilled in the art can implement many modifications without departing from the spirit and scope of the appended claims.