Block based Streaming
Previous  Top  Next

 
streaming overview  
 
Any network storage device can serve as a streaming server for hundreds or thousands of client PCs. To use Thinstall packages in a streaming fashion, simply place your Thinstall package in a location that is accessible to client PCs and send a link to end-users to run the application directly, for example \\server\sharename\application.exe. You can also create shortcuts on the end-user's desktop which point to the centrally hosted EXE package(s). When the user clicks on the shortcut, the application will automatically begin streaming to the client PC. During the initial streaming startup process, the Thinstall statusbar will inform the user of the progress. Once enough of the application has been streamed that the application can begin running, the status bar will slide down and the user can begin using the application. As more parts of the application are required by the application, they will be pulled from the "streaming server". Thinstall does not require any special server software to provide streaming capability; any windows file share, NAT device, or SMB share can automatically provide this capability. The amount of data that needs to be transferred before the application can begin running will vary widely; Office 2003 requires only a fraction of the package contents to be streamed before the application can run. Thinstall's streaming is currently designed for LAN based environments with 100mb networks recommended. For WAN and internet deployments where unexpected disconnects are more common, we recommend either deploying using a URL or using a desktop deployment solution to push the package in the background and only allow execution once the entire package has been downloaded. This will reduce failures and eliminate scenarios where unstreamed portions are required by the application during a network outage. A company with many branch offices would typically designate one "applicaiton repository" at each branch office which mirrors a central shared folder to optimize local performance for clients located at that branch.

For best security, it is recommended that a central shared directory be made read-only so users can read the package contents but they cannot tamper with the executable contents. As multiple users stream a package from a shared location, changes made by the application will be stored in the user's sandbox. The user's sandbox location defaults to %AppData%\Thinstall\APPLICATION_NAME, but can be configured at runtime or package time. A common setup is to have the user's sandbox be located on another central storage device so the user can walk up to any PC and retain their individual application settings centrally. When packages are being streamed from a central share, they will remain locked until all users have exited the application. Thinstall provides a mechanism for updating applications while they are still running to address this scenario.

Some common questions about Thinstall's streaming:
Q. If I have a large package, will it take a long time to load over a network?
A. No, not necessarily. The size of the package has no effect on the startup time of an application. If you add an extra 20GB file to your package which is not used at runtime it will load at the same speed as before. If the application opens and reads 32k of data from the 20GB file, only 32kb of data is sent across the wire.

Q. There is no client and no server, how is streaming possible?
A. The "client" is built into the EXE package, but it is very small (400k) so the load time of the client across a network is only a few milliseconds. Once the client is loaded into memory on the client PC, it decides which blocks of data are further required from the "server" and reads them based on application activity.

When compressed Thinstall EXEs are placed on a network share or USB flash, the contents from the EXE file will automatically stream to client PCs in a block based fashion. As the application request specific parts of data files, this information is read in the compressed format over the network using the standard windows file-sharing protocol. After the data has been received on the client PC, data is decompressed directly into memory and provided to the application. Because no data needs to written to disk during the entire process the process is very fast and client PCs need only minimal disk space to host the operating system. When subsequent read requests are made by the application for the same data, the Window disk cache will provide the same data without requiring a network read operation. If the client PC runs low on memory, Windows will automatically throw away some of its disk cache and provide the memory resource to other applications.


clip0051