1) I personally think the more connections you allow, the better. Also, the smaller files, the better. The updater isn't super great in the sense that it sends files to users as a whole before sending any files to anyone else. This can be good in a instance where you have smaller files, but with big files it may not be as great. In fact, I am not sure how well it will work for people downloading slowly. Though, unless you have a massive game, you probably wont be having a ton of people downloading at once. But as long as your file sizes are small, you should be fine with as many connections as you want.
2) Feel free to use it, glad you like it that much!
On a side note, just to let you know, the updater uses Strings. It also really isn't optimized for much performance, but then again, that shouldn't be a problem for an updater.
I am planning on definately adding compression to the files, too, using the ZLib compression that you can find in the Compressions module under the Common Code folder. I plan to have the updater automatically check for files that do not have a compressed version at runtime, automatically compress them if needed, then when a user requests a file, compair the information to the uncompressed version but send the compressed version. This should help a LOT on the updater bandwidth.
Another thing that I think will help updating is that if you have trusted hosts run updating servers for you. I think I will put this into the vbGORE updater at some point, by the way. What I am thinking is have the client load up, ping all the servers and let the users see the ping times and if the servers are even online, and finally, how many people are downloading from the host. This way, they can see who they can connect to for the fastest downloading, and if that is slow, then they can switch.
Not sure how long it will be until I get to making a system like that, though. I'm having problems even testing it through non-localhost since my router refuses to open many ports.
