(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2003/0236905 A1
`(43) Pub. Date:
`Dec. 25, 2003
`Choi et al.
`
`US 20030236905A1
`
`(54) SYSTEM AND METHOD FOR
`AUTOMATICALLY RECOVERING FROM
`FAILED NETWORK CONNECTIONS IN
`STREAMING MEDIA SCENARIOS
`(75) Inventors: Yejin Choi, Bellevue, WA (US);
`Alexandre Grigorovitch, Redmond,
`WA (US); Troy Batterberry, Kirkland,
`WA (US)
`Correspondence Address:
`SENNIGER POWERS LEAVITT AND
`ROEDEL
`ONE METROPOLITAN SQUARE
`16TH FLOOR
`ST LOUIS, MO 63102 (US)
`(73) Assignee: Microsoft Corporation
`
`(21) Appl. No.:
`(22) Filed:
`
`10/179,583
`Jun. 25, 2002
`Publication Classification
`
`(51) Int. Cl." ..................................................... G06F 15/16
`(52) U.S. Cl. .............................................................. 709/231
`(57)
`ABSTRACT
`A System and method for automatically recover from broken
`network connections in Streaming media Scenarios. Server
`Software executing on the Server communicates with client
`Software executing on the client during the Streaming media
`Session. If the Streaming media Session is interrupted, the
`Server Software and the client Software exchange messages
`to associate the client with a client State Stored by the Server
`and to re-synchronize playback of the content.
`
`DO NOTATTEMPT
`TOAUTOMATICALLY
`RECONNECT THE
`CLEN
`210
`
`^ RESUME \
`224-sANs
`SY "Y
`
`EXTRECONNECTS
`PROCESSING |
`
`|
`212
`
`222
`
`218
`
`
`
`SUBMT LOGGING
`INFO FOR PREVIOUS
`STREAMING
`SEGMENT, AND
`RESET COUNT OF
`RECONNECT
`ATTEMPTS
`YES
`
`
`
`
`
`NETWORKING
`CODE
`/1 ENCOUNTERS AN
`2O2
`ERROR
`
`
`
`IS
`RECONNECT LOGIC
`SABLED
`
`YES
`
`CONNECTED TO
`A W3C SERVER
`
`
`
`
`
`204
`
`
`
`2O6
`
`
`
`
`
`HAS THE CENT
`SESSION PREVIOUSLY
`TREAMED FROM THE SERVE
`SUCCESSFULLY
`
`NO
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`/ SLEEP
`f BASED
`ENyes / ONTHE \
`HANDLED BY
`ALGORITHM,
`RECONNECT
`AND INCREMENT/
`\ COUNT OF /
`ANLOGIC
`\RECONNECT,
`/VariEMTs,
`24
`;
`216
`
`-
`
`!
`
`NITIATE
`RENT
`RECONNEC
`SSYER \sic ESSR
`PROTOCOL
`v
`
`g
`220
`
`NO
`
`DOES THE
`\ YES - NUMBER OF
`?t EXIT
`RECONNECT
`RECONNECTATEMPTS
`/ w PROCESSING
`EXCEED THE
`228
`LIMIT?
`
`
`
`NETFLIX, INC. EXHIBIT 1004
`
`

`

`Patent Application Publication Dec. 25, 2003 Sheet 1 of 7
`
`US 2003/0236905 A1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`|||NENOdWOO | |
`
`ELVIS
`
`ÅRHOLISOdE}}
`
`
`
`XèJO LISOdE}}
`
`ELVIS
`
`|NH|TO
`
`ILNENOdWOO
`
`||NENOdWOO
`
`NETFLIX, INC. EXHIBIT 1004
`
`

`

`Patent Application Publication Dec. 25, 2003 Sheet 2 of 7
`
`US 2003/0236905 A1
`
`/ ?NISSHOOHd(\ / | 1OHNNOOB, :,
`
`O
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`NETFLIX, INC. EXHIBIT 1004
`
`

`

`Patent Application Publication Dec. 25, 2003 Sheet 3 of 7
`
`US 2003/0236905 A1
`
`
`
`
`
`O
`
`D
`
`H
`
`f
`c
`
`S
`tra
`
`CY)
`
`g
`CD
`L
`
`NETFLIX, INC. EXHIBIT 1004
`
`

`

`Patent Application Publication Dec. 25, 2003 Sheet 4 of 7
`
`US 2003/0236905 A1
`
`FIG. 4
`
`
`
`402 N - N.
`. Has the N
`Server detected that
`Na client has disconnected
`N abnormally? -1
`
`403
`
`Conti
`stri.A. and
`Waiting for client
`Commands
`
`
`
`404 N
`
`Yes
`
`
`
`410 -
`
`
`
`No
`
`ACCept log
`information
`
`ls the
`- specific client
`N attempting to
`reconnect?
`
`P
`t
`OCeSS reCOneC
`Sequence of msgs
`from client
`N 408
`
`
`
`
`
`Pause client state
`and Cache client
`state in timeOut
`queue
`
`1
`N.
`Has client states No
`st timer expired? --
`Nu gy-
`Yes
`. /
`
`- 412
`
`Delete client
`State
`
`Log error
`
`414
`
`End processing for
`Specific session ID
`
`NETFLIX, INC. EXHIBIT 1004
`
`

`

`Patent Application Publication Dec. 25, 2003 Sheet 5 of 7
`
`US 2003/0236905 A1
`
`FIG. 5
`
`502 - -
`
`Client initiates
`areConnect
`using RTSP
`
`504 --
`
`Select stream
`with session ID
`and stream ID
`506 - IS N. NO
`1 Session ID is
`site:
`ve
`---
`> Does the N No
`508
`Stream ID
`match?
`YeS
`Server responds
`510 - say K
`SeeCtOn S
`was
`
`- V
`512-s Play command is
`submitted by client
`
`-
`
`Status log
`516-N information is
`Submitted
`
`518 -->
`
`--
`
`?o has successfully
`reconnected and has
`resumed at the rough
`point in the content where
`the disconnect OCCurred
`
`
`
`- - - ------
`Server
`responds
`E. eW
`Session and
`head
`neader
`information
`S-520
`
`522
`
`-- Client
`Submits new
`Select
`Stream
`Command
`
`
`
`
`
`524.
`
`Submit a
`DESCRIBE
`Command
`
`526 - Submit new Select
`Stream Command
`
`532
`
`
`
`530 - Streaming
`begins
`v.
`Client has successfully
`reconnected, but in the
`case of the on-demand
`Content, the Connection
`starts from the beginning
`of the Content
`
`
`
`
`
`
`
`NETFLIX, INC. EXHIBIT 1004
`
`

`

`Patent Application Publication Dec. 25, 2003. Sheet 6 of 7
`
`US 2003/0236905 A1
`
`
`
`
`
`
`
`
`
`Client initiates
`a reConnect
`using HTTP
`
`602
`
`
`
`Client Submits
`Select Stream
`COmmand,
`Session ID, and
`stream ID
`
`- sessin iDs No
`606 - N-1s Ys
`present gn
`Nserver
`Yes
`
`608
`
`Opoes the N No
`1 N.
`<
`Stream ID
`\ match?
`
`
`
`610
`
`Server responds
`indicating
`Selection is
`SUCCeSSful
`
`
`
`
`
`Y.
`Streaming begins
`
`
`
`t 618
`
`
`
`Server
`responds
`with new
`header
`information
`
`620
`
`622 -- DESEREE
`Command
`
`Client Submits
`Select stream and
`play Command
`in One message
`
`624 -
`
`
`
`
`
`
`
`Submit new Select
`stream Command
`and play
`Command in
`One meSSage
`
`
`
`Status log
`information is
`Submitted
`
`
`
`614
`
`
`
`Client has successfully
`reconnected and has
`resumed at the rough
`point in the Content where
`the disconnect OCCurred
`
`
`
`626 -
`
`
`
`Streaming
`begins
`
`628
`
`
`
`
`
`
`
`Client has successfully
`reCOnnected, but in the
`case of the on-demand
`Content, the Connection
`starts from the beginning
`of the Content
`
`NETFLIX, INC. EXHIBIT 1004
`
`

`

`Patent Application Publication Dec. 25, 2003 Sheet 7 of 7
`
`US 2003/0236905 A1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`871 SETmGOW|
`
`-|
`
`| | | | | !
`
`}
`
`| | | |
`
`
`
`9N|| WHECHO
`
`WELSÅS
`
`NETFLIX, INC. EXHIBIT 1004
`
`

`

`US 2003/0236905 A1
`
`Dec. 25, 2003
`
`SYSTEMAND METHOD FOR AUTOMATICALLY
`RECOVERING FROM FAILED NETWORK
`CONNECTIONS IN STREAMING MEDIA
`SCENARIOS
`
`TECHNICAL FIELD
`0001. The present invention relates to the field of stream
`ing media. In particular, this invention relates to a System
`and method for automatically recovering from failed net
`work connections in Streaming media Scenarios.
`
`BACKGROUND OF THE INVENTION
`0002 Content streaming includes the streaming of audio,
`Video, and/or text data from a network Server to a client
`computer on an as-needed basis. The client computer ren
`ders the data as it is received from the network server. For
`example, audio, Video, or audio/visual coverage of notewor
`thy events can be broadcast with Streaming multimedia over
`a network Such as the Internet as the events unfold. Simi
`larly, television and radio Stations can transmit live content
`over the network as Streaming multimedia.
`0.003 Streaming media over diverse networks poses a
`variety of technical challenges. The network connection
`between the server and the client is often subject to adverse
`conditions Such as congestion, packet loSS, varying laten
`cies, IGMP/ICMP errors, rebooting routers or other net
`working devices, rebooting servers, inadvertent reset of TCP
`connections, lost modem connections, and temporarily
`unplugged network cables. Depending on the severity of the
`issue, Some Streaming media players encounter Such adverse
`conditions and Subsequently post a critical error to the user
`interface. The error is critical in that the user must manually
`intervene and re-establish the Streaming Session. Unfortu
`nately, in the case of on-demand content, this also means the
`user must manually Seek to the position in the content that
`was last being viewed, if Seeking in the content is allowed,
`after the connection is re-established. Further, when this
`Streaming link is disconnected, all the clients and Servers
`that are downstream from the disrupted connection are
`terminated. The abnormal termination of all downstream
`clients can result in Significant lost revenue.
`0004 For these reasons, a system for automatically
`recovering from a failed Streaming media Session is desired
`to address one or more of these and other disadvantages.
`
`SUMMARY OF THE INVENTION
`0005 The invention includes a method of streaming
`media content from a server to at least one client. In
`particular, the invention includes Server Software executing
`on the Server communicating with client Software executing
`on the client. If the Streaming is interrupted, the Server
`Software and the client Software exchange messages to
`re-map a State of the client and re-synchronize playback of
`the content.
`0006 The invention addresses network problems expe
`rienced between the client(s) and the server. In addition, the
`invention addresses network problems experienced by
`Server-to-Server and encoder-to-Server distribution Sce
`narios, where the Server is actually a client Streaming from
`another source. The Software of the invention allows a
`Streaming media client player to automatically attempt to
`
`recover from a variety of connection problems with a server
`without user intervention. Furthermore, the invention Soft
`ware allows the client playing on-demand media to continue
`after re-connection at roughly the same point in the media
`program when the connection was lost. The client network
`ing code uses the Software of the invention to act upon
`unexpected errors that are not the direct action of an admin
`istrator. The invention includes Software on both the server
`and the client as well as Software for a protocol-specific
`implementation using real-time streaming protocol (RTSP)
`and hypertext transfer protocol (HTTP).
`0007 With the invention, servers can withstand longer
`network outages without terminating clients. The invention
`improves the end-user experience by preventing the user
`from having to manually recover from connectivity prob
`lems. The fault tolerant functionality improves the end user
`experience for Streaming media by more closely mimicking
`other content delivery metaphorS Such as television, radio,
`Video cassette recorders, digital versatile disk players, etc.
`0008. In accordance with one aspect of the invention, a
`method streams media content from a Server to at least one
`client. The method includes establishing a streaming media
`connection between the Server and the at least one client and
`Streaming the media content from the Server to the client.
`The method further includes receiving, by the client, the
`streamed media content from the server. The method
`includes Sending a reconnect request from the client to the
`Server if the Streaming is interrupted. The method also
`includes receiving, by the Server, the reconnect request from
`the client and re-establishing the Streaming media connec
`tion with the client. The method includes continues with the
`Server Streaming the media content and the client receiving
`the Streamed media content.
`0009. In accordance with another aspect of the invention,
`a method Stream media content to at least one client. The
`method includes establishing a streaming media connection
`with at least one client and Streaming the media content to
`the client. The method also includes receiving a reconnect
`request from the client if the Streaming is interrupted. The
`method further includes re-establishing the Streaming media
`connection with the client and continuing to Stream the
`media content.
`0010. In accordance with yet another aspect of the inven
`tion, a method receives media content Streamed from a
`Server. The method includes establishing a streaming media
`connection with the Server and receiving the media content
`streamed from the server. The method also includes trans
`mitting a reconnect request to the Server if the receiving is
`interrupted. The method further includes re-establishing the
`Streaming media connection with the Server and continuing
`to receive the Streamed media content.
`0011. In accordance with yet another aspect of the inven
`tion, one or more computer-readable media having com
`puter-executable components in a System wherein a Server
`Streams media content to at least one client. The components
`include a Server component and at least one client compo
`nent. The Server component and the client component
`include computer-executable instructions for exchanging
`one or more messages to re-map the State of the client and
`to re-synchronize playback of the content if the Streaming is
`interrupted.
`0012. In accordance with yet another aspect of the inven
`tion, one or more computer-readable media Store a data
`
`NETFLIX, INC. EXHIBIT 1004
`
`

`

`US 2003/0236905 A1
`
`Dec. 25, 2003
`
`Structure representing a reconnect request transmitted by a
`client to a Server to re-establish an interrupted Streaming
`media Session. The data Structure includes a Session identi
`fier identifying the interrupted Streaming media Session and
`a stream identifier identifying a media Stream Streamed by
`the Server to the client in the interrupted Streaming media
`Session.
`0013 Alternatively, the invention may comprise various
`other methods and apparatuses.
`0.014. Other features will be in part apparent and in part
`pointed out hereinafter.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0.015
`FIG. 1 is an exemplary block diagram illustrating
`a streaming media Scenario.
`0016 FIG. 2 is an exemplary flow chart illustrating
`operation of client component autoreconnect Software of the
`invention.
`0017 FIG. 3 is an exemplary block diagram illustrating
`a client Sending a reconnect request to a server.
`0.018
`FIG. 4 is an exemplary flow chart illustrating
`operation of Server component autoreconnect Software of the
`invention.
`0019 FIG. 5 is an exemplary flow chart illustrating the
`interaction between the client and the Server during recon
`nection via a real-time Streaming protocol.
`0020 FIG. 6 is an exemplary flow chart illustrating the
`interaction between the client and the Server during recon
`nection via a hypertext transfer protocol.
`0021
`FIG. 7 is a block diagram illustrating one example
`of a Suitable computing System environment in which the
`invention may be implemented.
`0022 Corresponding reference characters indicate corre
`sponding parts throughout the drawings.
`
`DETAILED DESCRIPTION OF THE
`INVENTION
`0023 Software of the invention provides a mechanism
`for automatically re-connecting a streaming Server with a
`client if Streaming is interrupted during a streaming media
`session as illustrated in FIG. 1. This invention includes
`Software executing on both the client and one or more
`Servers. In particular, the invention includes Server Software
`executing on the Server communicating with client Software
`executing on the client. If the Streaming is interrupted, the
`Server Software and the client Software exchange messages
`to re-map a State of the client and re-synchronize playback
`of the content.
`0024.
`Referring to FIG. 1, an exemplary block diagram
`illustrates a streaming media Scenario. The invention Soft
`ware is operable in a System having an optional encoder 102,
`an origin server 104, one or more downstream servers 106
`Such as downstream Server #1 through downstream Server
`#N, an edge server 108, and one or more clients 110 such as
`client #1 through client #M. The origin server 104, the
`downstream servers 106, and the edge server 108 each
`execute a Server Software component 112 while the clients
`110 execute a client software component 114. The server
`
`component 112 and the client component 114 include com
`puter-executable instructions for exchanging one or more
`messages to re-map the State of the client 110 and to
`re-synchronize playback of the content if the Streaming is
`interrupted. Separate State repositories 118 Such as a State
`repository Stored by the origin Server 104, a State repository
`stored by the downstream servers 106, and a state repository
`stored by the edge server 108 store a state of the downstream
`server 106 or client 110. For example, the edge server 108
`stores a state of the client 110. In addition, each of the
`downstream servers 106 and the origin server 104 store a
`State for downstream Servers acting as clients. For example,
`the downstream Server #1 Stores a State of the edge Server
`108. Similarly, the origin server 104 stores a state of the
`downstream server #N.
`0025 The origin server 104 is the first server the content
`flows through on the way to the client 110. The origin server
`104 generally receives content from either a file system 116
`at 120 or a feed from the encoder 102 at 122. The encoder
`102 stores the encoded content in the file system 116 at 124.
`If the origin server 104 receives content from the encoder
`102, the file system 116 may be bypassed, or the encoded
`content may be concurrently stored in the file system 116 at
`124. The downstream servers 106 generally receive data
`from the origin server 104. In complex distribution scenarios
`involving multiple levels of Servers, the downstream Servers
`106 may receive and forward content from another server
`that is sourcing content from the origin server 104. Since the
`data flows from the origin server 104 to the client 110, a
`Server is considered downstream from previous Servers. The
`edge server 108 is generally the last server in a distribution
`scenario. The edge server 108 is downstream from all other
`servers in the distribution chain. The edge server 108 is
`intended to have direct client connections. For clarity and
`simplicity, the edge server 108 will be referred to herein as
`server 108, noting that the invention is operable with any
`configuration and/or number of servers 104,106, 108.
`0026. In addition, the edge server 108 maintains a state
`repository Storing a client viewer State of each of the clients
`110 (e.g., Storing logging Statistics). The clients 110 transmit
`their states to the edge server 108 for storage. The state of
`each client 110 is maintained for a preset time period after
`a network failure or other interruption in the Streaming.
`0027. In one embodiment, the origin server 104 streams
`the media content from the file system 116. In an alternative
`embodiment, the encoder 102 also executes the server
`component 112 to stream content to the origin server 104 as
`it is encoded. In such an embodiment, the file system 116
`may be bypassed, or the encoded content may be concur
`rently stored in the file system 116. Those skilled in the art
`will appreciate that the invention is not limited to the
`exemplary block diagram of FIG. 1. Instead, it is contem
`plated by the inventors that the Software of the invention is
`operable in various other client-Server Streaming media
`Scenarios not Specifically described herein.
`0028. The clients 110 may render or otherwise display or
`process the received content via a media player user inter
`face (UI). Clients 110 receiving streamed media content for
`long periods of time often encounter a variety of network
`problems that result in the Server-to-client connection or
`Session being lost. With other Systems, a lost connection
`requires user intervention to re-establish the link. With the
`
`NETFLIX, INC. EXHIBIT 1004
`
`

`

`US 2003/0236905 A1
`
`Dec. 25, 2003
`
`Software of the invention, the clients 110 and the servers 108
`attempt to automatically reconnect. If the server 108 was
`Streaming Stored content (e.g., from a computer-readable
`medium) prior to the session failure, the client 110 can
`resume playback at the location in the Stream when the
`failure occurred using Statistics Saved prior to the failure. If
`the server 108 was streaming live content (e.g., directly from
`the encoder 102) prior to the session failure, the client player
`UI may not receive and render the content that was Streamed
`during the reconnection process. If the reconnection proceSS
`occurred relatively quickly, the server 108 may have buff
`ered a small amount of the live content, and will deliver that
`buffered content to the client 110 if reconnection is Success
`ful. AS Such, a user may experience minimal disruption in
`the playback.
`0029. In one embodiment, communication between the
`servers 108 and client 110 in FIG. 1 is implemented using
`a real-time streaming protocol (RTSP) and a Session descrip
`tion protocol (SDP). RTSP, as described in the Internet
`Engineering Task Force (IETF) RFC 2326, the entire dis
`closure of which is incorporated herein by reference, is an
`application-level protocol for control of the delivery of data
`with real-time properties. RTSP provides an extensible
`framework to enable controlled, on-demand delivery of
`real-time data, Such as audio and Video. Sources of data can
`include both live data feeds and stored clips. This protocol
`is intended to control multiple data delivery Sessions, pro
`vide a means for choosing delivery channels. Such as a user
`datagram protocol (UDP), a multicast UDP and a transmis
`Sion control protocol, and provide a means for choosing
`delivery mechanisms based upon a real-time transport pro
`tocol.
`0.030. For example, the Real-time Transport Protocol
`(RTP), as described in the IETF RFC 1889, the entire
`disclosure of which is incorporated herein by reference,
`provides end-to-end network transport functions Suitable for
`applications transmitting real-time data, Such as audio, Video
`or Simulation data, over multicast or unicast network Ser
`vices. RTP does not address resource reservation and does
`not guarantee quality-of-Service for real-time Services. The
`data transport is augmented by a control protocol (RTCP) to
`allow monitoring of the data delivery in a manner Scalable
`to large multicast networks, and to provide minimal control
`and identification functionality. RTP and RTCP are designed
`to be independent of the underlying transport and network
`layers.
`0031) SDP, as described in the IETF RFC 2327, the entire
`disclosure of which is incorporated herein by reference, is an
`application level protocol intended for describing multime
`dia Sessions for the purposes of Session announcement,
`Session invitation, and other forms of multimedia Session
`initiation. SDP can be used in conjunction with RTSP to
`describe and negotiate properties of the multimedia Session
`used for delivery of real-time data.
`0.032 The invention software supports automatic recon
`nection logic 112, 114 for various protocols such as HTTP
`(see FIG. 6), RTSP (see FIG. 5), and any proprietary
`protocols in the client component 114 and the Server com
`ponent 112. The invention software also logs the first
`Segment of information received following a Successful
`reconnect (e.g., as a status code of 210). The invention
`Software Supports broadcast and on-demand modes of opera
`
`tion. The automatic reconnection logic 112, 114 can be
`tuned/disabled in the server 108 (e.g., to act as a distribution
`client) and in the client 110. The invention software staggers
`the client reconnect attempt requests over time to prevent the
`server 108 from being overwhelmed by thousands of simul
`taneous reconnect requests. The reconnecting client 110 is
`authenticated and authorized if corresponding Security is
`enabled. The reconnecting client 110 resumes at the same
`point of a Seekable on-demand playlist element. In one
`embodiment, the server 108 maintains a client viewer state
`if data has actually been Streamed. This check increases the
`difficulty of developing a denial of Service attack. A discon
`nection resulting from a client inactivity timeout on the
`server 108 does not result in an error immediately displayed
`on the client 110. Instead, the client 110 attempts to re-open
`the file at the beginning of the playlist once play is pressed.
`In one embodiment, a Seek is not possible because the client
`viewer state on the server 108 for the previous connection
`will no longer be present. In embodiments lacking a client
`viewer state present on the server 108, seeking to the
`previous playlist entry element in a Server-side playlist may
`be disabled. An error displays on the client 110 if the re-open
`attempt is unsuccessful.
`0033. In one embodiment, the invention Software does
`not attempt to automatically reconnect when an administra
`tor for the server 108 terminates a connection, when the
`Server 108 denies acceSS due to an authentication failure,
`when playing content from a web server, or when the Server
`108 denies access due to an authorization failure.
`0034). In operation, client 110 and server 108 computers
`Such as computer 130 execute computer-executable instruc
`tions such as those illustrated in FIG. 2 and FIGS. 4-6 to
`re-establish a streaming media connection between the
`Server 108 and the client 110. The server 108 Streams the
`media content to the client 110. The client 110 receives the
`streamed media content from the server 108. If the streaming
`is interrupted, the client 110 Sends a reconnect request to the
`server 108. The server 108 receives the reconnect request
`from the client 110. The server 108 and the client 110
`re-establish the Streaming media connection. Re-establish
`ing includes the Server 108 mapping a reconnecting client
`110 with a state maintained by the server 108. Alternatively,
`re-establishing includes creating a new Session for Streaming
`if no maintained state corresponds to the client 110. The
`server 108 continues streaming the media content to the
`client 110 over the re-established Streaming media connec
`tion.
`0035) Client Component Software
`0036 Referring next to FIG. 2, an exemplary flow chart
`illustrates operation of client component autoreconnect Soft
`ware 114 the invention. The client component software 114
`acts upon unexpected errors at 202 that are not the direct
`action of an administrator. The client component Software
`114 operates if the client 110 has successfully streamed from
`the server 108 previously at 208 and the error is handled by
`reconnect logic 114 at 214.
`0037. If thousands of clients 110 attempt to auto-recon
`nect at exactly the same time, the server 108 may not be able
`to process any of them Successfully. Also, repeated recon
`nect attempts can tax the client's processor. Therefore, the
`Software of the invention spreads out the timing of the
`auto-reconnect requests by clients 110. To prevent all clients
`
`NETFLIX, INC. EXHIBIT 1004
`
`

`

`US 2003/0236905 A1
`
`Dec. 25, 2003
`
`110 from overwhelming a streaming media server 108 with
`a flood of reconnect requests at exactly the same time, the
`client 110 employs software to sleep at 216 between recon
`nect attempts. The Sleep duration involves a random com
`ponent to help spread reconnect requests when multiple
`clients 110 are disconnected at the same time. The sleep
`Software is also used to minimize the amount of client
`processing required to Successfully reconnect. For example,
`if a client 110 continuously reconnects while waiting for a
`router to reboot, it could adversely affect the client processor
`load. By delaying the transmission of the reconnect request
`to the server 108 for a preset time period between reconnect
`attempts, both the client 110 and the server 108 are opti
`mized. For example, the client software may wait for five
`Seconds between failed reconnect attempts and increment a
`reconnect counter for each attempt. In one embodiment, the
`client 110 attempts to reconnect twenty-five times before
`halting. That is, if the reconnect counter exceeds a preset
`threshold at 226, the client Software halts the reconnect
`attempt and logs an error at 228.
`0038. The number of attempts the client 110 retries to
`connect is fully configurable through a client application
`programming interface (API) and also a uniform resource
`locator (URL) modifier. A URL modifier allows a content
`provider or other encoder such as encoder 102 to control the
`number of reconnect attempts made by the client 110 so that
`it is appropriate for the environment. An example of the
`URL modifier follows.
`0039 mms://server/file.asfWMReconnect=15
`0040. In this example, the client 110 will attempt to
`reconnect fifteen times (e.g., at 218) before failing with an
`error. If the client software successfully reconnects with the
`server 108 at 220, logging statistics are sent to the server
`108, the reconnect counter is reset to zero at 222, and
`Streaming resumes at 224.
`0041. There are several mechanisms that trigger the client
`110 to attempt a reconnect. A network error detected from
`the local protocol Stack or the error Signal Sent by the Server
`108 or prolonged no data period (e.g., a starvation timeout)
`will potentially trigger the reconnect logic 114. If the error
`signal sent by the server 108 denotes that the server 108
`intended to disconnect the client 110 deliberately, the client
`110 will not attempt to reconnect. The client 110 will attempt
`to reconnect even in a paused State in order to maintain the
`client viewer status active at the server 108. The player code
`fires events to update the Status of the player user interface
`to indicate when the client 110 has started (and finished)
`reconnecting.
`0042. The client 110 does not attempt to automatically
`reconnect with the server 108 under various conditions Such
`as when the client component 114 and/or the Server com
`ponent 112 is disabled at 204. In one embodiment, the client
`110 does not attempt to automatically reconnect with the
`Server 108 when the server 108 is a World Wide Web
`Consortium server at 206. Under Such conditions, the client
`110 and the server 108 do not automatically reconnect at 210
`and reconnect processing exits at 212.
`0043. In a server distribution or a cache/proxy scenario
`where one Server is receiving content from the origin Server
`104, the downstream server 106 is essentially a client such
`as client 110 in that it is streaming content from the origin
`
`server 104. In this scenario, the downstream server 106 can
`employ auto-reconnect Software to connect back to the
`origin server 104 using software similar to the software 114
`used by the client 110.
`0044) Referring next to FIG. 3, an exemplary block
`diagram illustrates the client 110 Sending a reconnect request
`302 to the server 108 to re-establish an interrupted streaming
`media session. In the exemplary embodiment of FIG. 3, the
`reconnect request 302 is a data Structure including a stream
`identifier 306 and a session identifier 304. The session
`identifier identifies the interrupted Streaming media Session.
`For example, the Session identifier may be a 64-bit or a
`32-bit value generated by the server 108 and identifies the
`client-Server relationship. The Stream identifier identifies a
`media stream streamed by the server 108 to the client 110 in
`the interrupted Streaming media Session. For example, the
`stream identifier may be a 32-bit value generated by the
`server 108 to identify a particular stream in the media
`COntent.
`0045 Server Component Software
`0046 Referring next to FIG. 4, an exemplary flow chart
`illustrates operation of the Server component autoreconnect
`Software 112 of the invention. During the period in which
`the server 108 does not detect at 402 that the client 110 has
`disconnected abnormally, the server 108 continues stream
`ing at 403 and waiting for commands from the client 110. If
`the server 108 detects at 402 that the client 110 has discon
`nected abnormally, the server 108 employs a variety of
`mechanisms to allow the client 110 to reconnect. These
`mechanisms are described below.
`0047 The client 110 periodically transmits state data
`(e.g., logging statistics) to the server 108 for Storage. In
`addition, the server 108 tracks the status of each client
`viewer state and allows an administrator of server 108 to
`determine the state of any client 110. The state data includes
`a Session identifier and a Stream identifier corresponding to
`the current client-Server Session and the Streams being
`delivered, respectively. The server 108 pauses the client state
`and maintains the client viewer State for a pre-determined
`(e.g. configurable) duration or time period at 404. The client
`Viewer State may be Stored or cached in the State repository,
`a timeout queue, or the like. Since the client viewer State
`consumes server resources, the server 108 will not maintain
`the State indefinitely. After determining that the configurable
`duration expired at 405, the server 108 removes the client
`Viewer State at 412, frees the associated resources, logs an
`error at 414, and ends processing at 416 for the current
`Session. For example, logging an error at 414 includes the
`server 108 generating a log on behalf of the client 110
`because the reconnecting client 110 will not Submit a log
`(e.g., with status cod