COPYRIGHT NOTICE [0001] A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application Serial Number 61/428,040 filed 29 December 2010, and is hereby incorporated by reference in its entirety for all purposes.

FIELD

[0003] The present invention relates to client server systems, and in particular, the maintenance of memory in client server systems. BACKGROUND

[0004] Adobe® Flash Player™ is software, executed by a client device, for viewing files, animations, and movies using computer programs such as a web browser on a client device. Flash Remoting is a well-known Adobe® client-side technology for requesting or calling an application or service that is resident on a remote server when the client is executing a Flash Player™ function. Flash Player™ is available from Adobe Systems incorporated of San Jose, California, USA. Examples of Adobe Flash Player™ functions include requesting information (such as XML documents, movie titles, purchase item lists, etc.), requesting audio and video streaming, and the like. Flash Player executes swf extension files. Flash Remoting is essentially a remote procedure call for use on a client device using Flash Player™.

[0005] ActionScript™ is Adobe's programming language that executes on Flash Player™ and web browser plug-in clients. ActionScript™ programs requesting Flash Remoting services allocate both client and server memory during object construction. Since memory is a finite resource, continuous memory allocation eventually exhausts this resource resulting in system failure. Consequently, memory recycling must occur by freeing previously allocated and unused memory. Standard industry practice implements memory recycling for client memory resources by either explicit program statements or automatic garbage collection. Garbage collection is a term used to de-allocate resources or destroy created objects that are no longer in use. ActionScript™ uses automatic garbage collection for client memory resources since the language doesn't provide explicit memory reclamation statements. Although this automatic garbage collection frees memory in Flash Player and web browser clients, it doesn't automatically signal when server memory can also be freed. Currently, the server only responds to client requests and consequently never knows when client side garbage collection occurs. Thus, server-side garbage collection does not occur when client- side garbage collect occurs. Additionally, server-side garbage collection may not occur at all even though the client no longer needs the resources allocated within the server for the client's use. The above discussed problems are encountered in practically all Web Script applications and Adobe® Flash Player™ is described above for purposes of example only. SUMMARY

[0006] In one aspect of the invention, a client device establishes a socket connection to a server and requests resources. The server grants the resource requests which are used by the client during the socket connection time period. A subsequent disconnection of the socket connection between the client and server then acts as a trigger for the server to de-allocate the resources that were allocated to the client during the socket connection.

[0007] In one embodiment, a method is performed by a server device in a client/server configuration. A client establishes a socket connection to the server and a request from the client to the server to allocate server resources is then detected. Server resources according to the request from the client are allocated. Server resources are de-allocated after detection of a socket disconnection triggering event.

[0008] In another embodiment, a server apparatus includes a network interface and a processor. The network interface connects to a client device. The processor has access to memory and the network interface. The processor can detect an establishment of a socket connection between the server and a client. The processor allocates resources according to a request from the client after a socket connection is made and later de-allocates the resources after the socket connection is terminated.

[0009] A client apparatus includes an interface and a web player. The interface connects to a server. The web player establishes a socket connection with the server and requests a web application from the server. Upon termination of the socket connection, a signal is sent to the server causing the server to de-allocate server resources allocated according to the request from said client apparatus.

[0010] The above presents a simplified summary of the subject matter in order to provide a basic understanding of some aspects of subject matter embodiments. This summary is not an extensive overview of the subject matter. It is not intended to identify key/critical elements of the embodiments or to delineate the scope of the subject matter. Its sole purpose is to present some concepts of the subject matter in a simplified form as a prelude to the more detailed description that is presented later.

[0011] To the accomplishment of the foregoing and related ends, certain illustrative aspects of embodiments are described herein in connection with the following description and the annexed drawings. These aspects are indicative, however, of but a few of the various ways in which the principles of the subject matter can be employed, and the subject matter is intended to include all such aspects and their equivalents. Other advantages and novel features of the subject matter can become apparent from the following detailed description when considered in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 illustrates an example deployment of a client/server architecture;

Figure 2 illustrates an example method to de-allocate server resources; Figure 3 illustrates an example server configuration according to aspects of the invention;

Figure 4 is a flow chart describing exemplary remoting messages sent over a network socket; and

Figure 5 is a flow chart describing an exemplary server implementation according to aspects of the invention.

DETAILED DISCUSSION OF THE EMBODIMENTS

[0013] The subject matter is now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the subject matter. It can be evident, however, that subject matter embodiments can be practiced without these specific details. In other instances, well-known structures and devices (such as power supplies, drivers, etc.) are omitted from the block diagrams in order to facilitate describing the embodiments. [0014] A web video player, such as a Flash Player™, executing a web script program, such as an ActionScript™ program or JavaScript program, destroys objects created during Flash Remoting sessions using automatic garbage collection at the client-side device thus reclaiming such resources. But, the same object destruction or memory de-allocation does not occur on the server side. On the client side, a client program establishes a network socket connection before requesting Flash Remoting services. Automatic garbage collection performs client object removal and subsequent unused memory reclamation. Currently, the server has no such mechanism to free up resources previously allocated by such Flash Remoting services.

[0015] A Flash program could conceivably send explicit socket messages that free server memory; however, monitoring client side memory reclamation can be programmatically onerous and still not provide a fail-safe mechanism by which server memory is reclaimed should network or Flash program errors occur.

[0016] As an aspect of the current invention, the client program establishes a network socket connection before requesting Flash Remoting services. After all requested Flash Remoting services have been completed, the invention includes a network socket disconnection that acts as a trigger to signal the server that all memory and other resources allocated during the previous socket connection time period and subsequent socket communications are no longer needed and can be subsequently freed. In one aspect of the invention, this socket disconnection signaling or triggering also provides a fail-safe mechanism such that unexpected failures like Flash program crashes or network disconnections insure that the server is still informed that memory and other resource reclamation can occur.

[0017] Figure 1 depicts a deployed Flash Remoting system architecture represented generally by the reference numeral 100. A web file 102, (such as a Flash File.swf) is a representative Shockwave Flash (SWF) file, references or nests representative Video program files 118 and web script program files 120. Web Files 102, such as SWF files, can be deployed on devices such as set-top boxes (STB) 104, personal computers 106, and mobile phones 108 containing a web video player executable environment 110. An example of a web video player is Adobe® Flash Player™. However, any web video player 110 can be used. A device's web player 110 can load a web file 102 and subsequently commence playing back its video program files 118 and executing its web script program 120. A device's web script program 120 contains statements making web application server requests such as Flash Remoting requests to a web application server 112 using a web application server request format communications path 114 between a web video player 110 and a web application server adapter 116 of the web application server 112.

[0018] Figure 2 depicts an example flowchart method for Flash Remoting garbage collection according to principles of the invention. The method 200 is executed at the server device and starts at step 201 which generally occurs when a client device, having a web video player such as Adobe® Flash Player™, establishes a connection to perform a Flash Remoting operation. The server waits for a client socket connection at step 205. At step 210 it is checked whether the client has made a socket connection. If no socket connection is made, the process returns to step 205 and repeats waiting for a socket connection. Once a socket connection is determined to be established at step 210, step 215 is performed and the server waits for a client request from the web video player on the client device. This client request may be made through a Flash Remoting process of a Flash Player on the client device. After the client has made a request, a socket disconnection is tested in step 230. If the socket is not disconnected, then the request is honored and the server may, for example, allocate a memory resource per the client request at step 225. The process the returns to step 215 to wait for a new client request. If the client device has a disconnected socket, then the server frees up all previously allocated memory per step 220 and returns to step 205 with the server waiting for a new socket connection.

[0019] Figure 3 represents a server block diagram 300 capable of implementing the method of Figure 2. Figure 3 includes a local area network (LAN) 320 connection to a server 350. The LAN 320 communicates to the internet 305 via a router 310 and to the server 350 via a network interface 335. In one implementation, the internet 305 allows a client device 355 to communicate with the server. The client device 355 performing a Flash Remoting operation while executing a web script file such as a Flash Player™ compatible file or SWF file. The server 350 includes a memory 325, a processor 330, the network interface 335, and a disk drive 340. One option for interconnection of the components of the server 350 is an internal bus 345, but other implementations are possible as is known by those of skill in the art of equipment design. Both memory 325 and disk drive 340 contain resources allocated and reserved by web Remoting operations. Memory 325 contains example resources such as operating system synchronization, process management, and data buffer objects. Disk drive 340 contains example resources such as directories, files, and partitions. Client devices 355 are able to connect to the server 350 either through the internet 305, the LAN 320 or directly to the internal bus 345. The Figure 2 method frees both memory 325 and disk drive 340 resources upon detection of the trigger event of socket disconnection. [0020] The server 350 performs the method 200 of Figure 2 which functions to free up previously allocated resources, such as memory, files, bandwidth, and the like after the client has released the socket connection established between the client 355 and server 350. The server 350 uses the socket disconnection event as a trigger to reclaim resources. The de- allocation of resources in the server prevents resources remaining uselessly allocated to a client that no longer requires the server resources.

[0021] The following client ActionScript code displays representative web application server request statements. The code below is described in the flow chart of Figure 4 and demonstrates an exemplary Flash Remoting message sent over a network socket. One of skill in the art will recognize that the following Code is only one example embodiment and that other similar code embodiments are possible. The below-listed code is broken up with annotations identifying steps in the flow chart of Figure 4 interspersed within the related code sections:

[0022] Exemplary code for sending of a flash remoting message over a network socket begins at step 402. private function SocketTest(server: String, port:Number):void

{

var Msg = "hello";

A Socket is then created in step 404. mySocket = new Socket();

ThomObj ect. setSocket(my Socket);

Objects are then encoded in step 406. One example of encloding as depicted in the exemplary code herein is AMF3 (Action Message Format). Alternatively, XML encoding or the like can be used for encoding the objects. mySocket.objectEncoding = ObjectEncoding.AMF3; Upon receipt of data, onSocketData is called in step 408. mySocket.addEventListener(ProgressEvent.SOCKET_DATA, onSocketData); A socket connection is made by the client in step 410. mySocket.connect(server,port); A request is then made by the client in step 412. mySocket.writeObject(Msg); mySocket.flushQ; function onSocketData(evt:ProgressEvent)

{

var newObj bject;

while (mySocket.bytesAvailable > 0)

{

newObj = mySocket.readObject();

}

The socket is then disconnected in step 414. mySocket.closeQ;

[0023] The C code below demonstrates one possible server implementation according to aspects of the invention. The below-listed example code is broken up with annotations identifying steps in the flow chart of Figure 5 interspersed within the related code sections:

[0024] The process at the server begins at step 500. At step 502, the server waits for a client socket connection. The server checks whether a socket connection has been established in step 504. static void *SocketThread(void *param)

{

int i, loop = 1 ;

ssize_t rdbytes, allocbytes;

unsigned char buff[BUFF_SZ], *ptr;

sockattr t sockattr;

If the server determines at step 504 that a socket connection has not been established, the process returns to step 502 and waits for a client socket connection. If the server determines that a socket connection has been established, the process advances to step 506. The server then waits for a request message from the client in step 506. if (RetrieveSocket(&sockattr) == 0) while (loop)

{

In step 508 it is checked whether the client has disconnected the socket. if ((rdbytes = read(sockattr.fd, &buff[0] , BUFF SZ)) > 0)

{ allocbytes = rdbytes;

If the client has not disconnected the socket, the server allocates resources per client request as discussed in step 510. ptr = malloc(allocbytes * sizeof(char));

printf("Received Flash Remoting request: ");

for (i = 0; i < rdbytes; i++)

{

*(ptr + i) = buff[i];

if (isprint(*(ptr + i))) printf("[%c]", *(ptr + i));

else printf("[%02X]", *(ptr + i));

}

printf("\nAllocated %d bytes\n", allocbytes);

if (BroadcastSocket(sockattr.fd, (void *) &buff[0],

(size t) rdbytes) < 0)

{

fprintf(stderr, "BroadcastSocket() Error!\n");

}

}

else if (rdbytes < 0)

{

switch (errno)

{

case ENOTCONN:

perror("ENOTCONN");

loop = 0;

break;

case EINVAL:

perror("EINVAL");

loop = 0;

break;

default:

perror("Exiting - ");

loop = 0;

break;

}

}

else

{

If it is determined that the client has disconnected the socket, the server frees all previously allocated resources such as memory or bandwidth in step 512. free(ptr);

printf("Freed %d bytes\n", allocbytes);

printf("%s():%d tid=%u, fd=%d - ExitingV ^* ,

_FUNCTION_, _LINE_, sockattr.tid, sockattr.fd);

loop = 0;

} }

if (DeleteSocket(&sockattr) < 0)

{

fprintf(stderr, "DeleteSocket() Failure !\n");

}

}

else

r

i

fprintf(stderr, "RetrieveSocket() Failure !\n");

}

pthread_exit((void *) 0);

}

static int BroadcastSocket(int fd, void *buff, size t nbytes)

{

int status = 0;

size_t bytes;

ssize_t wrbytes;

list_pointer curr; if (pthread_mutexJock(&listlock) != 0)

{

return(-l);

}

if (head)

{

curr = head;

while (curr)

{

bytes = nbytes;

while ((wrbytes = write(curr->fd, buff, bytes)) > 0)

{

bytes -= (size_t) wrbytes;

}

if (wrbytes < 0)

{

status = -1 ;

break;

}

curr= curr->link;

}

}

else status = -1 ;

if (pthread_mutex_unlock(&listlock) != 0)

{

return(-l);

}

return(status);

}

[0025] The exemplary server C code above generates the following server console output when exercised with the above code. "Received Flash Remoting request: [06] [OB] [h] [e] [I] [I] [o]

Allocated 7 bytes

Freed 7 bytes

SocketThread():226 tid=6987968, fd=4 - Exiting"

[0026] The server console output above shows the server receiving the "hello" string from the client. The server stores the string in a 7-byte memory allocation. The client then utilizes the allocated resources to obtain and process the requested information. The server then echoes back the encoded string. The client onSocketData handler receives the echoed string and subsequently closes the socket. The server detected the client's socket closure, freed the previously allocated bytes, and then exited the "while" instruction loop.

[0027] According to an aspect of the invention, the server resources, such as memory, is de-allocated because the client has disconnected the socket connection and no longer needs the server resources. Essentially, the client socket disconnection triggers a resource de- allocation in the server. As indicated in the above, the example C code provides the functionality to detect the socket disconnection trigger and start, for the server, a de-allocation of previously requested, but now unused server resources. Such resources may include allocations in the server for file, operating system, and network resources including bandwidth. Socket disconnection can occur accidentally by implicit system errors and intentionally by explicit program statements such as ActionScript™ or JavaScript program statements. The server method of Figure 5 thus operates robustly under ideal and actual system circumstances. One aspect of the invention includes the feature that the socket disconnection triggering event triggers the server to free up resources allocated during the socket connection that was just terminated. Thus, ongoing socket connections and their corresponding resource allocations may continue undisturbed while the just-terminated socket connection resource allocations are reclaimed.

[0028] The implementations described herein may be implemented in, for example, a method or process, an apparatus, or a combination of hardware and software. Even if only discussed in the context of a single form of implementation (for example, discussed only as a method), the implementation of features discussed may also be implemented in other forms (for example, a hardware apparatus, hardware and software apparatus, or a computer-readable media). An apparatus may be implemented in, for example, appropriate hardware, software, and firmware. The methods may be implemented in, for example, an apparatus such as, for example, a processor, which refers to any processing device, including, for example, a computer, a microprocessor, an integrated circuit, or a programmable logic device. Processing devices also include communication devices, such as, for example, computers, cell phones, portable/personal digital assistants ("PDAs"), and other devices that facilitate communication of information between end-users.

[0029] Additionally, the methods may be implemented by instructions being performed by a processor, and such instructions may be stored on a processor or computer-readable media such as, for example, an integrated circuit, a software carrier or other storage device such as, for example, a hard disk, a compact diskette, a random access memory ("RAM"), a read-only memory ("ROM") or any other magnetic, optical, or solid state media. The instructions may form an application program tangibly embodied on a computer-readable medium such as any of the media listed above. As should be clear, a processor may include, as part of the processor unit, a computer-readable media having, for example, instructions for carrying out a process. The instructions, corresponding to the method of the present invention, when executed, can transform a general purpose computer into a specific machine that performs the methods of the present invention.

[0030] What has been described above includes examples of the embodiments. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the embodiments, but one of ordinary skill in the art can recognize that many further combinations and permutations of the embodiments are possible. Accordingly, the subject matter is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims.