New version of service installer

There is a new version of the NT/2K/XP service installer available at http://kerryjones.home.mindspring.com/sobsvc.zip (same URL as before). The new version has the following new features:

1. ability to automatically restart service at a fixed time each day (principally a workaround for the "socket grabbing" problem)

2. ability to automatically restart any client that crashes (I've never had it happen, but some have)

3. ability to automatically restart any client that stalls or hangs (same comment as #2).

4. ability to run client worker threads at true lowest possible priority (not generally recommended, but some have a need for this).

Of course, it still has all the old features - support for up to 32 clients, affinity setting, affinity optimization, etc. I should probably put in a disclaimer about new feature #3 - since this problem doesn't happen to me, I haven't been able to test it with a "real live stalled client," but it does happily restart a manually paused client (it takes it about ten minutes to decide that a client is stalled).

The readme has instructions for upgrading (essentially just stop the service, unpack the zip and restart) and for installing from scratch.

Let me know via this forum if you have any problems of any sort. I may be hard to reach for the next week or so, so if you have an urgent problem with the new version, you can revert to the original version - it's available at http://kerryjones.home.mindspring.com/sobsvc10.zip

If there are any other features you'd like in the service handler, let me know and I'll see what I can do. Let me know fairly quickly, though, because I really don't intend to do a *lot* of additional work on this thing.

thanks again, Math-Guy.

:thumbs:

Big thumbs-up.

I just installed it in the other room.

Dont' really need the new features for that install but figured I would install it and if there are any problems hopefully I can find them. ;)

Is it possible to add an option to force the sob tray icon without having to restart the service?

I find myself restarting the service after reboots just so that I can see the icon...

Thanks,

Kevin C.

heh. yeah, I do that too.

just FYI: we have the service running on about 90% of the computers we are running the project on. We are very happy with it, and we owe our position in the stats entirely to the service!

All Hail MathGuy!

:notworthy

OberonBob: any information on your experiences deploying SoB on your networks/labs would most likely be appreciated by the community as a whole.

Tips for installation, options set in the service, what OS and network settings you have (not specific, but general stuff) and anything else that might others install SoB on larger Win NT based labs/networks without having to "re-invent the wheel"

Especially any sort of scripts for monitoring or installation.

well, ORU is a Novell shop. We have ZENworks (Zero Effort something,installation,maybe?), and we can just a take a snapshot of what we want, and push it on out. works like a charm, most of the time.

As for settings, we are running restart if stopped, restart if stuck, restart at 5am every morning, and true idle. True idle great and fixes some screensaver issues we had before.

Monitoring is a great unknown, we don't have a good way of knowing if some machines are not working or whatever. I did set up tcpproxy on a linux box to get around a firewall issue for some of our more secluded computers, I suppose it must log connections or something, I might could redirect all the traffic through it, and parse the logs somehow. Now you got me thinking...

--
OberonBob
Team ORU

Quote:

---

Originally posted by kevinc
Is it possible to add an option to force the sob tray icon without having to restart the service?

I find myself restarting the service after reboots just so that I can see the icon...

Thanks,

Kevin C.

---

Back from vacation now and I'll give that a thought...I actually do the manual restart thing myself to see the icon!

Hey, Mathguy, sonds great! Have you considered using your system to make a queueing system for these work units? You'd really only have to store one extra per processor, but it could make a real difference for those of us on dial-up.

Thanks! :notworthy

Yes, I have thought about it and unfortunately, there's a problem: keeping the clients busy is not really that hard (I could start and then stop an "extra" client and let it cache its result, which could be moved to a working client if it runs out of work). BUT, the big problem is how to let the server know that the work unit was finished. This can only be done by a client as it finishes up the work unit, so I would have to cache the progress just before it finishes (somehow), then restart it when connected to the Internet...very awkward!

How about this: just before a client is to report a block, if there is no connection, I dial the default connection, then leave the connection up until after it has reported, at which time I drop it if there has been no other activity on the line.

That is probably do-able...let me know what you think.

Service Handler 1.2 is now up at the above link. In addition to 1.1, it does the following:

1. has a slightly different method of detecting stalled clients which seems to work better.

2. has an option to restart all the clients when a user logs on, so that the icons show up in the system tray automagically

3. produces a log file of its actions in case (this thing is getting complicated enough to warrant it, unfortunately).

The only other suggestion that I am thinking about that I haven't implemented is some sort of assistance for dial-up-networking. See above post for what my current thinking is on this subject.

Let me know (again, fairly quickly - I'm really not planning on making a career of this) if you can think of anything else to put in.

Thanks for your efforts.
Marc

Thanks again. :)

Thanks MathGuy!


I have put up a little page here on my web page, with info on the Service Install, and also have added my own version with a small script which does a couple of the main configuration settings :)

Thanks for this workaround! :)


Garry
(Confused)

Thanks, Confused!

I should probably mention here that in response to some requests from a few Team Prime Rib members I'm doing a similar thing for Win9x/Me...it's not a *real* service (since 9x/Me doesn't have them) but it will at least allow 9x/Me folk access to the monitoring/restart capabilities of the service handler...I'll post here when it's done.

The 9x/Me "service" handler is done and available here: http://kerryjones.home.mindspring.com/sobsvc9x.zip It hasn't received anywhere *near* the amount of testing as the NT/2K/XP version, but all the core code is identical, so I suspect it will work fine.

Also, there is a new version of the NT/2K/XP handler up at the old link - http://kerryjones.home.mindspring.com/sobsvc.zip - no new features, but fixes a few minor bugs that nobody noticed but me, apparently (or you didn't tell me if you did). Namely:

1. on slow machines with lots of startup load (for example, antivirus and such), the clients occasionally fail to start successfully within the time the service handler allows. Now it tries again, if the "monitor and restart" switch is turned on.

2. machine shutdown didn't properly cache the client progress, so you could lose a bit of work (on the order of 5 minutes) across a machine restart.

3. some of the log messages were inconsistent in the numbering of the clients.

4. I think there was some other piddly little thing or other, but I forget...

Enjoy!

Thanks MathGuy!


I have added the link and information to my site, which I listed above, and is also linked to on my Daily Stats threads on Anandtech forums :)


Confused

Cool to see a new version for 9x. :thumbs:

I just posted a small news blurb on the homepage for those who haven't heard about the service install yet. if you see any features i missed or something, drop me an email and i'll update it.

Just to clarify for those curious, the reason there is no "dead idle" priority in SB by default is because i noticed on my system that the cache file will often take ages to open even when the system is under no load. i'm talking like 20 minutes of it sitting there trying to read from a 300k file. :(

I think it's cool that MathGuy included the option, but just be wary if you experiment with it. If you don't get the problem, great. if you do, you probably should just leave SB on the default idle.

Other than that warning about the experimental new feature, the service install is a solid program and well worth the install, especially if you have an SMP system.

-Louie

9x version was posted prematurely and has some serious problems in some configurations...this is why I didn't do it in the first place! I'm yanking it for the time being. Hopefully, I'll have the wrinkles worked out and re-post it some time this evening.

I found this in my own testing and haven't heard of anyone being messed up by the 9x "service" - if there is someone, I apologize!

In the meantime, if you don't use the "-m" option, then you can simply uninstall the service as the readme indicates ("sobsvc9x -u").

If you have used the "-m" option, then you may get a flurry of client restarts that keep you from being able to do anything useful on your machine. Use Ctrl+Alt+Del, kill sobsvc9x, then uninstall as above.

Again, my apologies! Alas, 9x/Me are not nearly as robust and predictable from a programming viewpoint as NT/2K/XP...

Thanks for letting us know, MathGuy :)


I have put the information up on AT, and have currently moved my 9x Service Handler help thingy out of main view.

I hope you get things ironed out, and many thanks for doing this! :D


Garry

Thanks, Garry - I had forgotten just how bizarrely different all the various 9x/Me versions are...I currently have a version that works on BOTH 98 and 98SE (woohoo!). I'll check out ME and 95 when I get some more time this evening. Hopefully this will be back up shortly.

The 9x/Me handler is back up and works now under all the configurations and permutations that I have been able to put together. I should mention that I was unable to test under Win 95 since the only machine like that I have access to was unable to install the SB client. This is a known problem which is thought to be related to not having winsock 2.0, but the machine I was using *does* have winsock 2.0 on it...rather than delay the whole thing for compatibility with a seven-and-a-half-year-old OS, I decided to let it fly (again - <groan>).

My family has been instructed that, should I ever again volunteer to do any 9x/Me programming, they should simply shoot me since this will only happen if I have *entirely* lost what is left of my mind (the same instructions apply if I should ever purchase an electric lawnmower, but that's another story...)

It's located here: http://kerryjones.home.mindspring.com/sobsvc9x.zip

Let me know if there are any *further* problems...

LOL! Thanks MathGuy :)

Have posted news up on Anandtech :) Hopefully people will find it useful! :)


Garry

Update: I found a (decrepit, ancient, slow) machine using Win95 B, on which the SB client would install fine. The 9x/Me service handler works fine on it, except that the KeepVisible option (restart client when someone logs on so that the icons are visible in the system tray) seems not to work. If the OS won't notify me when the taskbar is re-created, there's really nothing I can do <sigh>.

I doubt this is a high-priority issue for anyone, but I thought I'd let you know. It's possible that this is yet another quirk of some flavor of 9x/Me and there is a workaround possible. If I find one, I'll implement it. If not, then I won't (obviously...)

Quote:

---

Originally posted by MathGuy
Yes, I have thought about it and unfortunately, there's a problem: keeping the clients busy is not really that hard (I could start and then stop an "extra" client and let it cache its result, which could be moved to a working client if it runs out of work). BUT, the big problem is how to let the server know that the work unit was finished. This can only be done by a client as it finishes up the work unit, so I would have to cache the progress just before it finishes (somehow), then restart it when connected to the Internet...very awkward!

How about this: just before a client is to report a block, if there is no connection, I dial the default connection, then leave the connection up until after it has reported, at which time I drop it if there has been no other activity on the line.

That is probably do-able...let me know what you think.

---

Sorry I'm so late getting back to you. I've been on Spring Break! :cheers:

That would be great for some, but not necessarily for me. How about this: Set the MaxRetries to 1, and the RetryWait to some reasonable value. When the client finishes its work unit, it should stop, and exit after the RetryWait. When you detect that the client has died, restart it and check before and after the RetryWait. If the client dies again, in that interval, there's a good chance the WU is done. So then swap out the WU.

Alternatively, I think I the source code for PRP (one of the source zips I think) would show you how to dig the completion level out of the z#### file. Of course, this could also allow cheating :eek: , but I don't think it's that easy to figure out...:confused:

I should also note that I've never actually watched SoB finish without connecting.

It seems this "handler" is nothing but a service install, am I correct? What if I like being abloe to see the little GUI??? Does using this mean that everything will be hidden?

Heck . . .that is part of the fun of DCing! Being able to physically see those numbers!

Jammy :swear:

Quote:

---

Originally posted by MathGuy
.

Also, there is a new version of the NT/2K/XP handler up at the old link - http://kerryjones.home.mindspring.com/sobsvc.zip - no new features, but fixes a few minor bugs that nobody noticed but me, apparently (or you didn't tell me if you did). Namely:

---

It originated as simply a service install, but it has a number of other features now:

1. ability to have multiple clients running (up to 32)
2. ability to automatically set processor affinity (on multi-processor machines)
3. ability to restart the clients at a particular time of day (useful for releasing the sockets that they accumulate)
4. ability to monitor and restart any clients that crash for any reason
5. ability to monitor and restart any clients that stall (this seems to happen more than crashing)
6. ability to run clients at absolutely lowest priority (some find this helpful)
7. ability to restart clients whenever the taskbar is re-created (so the icons are always visible in the tray)
8. anything else you'd like to have that I eventually get around to putting in (currently this includes a work-unit queue to assist dial-up users).

You can, of course, keep the icons from showing up in the system tray with a service install, but that's not the main reason for it (in fact, by default, this service installs with visible icons). The main reason for a service is that it runs before anyone logs on.

Headless crunchers find this particularly helpful...

Thanks! I will try this then. :)

Jammy

Quote:

---

Originally posted by MathGuy

You can, of course, keep the icons from showing up in the system tray with a service install, but that's not the main reason for it (in fact, by default, this service installs with visible icons). The main reason for a service is that it runs before anyone logs on.

---

Hmmm...not bad. I think I'll use this version. :)

Old thread, I know, but I needed to bring it to the top for installing on other pc's. :)

Quote:

---

Originally posted by rstarr
Hmmm...not bad. I think I'll use this version. :)

Old thread, I know, but I needed to bring it to the top for installing on other pc's. :)

---

Not only is it an old thread, but it refers to what is now an old version. The handler on my website is the old one (for use only with client version 1.0.0). The version of the service handler that comes with the current client (1.1.0) has the same features, but works with client version 1.1.0, which is much better in many ways than client version 1.0.0.