[wpkg-users] creative ideas to spread out the running of wpkg installs?

[Dr. Frank Lee]

>> <thinking mode=aloud>
>> wpkg.js has a function which displays debug messages to screen or event
>> viewer. Could that be adapted to optionally open HTTP connections? We
>> might assume that the wpkg file server has an httpd running
>
> No, we should not assume HTTP server is running.

We have to assume something! (-:

> At least, my experience shows that a file server doesn't necessarily 
> have to run a web server.

I agree with you - but *if* we want some central logging facility, we need 
some way of doing it and I don't think that there's a way of doing that 
through samba or windows file sharing. We could take the route of writing 
our own logging server (which seems like a load of effort for little 
gain), using some central syslogging server (again, lots of effort and 
requires something to be installed on all the clients) or using something 
easy to arrange and well known like an httpd. For what it's worth, my file 
server doesn't run an httpd server either but they're available for just 
about any OS and pretty simple to set up. Just seems like the lowest 
effort solution.

> So, wpkg.js would have to connect somewhere:
>
> http://wpkg.server.org/wpkg-log.php?query
>
> and expect a number (like 10, for 10 running installations).
>
> If the number is greater than, say, 15 (configurable), wait for 30 seconds.

Not what I was suggesting but I like the idea. (I was just thinking about 
one-way data transfer via the HTTP requests and ignoring the response.)
Having the ability for the server to return an action like "wait 30s" or 
"overloaded: try later" would be great.

> wpkg.js should report its actions every 15-60 seconds or so - if a given host doesn't report anymore, consider the installation successful (host
> died, ended installation etc.)

Would be nice if it did but possibly more work to implement. I use a 
central syslogging server for monitoring clients and therefore see the 
event viewer logs. It's easy enough to see the last WSH entry and deduce 
what's happening even if it was a while ago.

> Hmm, perhaps, much more has to be thought.

Thinking is always a good plan. We're more likely to come up with 
something useful, for a start!

> If the OP has a fat server as he says, it shouldn't suffer in that way 
> with a 90 MB file. The file should be buffered/cached fully by the 
> operating system, and served from RAM.

Agreed - I wasn't trying to address this though.

> With small devices serving as file servers, installing 70 clients 
> concurrently is not a great idea (although it happened to me to 
> installed ~30-40 machines, operating system + software, off a 2.4 GHz 
> machine with 256 MB RAM - still, it went fine).
> So I guess, the OP should look more carefully at his server's configuration.

Definitely. Or possibly network congestion (can that raise the CPU load? I 
guess re-trying TCP transmissions could do but I'm no expert on TCP 
stacks...).

Yours,

Frank