# An Experimental Implementation of a Resilient Graphic Rendering Cluster
## 1 Introduction
The GRC-client then sends a model description to each server in the render farm, and then a keep-alive connection executes the handshake part of GRCP (Graphic Rendering Cluster Protocol) by sending the clock value for the particular frame and waiting for the Persistence of Vision Ray rendering job of the frame to finish. After that, the GRC-server process on the render farm server will produce a reply indicating that the particular result frame is done and declare its size, making it available to the client for download over the existing connection. The procedure has been designed to produce an animation of a scene by calling a rendering farm node for each frame and then, having rendered all frames and transferred them to the web-front server's hard drive, calling ImageMagick's convert utility to produce an animated GIF. The animated GIF is then displayed in a separate HTML frame. Several layers of protection were added so the client could exhibit error recovery from transient and fatal errors, which were transmitted through a custom GRCP protocol reply status code common to protocols like SMTP, FTP or HTTP [5]. Finally, a web panel was added to provide a rendering progress meter to the user so they could know there was work in progress and not a server stall. Several programmed actions were introduced during the course of development to make the cluster finish animation in a reliable and resilient way, in contrast to GRID animations from SEE-GRID project, which would spuriously fail for unknown GRID reasons and without an error code. An effort was made to reduce frame dispatching overhead to the cost of rendering with Persistence of Vision-Ray SDL scenes. Where available, compile time and runtime optional Linux zero-copy kernel system calls were used, adding to cluster performance and eliminating some performance bottlenecks, thus increasing the theoretical limit of render farm servers that can be served via the GRC-client process which equally serves the text terminal and web front-end interface to the rendering farm. With a minimal scene box pov and a minimal rendering resolution, up to 3600 fps (frames per second) were reached on the 32-core cluster (on minimalistic benchmark Persistence of Vision Ray scenes), which demonstrated low overhead of managing animation frames and polling server nodes from the rendering farm. (However, this was only benchmarking. Real-life loads are something completely different.) The render farm servers are declared in a configuration file with server: port entry per line. Pluggable interface to the Persistence of Vision Ray rendering engine allows for use of other render engines, in addition to ray tracing Persistence of Vision Ray, which introduces performance problems because it uses mathematical interpolation instead of vertex rendering. Additionally, Persistence of Vision Ray has the limitation of no hardware or GPU support; the entire rendering process is executed on CPU and in software. Due to a small overhead to the cost of rendering, GRC-client/GRC-server and their GRCP communication protocol allowed for pluggable extension of the architecture which can be used to produce animations exported from open-source software like the Blender. This is enabled in the protocol and upload mechanism with corresponding MIME types (e.g., application/x-tar-povray).