Serving content from an off-line peer server in a photosharing peer-to-peer network in response to a guest request

A method and system for serving content from a peer server in a photosharing peer-to-peer network is disclosed, wherein the peer server stores a web album and at least one associated digital image. Aspects of the invention include prior to the peer server going off-line, the peer server initiates a synchronization with a proxy server and a guest content server in which the web page a web page descriptor defining the web album is copied from the peer server to the guest content server, and the image associated with the web album is copied from the peer server to the proxy server. In response to a request from a requesting computer to view content stored in the peer computer when the peer server is off-line, the request is fulfilled by forwarding the web page from the guest content server to the requesting computer, and forwarding the image associated with a web page from the proxy server to the requesting computer, thereby successfully serving content from the peer server even when the peer server is off-line.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present invention is related to U.S. patent application Ser. No. 10/927,291, filed on Aug. 25, 2004, entitled “Proxy Caching In A Photosharing Peer-to-Peer Network to Improve Guest Image Viewing Performance”, assigned to the same assignee of the present application.

FIELD OF INVENTION

The present invention relates to sharing digital images over a network, and more particularly to a method and system for improving guest viewing performance of images stored on peer computers in a photosharing peer-to-peer network.

BACKGROUND OF THE INVENTION

Over the past several years, photosharing has become widely accepted by photo enthusiasts. Many websites currently exist that allow users to upload digital images to the site for storage on a server and for viewing by others over the Internet. Oftentimes, images are grouped to form an album web page so that the user can invite others to view the album web page, as opposed to each individual image.

This approach to photosharing, however, presents some disadvantages. In particular, users are required to upload digital images to the site, which can be time consuming, and the site requires extensive storage capacity to store the images of all the users, which can become expensive.

To address these concerns, the assignee of the present invention has developed a web-based peer-to-peer photosharing system in which all workstations and computers (peers) in the network store images locally and act as servers to other users on the network. A central site accessible by all the peers provides additional functionality, such as coordinating the peers, providing search capabilities for the peers, purchase order fulfillment, etc.

FIG. 1is a block diagram illustrating the web-based peer-to-peer photosharing system. The peer-to-peer photosharing system20includes a photosharing P2P network22, which comprises multiple peer servers24running peer node software26and web server software28. The peer node and server software24and26enable the users of the computers to share images with others in the network22through a web browser30without having to upload their pictures to a web site. A novel feature of the photosharing P2P network22is that it provides a hybrid peer-to-peer architecture for general HTTP/web browser configuration that incorporates a central proxy server36to coordinate networking traffic for peers behind firewalls, thus allowing access to peers behind firewalls by other peers and by visiting computers32not in the network22. The proxy server36provides supporting services to the peers24as well as providing a path through which the visiting computer32accesses images from the peer servers24via a standard web browser30. Allowing generic HTTP access to the images hosted on peer servers located behind firewalls becomes increasingly important as virtually all corporations use firewalls, and the use of software firewalls installed on user's home systems is becoming ubiquitous. As used herein, the peer servers24, proxy server36and the visiting computer32may comprise any computing device, such as PCs, workstations, mobile phones, and PDAs, with components necessary for executing the appropriate software. Also, in a preferred embodiment, the physical communications network is the Internet, although any type of network could be used.

Each peer24stores album web pages and associated images locally in a database. Each album web page is associated with a descriptor that includes information about the album, such as which images are included in the album and who is permitted to see the album. For example, if the album is private, only the owner is allowed to view the album; if the album is “public,” then everyone can access the album; and if the album is “restricted,” then the album is accessible only to selected users. In this case, the descriptor includes an access list. The descriptor for each album web page is stored in a database (not shown) in the peer24.

When a peer24receives a request (via the proxy server36) to access an album web page from either another peer24or a visiting computer32, the peer24accesses the database to retrieve the descriptor associated with the requested album web page. From the descriptor, the peer24determines whether the requester (e.g., peer user or user of the visiting computer) is permitted to access the album and which images are in the album web page. If the access is authorized, the peer24returns the album web page, which contains embedded images representing each of the album images.

Upon receipt of the album web page, the requestor's browser30interprets the web page and then initiates separate requests for each embedded image therein. When the peer24receives the request for the image, it accesses the database again to retrieve the descriptor for the album page in which the requested image resides to ensure: (1) that the requested image is actually in the associated album page; and (2) that the requestor has permission to access the album page and its contents, i.e., images.

One problem with routing images through the proxy server36is that it requires extra bandwidth. That is, the image must be moved twice; once from the peer server24to the proxy server36, and then a second time from the proxy server36to the visiting computer32. In addition, the path from the peer server24to the proxy server26generally has the longest latency because the peer server24is typically hosted in a user's home equipped with a cable modem or DSL that has an uplink speed much slower that the downlink speed. Thus, users may experience a significant delay when viewing images that are routed through the proxy server36due to the bandwidth limitations between the peer server24and the proxy server36.

In addition, because peer servers24may be hosted in a variety of environments and host computers, there may be situations where the network to which the peer server24belongs may go off-line or the peer server24needs to go offline for maintenance. It is also possible that the peer server24is a mobile system, such as a laptop or tablet PC, which goes in and out of network service. All of these issues would cause the peer server24to disconnect from the proxy server26and stop serving guest requests. In this situation, the requesting guest would fail to receive the requested content from the off-line peer server24.

Accordingly, there is need for a method and system for reducing the amount of network traffic between the peer server and the proxy server, and for serving content from a peer server regardless of whether the peer server is off-line in order to improve guest image viewing performance. The present invention addresses such a need.

BRIEF SUMMARY OF THE INVENTION

The present invention provides a method and system for serving content from a peer server in a photosharing peer-to-peer network, wherein the peer server stores a web album and at least one associated digital image. Aspects of the invention include prior to the peer server going off-line, the peer server initiates a synchronization process with a proxy server and a guest content server in which a web page descriptor defining the web album is copied from the peer server to the guest content server, and the image associated with the web album is copied from the peer server to the proxy server. In response to a request from a requesting computer to view content stored in the peer computer when the peer server is off-line, the request is fulfilled by forwarding the web page from the guest content server to the requesting computer, and forwarding the image associated with a web page from the proxy server to the requesting computer, thereby successfully serving content from the peer server even when the peer server is off-line.

DETAILED DESCRIPTION OF THE INVENTION

The present invention relates to sharing digital images over a network, and more particularly to a method and system for improving guest image viewing performance. The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the preferred embodiments and the generic principles and features described herein will be readily apparent to those skilled in the art. For example, although the preferred embodiment is in the context of a peer-to-peer network, the same principles can be applied to a client-server environment where the guest browser communicates directly with the computer system storing the album and images. Thus, the present invention is not intended to be limited to the embodiments shown but is to be accorded the widest scope consistent with the principles and features described herein.

The present invention provides a method and system for improving the viewing performance of a peer-to-peer photosharing network in which peer servers store their user's images and are coupled to at least one photosharing system server, such as a proxy server.

FIG. 2is a detailed block diagram of an improved photosharing network according to a preferred embodiment of the present invention. Besides the components shown inFIG. 1A, each peer server42includes a peer node application44that functions according to the preferred embodiment, and a database46of web albums56and associated digital images48. The peer node software42also includes a guest service component64for fulfilling guest request to view content, such as web albums56from the peer server42. The database46is typically stored on a hard drive of the hosting computer system, and the images48are typically given a timestamp50by the host operating system that indicates the date of creation or modification date, as is well-known in the art.

Each web album56may include one or more web pages and is associated with a descriptor58that includes information about the state of the peer and the web pages comprising the web albums. The descriptor58may include an identification of the peer server42, the number and identity of the images48included in the web pages, access privileges for the album and for each image48therein, and any metadata that is not stored in the images48. The access privileges may indicate whether the album56is private, public, or restricted. If the album56is “private,” then only the owner is allowed to view the album; if the album56is “public,” then everyone can access the album56; and if the album56is “restricted,” then the album56is accessible only to selected users. In this case, the descriptor58includes an access list. The descriptor58for each web album56is stored in the database46in the peer42. In an alternative embodiment, the database46may maintain a descriptor50for each web page in the album56.

The proxy server40acts as a proxy for the distributed peer servers42, which have a pre-established connection to the proxy server40. The proxy server40enables a firewall-protected peer server42to enable incoming generic HTTP access by establishing an outbound connection from the firewall-protected peer server42with the proxy server40. Incoming Web traffic for the firewall-protected peer server42is then directed to the proxy server40. The proxy server40multiplexes the Web traffic using a proprietary protocol to the peer server42, thus enabling generic web traffic to flow to the peer server42despite the presence of a firewall (not shown). In the case where there are multiple firewall-protected peer servers42, the proxy server40acts as a switchboard to receive and dispatch the incoming HTTP requests to the appropriate peer servers42. The process for providing Web browsing through a firewall in a peer-to-peer network is described further detail with respect toFIGS. 7 through 9B. As used herein, the peer servers24, proxy server40and the visiting computer32may comprise any computing device, such as PCs, workstations, mobile phones, and PDAs, with components necessary for executing the appropriate software. Also, in a preferred embodiment, the physical communications network is the Internet, although any type of network could be used.

According to the preferred embodiment, images48stored on the peer server42that are requested for viewing by a visiting computer32, are stored in a cache52on the proxy server40either before or after the first time the image is requested. In addition, the peer-to-peer photo sharing network is provided with a guest content server62that is coupled to both the proxy server40and the peer server42. The purpose of the guest content server62is provided with the same guest service component60run the peer server42so that the guest content server62can fulfill requests to view content on the peer server42when the peer server42is unavailable. Although the preferred embodiment shown inFIG. 2shows the proxy server40and the guest content server62as separate computers, the functionality of the proxy server40and the guest content server62may be implemented on the same computer.

FIG. 3is a flow diagram illustrating the process for content from a peer server in a photosharing peer-to-peer network in accordance with a preferred embodiment. Referring to bothFIGS. 2 and 3, the process begins in step90by synchronizing the peer server42with the proxy server40and the guest content server62prior to the peer server42going off-line. As used herein, the synchronization process includes two steps, steps92and94. In step92, the guest functionality of the peer server42is reproduced on the guest content server62by copying on the guest content server62, the guest service component60, the web albums56, and descriptors58from the peer server42. The guest content component60′ may only need to be loaded onto the guest content server62once (e.g., during initial configuration of the guest content server62), while the web albums56and descriptors58are copied to the guest content server62and stored in the database64each time the synchronization process is performed. In step94, the images48stored on the peer server42are copied to the proxy server40and stored in the cache52.

In response to a request from a visiting computer32to view content stored in the peer server42via the proxy server40, the request is fulfilled in step96by forwarding the web album56′ from the guest content server62to the visiting computer32, and by forwarding the images48′ associated with the web album56′ from the proxy server40to the visiting computer32, thereby successfully serving content from the peer server42even when the peer server42is off-line, while also increasing viewing performance.

FIG. 4is a flow diagram illustrating the synchronization process between the peer server42, the proxy server40, and the guest content server62. The synchronization process is initiated by the peer server42prior to the peer server42going off-line, and is preferably performed as a background process. The synchronization process begins in step90in which the peer server42uploads the peer state information to the guest content server62, including the web album descriptors58and the web albums56. In step92the guest content server62replicates the peer state in its database64, resulting in the storage of web albums56′ and web album descriptors58′. In step94, the peer server42initiates synchronization with the proxy server40in which new and/or modified images48from the peer server42are copied to the proxy server40. In step96, the proxy server40saves the new and/or modified images48in the cache52. This proxy caching process is described in further detail with respect toFIG. 6.

FIG. 5is a flow diagram illustrating the process for serving content from a peer server42when the peer server42is off-line online. The process begins in step150when a visiting computer32or guest submits via an industry standard browser30a request (URL) to view content on the peer server42via the proxy server40that the URL for the peer server42resolves to. In step151, rather than automatically forwarding the request to the peer server42, the proxy server44first determines if the peer server42is available or not, and whether the peer server42is also a subscriber to this off-line service. If the peer server42is online, then the proxy server40routes the request to the peer server42for normal fulfillment through the guest service component60. If the peer server42is off-line, but is not an off-line subscriber, then the proxy server40will send the browser30of the visiting computer32a “peer off-line” message. If the peer server42is both off-line and an off-line subscriber, then in step152the proxy server40routes the request to the guest content server62using a proprietary protocol. A proprietary protocol is used to avoid HTTP which would result in a redirect and change the URL in the browser32the URL of the guest content server62.

In step154, when the guest content server62receives the request to access an album56from the peer server42, the guest service component60′ accesses the database64to retrieve the descriptor58′ associated with the requested album56′. From the descriptor58′, the guest service component60′ determines whether the requester (e.g., user of the visiting computer) is permitted to access the album56′ and which images48′ are in the web album pages. If the access is authorized, then the guest service component60′ retrieves from the database64captions, order information, and links to embedded images, and constructs the requested web album56′. In step156, the guest service component60′ returns to the proxy server40the constructed web album.

In step158, the proxy server40receives the constructed web album and pulls out the specified images48′ from the cache52. In step160the proxy server40returns the web album56′ and images40′ to the requesting browser30. In an alternative embodiment, the constructed web album is forwarded to the guest browser30, and the guest browser30makes request to the proxy server40for each of the images to be displayed in the web album.

According to a second aspect of the present embodiment, the proxy server42ensures that the images48′ in its cache52are fresh by sending a request to the peer server42to check whether a requested image48′ has been modified since being cached. This is accomplished by comparing the timestamp50′ of the cached image48′ with the timestamp50of the image40stored on the peer server42. If the comparison of the timestamps indicates that the image48on the peer server42has been modified, then the peer server42transfers the modified image to the proxy server42prior to the proxy server42serving the image to the requester.

By caching the images48′ on the proxy server40, the present invention significantly reduces the need to transfer the image40from the peer server42to the proxy server40along path (C) to satisfy each image request, thereby improving the viewing performance of the network. Although a small amount of data is transferred between the proxy server40and the peer server42in order to determine if the proxy's cache52is still fresh, this traffic is generally only a few bytes, as opposed to the kilobytes or megabytes required to transfer images40from the peer server42to the proxy server40for every image request.

FIG. 6is a flow diagram illustrating the process for improving guest viewing performance of images stored on peer servers in a photosharing peer-to-peer network. Referring to bothFIGS. 2 and 6, the process begins in step60when the visiting computer32issues a request to view the image48stored in the peer server42. The request is routed to the proxy server40via path (A). In step62the proxy server40checks if a copy of the image48′ is stored in the cache52via path (E). If the copy of the image48′ is not stored in the cache (a cache miss), which may occur the first time an image is requested, then in step64the proxy server40sends a request for the image to the peer server42hosting the requested image48via path (B).

In step68, the peer server42retrieves the image48and transmits a copy of the image48to the proxy server40via path (C). In step70, the copy of the image48′ is stored in the cache52. In step72, the proxy server40retrieves the cached image48′ via path (F), and serves it to the requesting visiting computer32via path (E). In a preferred embodiment, the proxy server40streams the image48′ to the visiting computer32while the image48′ is being downloaded from the peer server42to further reduce the latency between the time that the request is made and the image is returned.

Referring again to step62, if the image48′ is present in the cache52(a cache hit), the proxy server40determines if the cached image48′ is still fresh in step74by sending a request to the peer server42in the form of a standard HTTP “If-Modified-Since” header with the timestamp50′ of the cached image48′ via path (B). In step76, the peer node application44on the peer server42compares the timestamp50′ of the cached image48′ with the timestamp50of the image40stored on the peer server42. If the timestamp50of the image48stored on the peer server42is different (i.e., newer) than the timestamp50′ of the cached image48′, then the peer server42determines that the image48on the peer server42has been modified since the image was cached (stale cache). In step68, the peer server42returns a copy of the image48as a response via path (C).

If the peer server42determines that the image48it has stored locally does not having newer timestamp50than the timestamp50′ sent by the proxy server40in step76, then in step78, the peer server42sends a 304 HTTP return code to the proxy server40as a response indicating that the image has not been modified via path (C). The proxy server40then retrieves the image48′ from the cache52via path (F) and serves it to the visiting computer32via step72via path (D).

From time to time, the peer server42will become disconnected from the proxy server40, especially in home environments where users often shut down their PCs when not in use. In this case, the proxy server40cannot communicate to the peer server42to determine if the images48′ in the cache52are still valid. Therefore, the proxy server40needs an updated set of the most current images and web page components surrounding those images before the peer server42goes off-line.

According to a further aspect of the present invention, this is handled via the synchronization server54(FIG. 2) and a synchronization protocol. Referring to bothFIGS. 2 and 6, in operation, the user may initiate the synchronization protocol between the peer server42and the synchronization server54in step80prior to disconnecting the peer server42. In a preferred embodiment, the user interface of the peer node44displays a peer synchronization icon or menu item that the user may select. Alternatively, the user may be prompted to perform synchronization, which the user may choose to accept or declined.

Once synchronization is invoked, in step82the peer server42uploads the timestamps50of all the images48to the synchronization server54via path (C). In step84, the synchronization server54compares the uploaded timestamps50to the timestamps50′ to determine if the cached images48′ are current and whether there are any missing images in the cache52. In step86, the synchronization server54sends a request to the peer server42for any images identified as being modified or missing. In step68, the peer server42retrieves and transmits the requested images48to the proxy server40via path (C).

In a preferred embodiment, synchronization is performed immediately upon request by the user. However, in an alternative embodiment, synchronization may be performed automatically in the background. That is, the proxy server40may be synchronized with the peer server42at the same time the proxy server40is serving images to the visiting computer32. In this embodiment, synchronization may be performed when the peer server42first makes a connection to the proxy server40. Background synchronization may also be performed when it is detected that the peer server's connection is idle. In either form of background synchronization, by time the user shuts down the peer server42after an active session, synchronization with the proxy server44may be more than likely complete.

In a preferred embodiment, the synchronization server54is a component of the proxy server40. However, the synchronization server54may separate from the proxy server40and run on a separate computer.

As can be seen, an image is only transferred from the peer server42to the proxy server40via path (C) when it is not present in the cache52, which is typically the case the very first time the image is request, and when the image in the cache52needs to be updated. However, other than the first time the image is requested, the image will be present in the cache52, and the only data passed between the peer server42to the proxy server40via path (C) is the HTTP return code, which is only a few bytes, rather than megabytes to transfer the image. Due to this decrease in traffic between the peer server42to the proxy server40, image viewing performance of the P2P network for guests is significantly increased.

FIG. 7is a flow diagram illustrating the process of a peer server42registering with the photosharing peer-to-peer network22to make its serving capabilities assessable through a firewall34. In a preferred embodiment, the P2P network22includes several proxy servers40a-n, referred to collectively as proxy server array40, a peer server table70, a registration server72, and a DNS server74.

The registration process begins in step100, in which the peer node44passes its name to the registration server72, the registration server72checks to make sure that the peer name is unique, and returns to the peer node44the name and IP address of the proxy server40to which it is assigned. In step102, the peer node44registers its proxy server name and proxy server IP address with the DNS server74. The DNS server74maintains a table of all peer names and their corresponding proxy IP addresses. In step104, the peer node44registers the peer server's name and socket to proxy server40to which it was assigned.

In step106, a user of the visiting computer32is notified that content (e.g., photos) exists on the peer server42for viewing. The notification could be implemented using several methods, but in a preferred embodiment, the user is notified via e-mail, with the e-mail including the URL of the content in the peer server42. In step108, the user of the visiting computer32receives the e-mail, and clicks on the URL. Using the peer name in the URL, the visiting computer32contacts the DNS server74to determine the identity of the proxy server40in which to send the request. The DNS server74responds with the IP address of the proxy server40assigned to the peer server42. Given the proxy IP address, the web browser30of the visiting computer32sends an HTTP request to the proxy server40in step110.

FIG. 8is a diagram illustrating components of the proxy server40and the flow between the requesting web browser30, the proxy server40, and the peer server42to enable the web browser30to have HTTP access to the peer server42through the proxy server40. In a preferred embodiment, the proxy server40includes multipleservlet threads150, a registration manager152, a peer manager154, a peer MessageBox156, and a peer packet manager thread158.

The process begins in step200when the servlet thread150in the proxy server40receives the HTTP request in the form of a URL from the web browser30. In step202, the registration manager152checks the server table70(seeFIG. 4) to determine if the peer server identified in the requesting URL is registered with the peer server42, and if so, returns the corresponding peer socket. In step204, the servlet thread150creates a peer request packet160from the HTTP request and then passes that packet to the peer manager154.

FIG. 9Ais a diagram illustrating the contents of a peer request packet160. In a preferred embodiment, the peer request packet160includes a MessageBoxID162, an HTTP URL164, multiple HTTP headers166, and an HTTP Post Data field168. The MessageBoxID162is a unique identifier for correlating peer request packets162, peer response packets170, and peer message boxes156. The HTTP URL164is the URL that was requested from the visiting web browser30. The HTTP Headers166is the HTTP headers from the original request from the visiting web browser30. The HTTP Post Data field168contains data for when the request is a POST command, and not a GET command.

Referring again toFIG. 8, in step206, the peer manager154finds the socket connection to the peer server42and passes the peer request packet160to peer server42. In step210, the servlet thread150gets a peer MessageBox156from the peer manager154and blocks, waiting for response packets to arrive in the peer MessageBox156.

In step212, the peer node44receives the request packet160, converts the packet160back into an HTTP request, and sends the HTTP request to the web server28. In step214, an HTTP response is sent from the web server28to peer node44, which then takes the HTTP headers from the response, creates a peer response packet170, and sends it back to the proxy server40. The remaining portion of the HTTP response is broken up into 2K chunks in step216and sent to the proxy server40in successive peer response packets170. In a preferred embodiment, the peer node44inserts a routing address with each peer response packet170. Note that there can be several threads handling request from the proxy server40. Therefore, the peer node44multiplexes those responses over the same response socket back to the proxy server40.

FIG. 9Bis a diagram illustrating the contents of a peer response packet170. In a preferred embodiment, the peer response packet170includes a MessageBoxID172, a packet size174, a packet type176, and a payload field178. The MessageBoxID172is a unique identifyer for correlating peer request packets162, peer response packets170, and peer message boxes156. The packet size174has to do with the fact that the response to the peer request packet160is sent back to the proxy server40in chunks. A packet size of 2K is used in the preferred embodiment. The individual packets are reassembled on the proxy server40to form the complete HTTP response, which is then returned to the visiting web browser30. The packet type176indicates the type of data being returned in the payload field178. Possible values include: [data, header, final packet]. The payload field178is the data portion of the peer response packet170.

Referring again toFIG. 8, in step218, the proxy server40receives raw bytes over the response socket and passes them to a peer packet manager158thread selected from a thread pool. In a preferred embodiment, there is only one peer packet manager thread per peer that is actively receiving requests158in the proxy server40170. In step220, the peer packet manager thread158waits until there is a complete packet in its buffer, then routes the complete peer response packet170to the corresponding peer MessageBox156. When the packet170arrives in the peer MessageBox156, the corresponding servlet thread150wakes up and retrieves the complete peer response packet170. In step242, the servlet thread150converts the peer response packet170back into an HTTP response and then sends the HTTP response back to the requesting web browser30. As disclosed herein, a combination of the proxy server40and the peer node44enable HTTP access to a peer server42located behind a firewall34by a visiting web browser30.

In one embodiment, the present invention provides a peer server in a photosharing peer-to-peer network, where the peer server stores a web album and an associated digital image. In an embodiment, the present invention provides a computer readable medium having program instructions for, prior to the peer server going offline, synchronizing the peer server with a proxy server and a guest content server by copying a web page descriptor defining the web album from the peer server to the guest content server and copying an image associated with the web album from the peer server to the proxy server. In an embodiment, the computer readable medium also includes instructions for, in response to a request from a requesting computer to view content stored in the peer server when the peer server is off-line, fulfilling the request by forwarding the web album generated with the web page descriptor from the guest content server to the requesting computer via the proxy server, and forwarding the image associated with the web album from the proxy server to the requesting computer, thereby successfully serving content from the peer server even when the peer server is off-line.

The present invention has been described in accordance with the embodiments shown, and one of ordinary skill in the art will readily recognize that there could be variations to the embodiments. For example, while the preferred embodiment has been described in relation to a web-based peer-to-peer network, those skilled in the art would readily appreciate that the same principles can be applied to a conventional client-server environment where the client computer communicates directly with the peer server without utilizing the proxy server. Any variations would be within the spirit and scope of the present invention. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.