Method and system for providing on-line interactivity over a server-client network

• US 20030088609A1
• Filed: 07/30/2002
• Published: 05/08/2003
• Est. Priority Date: 05/02/1997
• Status: Active Grant

• Current Assignee: CDN Innovations, LLC (IP Investments Group LLC)
• Original Assignee: MGI Software Corporation (MelodyVR Group Plc)
• Inventors: Guedalia, Isaac David, Guedalia, Jacob Leon, Hashkes, Jonathan
• Granted Patent: US 7,925,689 B2
• Time in Patent Office: Days
• US Class Current: 718/107
• CPC Class Codes: G06F 9/4843 by program, e.g. task dispatcher, supervisor, operating system
• CPC Class Codes: H04L 67/303 Terminal profiles
• CPC Class Codes: H04L 67/56 Provisioning of proxy services store-and-forward switching systems in data switching networks H04L12/54
• CPC Class Codes: H04L 67/567 Integrating service provisioning from a plurality of service providers
• CPC Class Codes: Y10S 707/99938 Concurrency, e.g. lock management in shared database

Abstract

Apparatus and a method for communicating media over a network including encoding the media into a server database at a server, downloading from the server database to a client database generally only those portions of the media which are necessary to satisfy user requests and in response to a user request for a given item of media, determining whether the media is present in the client database, and if not, automatically downloading those portions of the media which are necessary to supply the user with the given item of media from the server database. An image server is provided including at least one processor operative to supply portions of image data to clients in response to multiple requests therefrom, and thread management software operating the at least one processor by causing it to process the requests using at least one of a plurality of threads, the thread management software being characterized in that it initiates a new thread when an existing thread has exceeded a predetermined metric of busyness.

Claims

1. An image server comprising:

at least one processor operative to supply portions of image data to clients in response to multiple requests therefrom; and

thread management software operating said at least one processor by causing it to process said requests using at least one of a plurality of threads, said thread management software being characterized in that it initiates a new thread when an existing thread has exceeded a predetermined metric of busyness.

2. An image server according to claim 1 and wherein said thread management software is characterized in that it initiates a new thread only when an existing thread has exceeded said predetermined metric of busyness.

3. An image server according to claim 1 and wherein said thread management software operates a thread pool containing at least one of said plurality of threads.

4. An image server according to claim 3 and wherein said thread management software initiates a new thread when an existing thread in said thread pool has exceeded said predetermined metric of busyness.

5. An image server according to claim 3 and wherein said thread management software initiates a new thread only when an existing thread in said thread pool has exceeded said predetermined metric of busyness.

6. An image server according to claim 1 and wherein said thread management software is operative to open a socket connection for each new incoming request accepted by a thread for processing.

7. An image server according to claim 3 and wherein each existing thread can be in an active state or in a wait state.

8. An image server according to claim 7 and wherein threads belonging to said thread pool are characterized in that they enter said wait state upon completion of a client request, and are not destroyed.

9. An image server according to claim 3 and wherein at least one of said plurality of threads does not belong to said thread pool and is characterized in that it is destroyed upon completion of a client request.

10. An image server according to claim 3 and wherein all of the threads which do not belong to said thread pool are characterized in that they are destroyed upon completion of a client request.

11. An image server according to claim 3 and wherein said new thread is added to said thread pool.

12. An image server according to claim 3 and wherein if said existing thread belongs to said thread pool, said thread management software is operative to remove said existing thread from said thread pool when said existing thread has exceeded said predetermined metric of busyness.

13. An image server according to claim 1 and wherein each of said plurality of threads has an associated priority.

14. An image server according to claim 13 and wherein said thread management software lowers the priority of said existing thread when said existing thread has exceeded said predetermined metric of busyness.

15. An image server according to claim 1 and wherein said predetermined metric of busyness is a predetermined time duration measured during activity of a thread.

16. An image server according to claim 4 and wherein said predetermined metric of busyness is a predetermined time duration measured during activity of a thread.

17. An image server according to claim 1 and wherein said predetermined metric of busyness is a predetermined amount of disk access activity.

18. An image server according to claim 1 and wherein said predetermined metric of busyness is a predetermined amount of memory allocation.

19. An image server according to claim 15 and wherein said predetermined time duration is determined by incrementing ticks for each thread which is in an active state following initiation of its activity and at fixed time intervals.

20. An image server according to claim 15 and wherein said predetermined time duration is determined by incrementing ticks for each thread which is in an active state following initiation of its activity at fixed time intervals which are not measured from the onset of its activity.

21. An image server according to claim 16 and wherein said predetermined time duration is determined by incrementing ticks for each thread which is in an active state following initiation of its activity at fixed time intervals which are not measured from the onset of its activity.

22. An image server according to claim 15 and wherein said fixed time intervals are 50 msecs, and said predetermined time duration is the time expended until three ticks have been incremented.

23. An image server according to claim 1 and wherein said image data is FLASHPIX image data.

24. An image server according to claim 1 and wherein said multiple requests are Internet Imaging Protocol (IIP) requests.

25. A computer thread management system comprising:

at least one processor; and

thread management software operating said at least one processor by causing it to process requests using at least one of a plurality of threads, said thread management software being characterized in that it initiates a new thread only when an existing thread has exceeded a predetermined metric of busyness.

26. A computer thread management system according to claim 25 and wherein said thread management software is characterized in that it initiates a new thread only when an existing thread has exceeded said predetermined metric of busyness.

27. A computer thread management system according to claim 25 and wherein said thread management software operates a thread pool containing at least one of said plurality of threads.

28. A computer thread management system according to claim 27 and wherein said thread management software initiates a new thread when an existing thread in said thread pool has exceeded said predetermined metric of busyness.

29. A computer thread management system according to claim 27 and wherein said thread management software initiates a new thread only when an existing thread in said thread pool has exceeded said predetermined metric of busyness.

30. A computer thread management system according to claim 25 and wherein said thread management software is operative to open a socket connection for each new incoming request accepted by a thread for processing.

31. A computer thread management system according to claim 27 and wherein each existing thread can be in an active state or in a wait state.

32. A computer thread management system according to claim 31 and wherein threads belonging to said thread pool are characterized in that they enter said wait state upon completion of a client request, and are not destroyed.

33. A computer thread management system according to claim 27 and wherein at least one of said plurality of threads does not belong to said thread pool and is characterized in that it is destroyed upon completion of a client request.

34. A computer thread management system according to claim 27 and wherein all of the threads which do not belong to said thread pool are characterized in that they are destroyed upon completion of a client request.

35. A computer thread management system according to claim 27 and wherein said new thread is added to said thread pool.

36. A computer thread management system according to claim 27 and wherein if said existing thread belongs to said thread pool, said thread management software is operative to remove said existing thread from said thread pool when said existing thread has exceeded said predetermined metric of busyness.

37. A computer thread management system according to claim 25 and wherein each of said plurality of threads has an associated priority.

38. A computer thread management system according to claim 37 and wherein said thread management software lowers the priority of said existing thread when said existing thread has exceeded said predetermined metric of busyness.

39. A computer thread management system according to claim 25 and wherein said predetermined metric of busyness is a predetermined time duration measured during activity of a thread.

40. A computer thread management system according to claim 28 and wherein said predetermined metric of busyness is a predetermined time duration measured during activity of a thread.

41. A computer thread management system according to claim 25 and wherein said predetermined metric of busyness is a predetermined amount of disk access activity.

42. A computer thread management system according to claim 25 and wherein said predetermined metric of busyness is a predetermined amount of memory allocation.

43. A computer thread management system according to claim 39 and wherein said predetermined time duration is determined by incrementing ticks for each thread which is in an active state following initiation of its activity and at fixed time intervals.

44. A computer thread management system according to claim 39 and wherein said predetermined time duration is determined by incrementing ticks for each thread which is in an active state following initiation of its activity at fixed time intervals which are not measured from the onset of its activity.

45. A computer thread management system according to claim 40 and wherein said predetermined time duration is determined by incrementing ticks for each thread which is in an active state following initiation of its activity at fixed time intervals which are not measured from the onset of its activity.

46. A computer thread management system according to claim 39 and wherein said fixed time intervals are 50 msecs, and said predetermined time duration is the time expended until three ticks have been incremented.

47. An image server method comprising:

operating at least one processor for supplying portions of image data to clients in response to multiple requests therefrom including;

managing processing threads within said at least one processor, thereby causing said processor to process said requests using at least one of a plurality of threads, characterized in that a new thread is initiated when an existing thread has exceeded a predetermined metric of busyness.

48. A method according to claim 47 and wherein said managing step initiates a new thread only when an existing thread has exceeded said predetermined metric of busyness.

49. A method according to claim 47 and wherein said managing step operates a thread pool containing at least one of said plurality of threads.

50. A method according to claim 49 and wherein said managing step initiates a new thread when an existing thread in said thread pool has exceeded said predetermined metric of busyness.

51. A method according to claim 49 and wherein said managing step initiates a new thread only when an existing thread in said thread pool has exceeded said predetermined metric of busyness.

52. A method according to claim 47 and wherein said managing step includes opening a socket connection for each new incoming request accepted by a thread for processing.

53. A method according to claim 49 and wherein each existing thread can be in an active state or in a wait state.

54. A method according to claim 53 and wherein threads belonging to said thread pool are characterized in that they enter said wait state upon completion of a client request, and are not destroyed.

55. A method according to claim 49 and wherein at least one of said plurality of threads does not belong to said thread pool and is characterized in that it is destroyed upon completion of a client request.

56. A method according to claim 49 and wherein all of the threads which do not belong to said thread pool are characterized in that they are destroyed upon completion of a client request.

57. A method according to claim 49 and wherein said new thread is added to said thread pool.

58. A method according to claim 49 and wherein if said existing thread belongs to said thread pool, said managing step includes removing said existing thread from said thread pool when said existing thread has exceeded said predetermined metric of busyness.

59. A method according to claim 47 and wherein each of said plurality of threads has an associated priority.

60. A method according to claim 59 and wherein said managing step includes lowering the priority of said existing thread when said existing thread has exceeded said predetermined metric of busyness.

61. A method according to claim 47 and wherein said predetermined metric of busyness is a predetermined time duration measured during activity of a thread.

62. A method according to claim 50 and wherein said predetermined metric of busyness is a predetermined time duration measured during activity of a thread.

63. A method according to claim 47 and wherein said predetermined metric of busyness is a predetermined amount of disk access activity.

64. A method according to claim 47 and wherein said predetermined metric of busyness is a predetermined amount of memory allocation.

65. A method according to claim 61 and wherein said predetermined time duration is determined by incrementing ticks for each thread which is in an active state following initiation of its activity and at fixed time intervals.

66. A method according to claim 61 and wherein said predetermined time duration is determined by incrementing ticks for each thread which is in an active state following initiation of its activity at fixed time intervals which are not measured from the onset of its activity.

67. A method according to claim 62 and wherein said predetermined time duration is determined by incrementing ticks for each thread which is in an active state following initiation of its activity at fixed time intervals which are not measured from the onset of its activity.

68. A method according to claim 61 and wherein said fixed time intervals are 50 msecs, and said predetermined time duration is the time expended until three ticks have been incremented.

69. A method according to claim 47 and wherein said image data is FLASHPIX image data.

70. A method according to claim 47 and wherein said multiple requests are Internet Imaging Protocol (IIP) requests.

71. A computer thread management method comprising:

operating at least one processor, including;

utilizing thread management software operating said at least one processor by causing it to process requests using at least one of a plurality of threads, said thread management software being characterized in that it initiates a new thread only when an existing thread has exceeded a predetermined metric of busyness.

72. A method according to claim 71 and wherein said thread management software is characterized in that it initiates a new thread only when an existing thread has exceeded said predetermined metric of busyness.

73. A method according to claim 71 and wherein said thread management software operates a thread pool containing at least one of said plurality of threads.

74. A method according to claim 73 and wherein said thread management software initiates a new thread when an existing thread in said thread pool has exceeded said predetermined metric of busyness.

75. A method according to claim 73 and wherein said thread management software initiates a new thread only when an existing thread in said thread pool has exceeded said predetermined metric of busyness.

76. A method according to claim 71 and wherein said thread management software opens a socket connection for each new incoming request accepted by a thread for processing.

77. A method according to claim 73 and wherein each existing thread can be in an active state or in a wait state.

78. A method according to claim 77 and wherein threads belonging to said thread pool are characterized in that they enter said wait state upon completion of a client request, and are not destroyed.

79. A method according to claim 73 and wherein at least one of said plurality of threads does not belong to said thread pool and is characterized in that it is destroyed upon completion of a client request.

80. A method according to claim 73 and wherein all of the threads which do not belong to said thread pool are characterized in that they are destroyed upon completion of a client request.

81. An image server according to claim 73 and wherein said new thread is added to said thread pool.

82. A method according to claim 73 and wherein if said existing thread belongs to said thread pool, said thread management software removes said existing thread from said thread pool when said existing thread has exceeded said predetermined metric of busyness.

83. A method according to claim 71 and wherein each of said plurality of threads has an associated priority.

84. A method according to claim 83 and wherein said thread management software lowers the priority of said existing thread when said existing thread has exceeded said predetermined metric of busyness.

85. A method according to claim 71 and wherein said predetermined metric of busyness is a predetermined time duration measured during activity of a thread.

86. A method according to claim 74 and wherein said predetermined metric of busyness is a predetermined time duration measured during activity of a thread.

87. A method according to claim 71 and wherein said predetermined metric of busyness is a predetermined amount of disk access activity.

88. A method according to claim 71 and wherein said predetermined metric of busyness is a predetermined amount of memory allocation.

89. A method according to claim 85 and wherein said predetermined time duration is determined by incrementing ticks for each thread which is in an active state following initiation of its activity and at fixed time intervals.

90. A method according to claim 85 and wherein said predetermined time duration is determined by incrementing ticks for each thread which is in an active state following initiation of its activity at fixed time intervals which are not measured from the onset of its activity.

91. A method according to claim 86 and wherein said predetermined time duration is determined by incrementing ticks for each thread which is in an active state following initiation of its activity at fixed time intervals which are not measured from the onset of its activity.

92. A method according to claim 85 and wherein said fixed time intervals are 50 msecs, and said predetermined time duration is the time expended until three ticks have been incremented.

93. A computer thread management system for processing multiple requests by using at least one of a plurality of processing threads comprising:

thread monitoring software monitoring said plurality of processing threads; and

thread management software managing said plurality of processing threads based upon output from said thread monitoring software.

94. A computer thread management system according to claim 93 and wherein said output from said thread monitoring software is a measure of thread busyness.

95. A computer thread management system according to claim 93 and wherein said thread management software initiates new threads.

96. A computer thread management system according to claim 93 and wherein said thread management software lowers thread priorities.

97. A computer thread management system according to claim 93 and wherein said thread management software preserves some of said plurality of threads after processing one of said multiple requests by putting them into a wait state.

98. A computer thread management system according to claim 93 and wherein said thread management software allows some of said plurality of threads to be destroyed after processing one of said multiple requests.

99. A computer thread management method for processing multiple requests using at least one of a plurality of processing threads comprising:

monitoring said plurality of processing threads; and

managing said plurality of processing threads based upon output from said monitoring step.

100. A method according to claim 99 and wherein said output from said monitoring step is a measure of thread busyness.

101. A method according to claim 99 and wherein said managing step initiates new threads.

102. A method according to claim 99 and wherein said managing step lowers thread priorities.

103. A method according to claim 99 and wherein said managing step preserves some of said plurality of threads after processing one of said multiple requests by putting them into a wait state.

104. A method according to claim 99 and wherein said thread management software allows some of said plurality of threads to be destroyed after processing one of said multiple requests.

105. A method for communicating media over a network comprising the steps of:

encoding the media into a server database at a server;

downloading from the server database to a client database generally only those portions of the media which are necessary to satisfy user requests; and

in response to a user request for a given item of media, determining whether said media is present in the client database, and if not, automatically downloading those portions of the media which are necessary to supply the user with the given item of media from the server database.

106. A method according to claim 105 and also comprising the step of playing the given item of media to the user.

107. A method according to claim 106 and also comprising the step of storing in said client database, those portions of the media which are automatically downloaded from the server database, thereby to gradually build up the client database.

108. A method according to claim 106 and wherein the step of playing includes playing a first portion of media received from the client database and playing a second portion of media received from the server database.

109. A method according to claim 105 and also comprising the step of identifying which portions of media needed to satisfy a user request are stored on a client database.

110. A method according to claim 109 and wherein the step of identifying includes the step of translating an interactive user request for media into fetch addresses.

111. A method according to claim 105 and wherein said encoding step includes the step of compressing

112. A method according to claim 106 wherein said encoding step includes the step of compressing and also comprising, prior to said playing step, the step of decompressing said media.

113. A method according to claim 110 and wherein said identifying step takes place both at the server computer and at a client computer.

114. A method according to claim 106 and wherein said media is stored in a directly playable media database prior to playing thereof.

115. Apparatus for communicating media over a network comprising:

a server including;

a server database having media encoded therein; and

a server access controller enabling generally only those portions of the media which are necessary to satisfy user requests to be identified and downloaded from the server database to a client database; and

a client computer operated by a user including;

a client database; and

a client database manager operative to determine whether a user requested item of media is present in the client database and, if such item is not present, to automatically download those portions of the media which are necessary to supply the user with the user requested item of media from the server database via the server access controller.

116. Apparatus according to claim 115 and also comprising a player for playing the given item of media to the user.

117. Apparatus according to claim 116 and also comprising apparatus for storing in said client database those portions of the media which are automatically downloaded from the server database, thereby to gradually build up the client database.

118. Apparatus according to claim 116 and wherein the player is operative to play a first portion of media received from the client database and to play a second portion of media received from the server database.

119. Apparatus according to claim 115 and also comprising an access controller, identifying which portions of media needed to satisfy a user request are stored on a client database.

120. Apparatus according to claim 119 and wherein the access controller is also operative to translate an interactive user request for media into fetch addresses.

121. Apparatus according to claim 115 and also comprising an encoder that performs data compression.

122. Apparatus according to claim 116 and also comprising an encoder that performs data compression and a decompressor that performs data decompression prior to playing.

123. Apparatus according to claim 120 and wherein said access controller includes both a server access controller and a client access controller.

124. Apparatus according to claim 116 and also comprising a directly playable media database for storing media prior to playing thereof.