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.
