What happens to Feature Block 1 when you upgrade a package?

Recently, I had a discussion with a colleague around what happens to Feature Block 1 when you perform a package upgrade: does it get completely restreamed, when is the FB1 data erased when opening a package for upgrade, ... ? I decided to perform a set of small tests in order to figure out what happens exactly.

Here are the results: I used the SoftGrid Sequencer 4.2 build 303 for creating the packages, SFTExplorer 1.0 for finding out what the FB1/FB2 contents looks like and NetLimiter 2.0.10 Freeware to monitor network traffic.

When is the FB1/FB2 separation erased when opening a package for upgrade?

A first test consisted of finding out when the FB1/FB2 separation is erased when using the "installation wizard" for making modifications to the package:

• When adding a new file to the package using the "installation wizard", and not running the "application wizard" (FB1 determination), results in a loss of a previous FB1/FB2 division. The entire package becomes FB1 data.
  
  
• When adding a new file to the package using the "installation wizard", and then running the "application wizard" for FB1 determination, results in FB1 containing those (parts of the) files that are accessed during the FB1 monitoring. This is precisely the expected behaviour.

When opening the package for upgrade and immediately saving the package without making any modifications, retains the FB1/FB2 separation. As mentioned above, when you click the "Begin Monitoring" button in the "installation wizard", the FB1/FB2 separation vanishes, even when not changing anything in the package. This means that the "Begin Monitoring" click is (roughly speaking) the point where the previous FB1 is lost.

A second test consists of what happens when you use the "Encode Directory" option to modify the contents of the package instead of the "installation wizard". Something interesting here:

• When you use the "encode directory" wizard, the FB1/FB2 separation is lost, which coincides with the behaviour of using the "installation wizard". Strangely enough, now the entire package becomes FB2 (!!) with only SoftGrid's osguard.cp file being in FB1.
  
  
• When using the "encode directory" wizard, followed by the "application wizard", creates the usual FB1/FB2 separation that one would expect.
  

Here, the start of the "encode directory" wizard triggers the erase of the previous FB1/FB2 separation.

What is streamed to a client after a package was upgraded on the SoftGrid server?

This is very simple: the entire package needs to be restreamed to the client when the package is upgraded on the server. I performed the following three tests on a SoftGrid package that contained 3 files of 5 MB each:

• The first time the package was created, I added one file of 5 MB to FB1 (by reading it into WordPad during the monitoring phase). After publishing this application on the SoftGrid server, the SoftGrid client pulls in 5 MB as expected ; this was monitored using NetLimiter and verified in the SoftGrid client management console.
  
  
• Then I opened the package for upgrade, ran the "Application Wizard" and now touched the original 5 MB file that was already in FB1 and also a second 5 MB file. The sequencer correctly reports that the FB1 size then becomes 10 MB, as expected.
  
  The client's total transfer size after placing this new package on the server (using "Add Version") came down to 10 MB, the entire FB1. Notice that the launch bar kept on saying "100%" at the client side, even though a restreaming was in fact being performed.
  
  
• The third test consisted of opening the package with a 10 MB FB1 size and changing a single byte within one of the files that was in FB1. Again, it turned out that the entire FB1 was transferred to the client when I upgraded the package on the server.

I have heard several people say that SoftGrid will only stream the difference between an original package and the ActiveUpgrade that is performed on it; from these simple tests it turns out that this is not the case: upon every package upgrade, all previously cached data is invalidated at the client.

In a sense, this is not really surprising: at every save of a package, it is restructured and optimized for streaming according to the FB1/FB2 separation that was specified during the application wizard. This new SFT structure could in principle be completely different from the old SFT, making it nearly impossible or inpredictable on a 32 KB-block level to say which blocks need retransfering. I don't really see a practical way of implementing this when using a streaming protocol that only knows about block numbers and not about the contents of the package.