Question about sharing clients/files on LAN

[BlueWeasel]

I would like to set my second computer/client up so that the client is not a seperate install and upload on my second computer. I want to be able to crunch based on the buffer files on my main computer and upload the total (both computers) results from just my main computer.

I have the client folder on the main folder shared so that the other computer can see it. Can I just run the executable over the network and let it go, or will I have problems?

I have read the FAQ on the TA Distributed Comp. webpage, but seems like this method will work just as well.

The only problem I can see is if the second computer will have a problem opening/reading the buffer files if the client is running and writing the same buffer files on the main computer. However, the directory is shared, so I would not think this is a problem.

 

[Wolfie]

I am thinking you could run your own proxy.... That way everything goes threw one puter. But you will have to ask someone else how to set that up. I know nothing about that kinda stuff. Just a thought tho.


Wolf

 

[jinsonxu]

I offer my services to help if you want to setup a proxy. Lots of members here who can help too.

 

[BlueWeasel]

Is a proxy definately what I need? . . . .OK, I'll be honest - I don't know what a proxy is.

I was hoping I could just make some changes to some *.ini files, share a folder, and off I go.

 

[jinsonxu]

Actually with your current setup, remote buffers are sufficent. A proxy might be overkill.

 

[JonB]

BW, you can indeed run the client that way. I know I did at first,

BUT

it isn't very stable or desirable for a couple of reasons. First, a disconnection of the network from either end at the wrong time can corrupt or lock the buffer files. That means lost time and lost blocks. Second, the host computer must stay available constantly. I'm not talking just on, but not even rebooting, since a reboot could cause the other computer to lose its path when it needs to update the buffer files.

As mentioned above, a "personal proxy" or "pproxy" is a good way to go. The pproxy program is small, consumes virtually no CPU cycles or hard drive space, but maintains a ready supply of fresh and completed blocks for all computers on your network.

or, if all the computers have internet access, just let them run standalone. They can all have the same INI file, just be careful not to copy the same input buffer to each new client or they will all crack the same set of blocks initially.

 

[BGod]

BlueWeasel, One of my assimilations has a set up just like yours.

His main machine holds all the blocks and spends the most time connected to the net. I set the buffer level on that machine to 4,096. Try to always use a number that's divisable by 32, that way you always get bigger blocks.

The main machine has it's D.net folder shared with FULL ACCESS. You can't use a password or the second machine will never find blocks in that folder. Install the client on both machines, but configure the one that doesn't connect to the internet much to use your main machine's folder as the remote buffer. All blocks completed by the second machine will be flushed through your main machine.

Make sure you've got the correct network path typed into the configuration of your second machine. The easiest way to find it is to open Network Neighborhood and click your way into the folder until you get something like this in the Address bar: \\Dually\d\dnet. The other thing you'll have to set up is to use remote buffers, and disable buffer updates to/from a keyserver. That way all the blocks will get flushed to your main machine.

I ran 6 machines this way myself, so I know it works. My main machine ran the client out of the machine that stored the blocks (via the network) and never had the client actually installed on it. That way when I connected to the Internet it would flush the blocks. The machine that actually held the blocks ran out of it's own buffer and the other 4 machines used remote buffers. I only had the buffer file lock up on me once, and it was my own stupidity that did it. I was trying to import buffer files off of a floppy disk and I got my in buffer too big.

I wouldn't worry about locking up the buffer file if I was you, or about locking it up during a reboot. The new clients are very smart. If the buffer file isn't there when it needs to fetch/flush it will just sit on the blocks until it can make the connection.

GOOD LUCK 😀

 

[BlueWeasel]

Thanks Everyone for the suggestions.

Bgod: I did exactly as you said and it seems to work great. My second computer tells me it is cracking the same amount of packets as in my buffer file on the main computer. In other words, the second computer can see the appropriate files and seems to be going to work - rather slowly compared to my main computer (850 Cel. vs 450 K6-3), but more cracking none the less.

I will let you know how it does. . . .