5 expanded posts ยท every known parent and child
Couldn't one take advantage of the 50.000 mistake, by setting up a second server for that space. I guess things will screw up when the first server reaches FFFF, as indicated earlier. What would be nice is if one could divide up the key between servers also. Another thing that might decrease the load on the server is if we start allocating more blocks at a time, lets say 2-4 blocks each time. Wouldn't that help? /Christian
> > Another thing that might decrease the load on the server > is if we start allocating more blocks at a time, lets > say 2-4 blocks each time. Wouldn't that help? > I've been trying to report via WWW for almost 20 minutes... Yikes!
> Couldn't one take advantage of the 50.000 mistake, by > setting up a second server for that space. The design of the prtotocol assumes a hierarchy -- maybe in the next attempt. Static partitioning would be possible (e.g. 0000-7ffff and 8000-ffff) but there are problems with acking to the right server, deciding which to contact, etc. > I guess things will screw up when the first server reaches > FFFF, as indicated earlier. Yup. > What would be nice is if one could divide up the key > between servers also. Hierarchy or static ? > Another thing that might decrease the load on the server > is if we start allocating more blocks at a time, lets > say 2-4 blocks each time. Wouldn't that help? I think most of the load is "HELO COMM QUIT" clients. Yes -- we had thought of upping the allocation ....
| The design of the prtotocol assumes a hierarchy -- maybe in the next attempt. Ok, neat. I was merely thinking of a simple static partitioning of it right now. | but there are problems with acking to the right server, deciding which to | contact, etc. I was rather thinking of a simplistic solution right now, looking in the log of active calculators, roughly dividing them up into two similarly sized groups etc. But I guess this isn't as easy as I thought it would be. | > Another thing that might decrease the load on the server | > is if we start allocating more blocks at a time, lets | > say 2-4 blocks each time. Wouldn't that help? | | I think most of the load is "HELO COMM QUIT" clients. | Yes -- we had thought of upping the allocation .... Ok. /Christian
On Thu Aug 24 19:00:15 1995: you scribbled... > > > Couldn't one take advantage of the 50.000 mistake, by > > setting up a second server for that space. > > The design of the prtotocol assumes a hierarchy -- maybe in the next attempt. > > Static partitioning would be possible (e.g. 0000-7ffff and 8000-ffff) > but there are problems with acking to the right server, deciding which to > contact, etc. It would probably be best to have the "child" servers requeset large chunnks of keyspace from a "parent" server. This may require some minimal extension to the protocol. In particular, in the helo, you may want to add a "client type" field which would be either "Client" or "Server". If it's a "Server" the parent server would keep track of the name/ip of the "child" server. If someone tried to ack a set of keyspace that the "child" server was responsible for, the "parent" server would return either a 601 STOP <child server/port> or perhaps a new return code such as 602 ACKHERE <child server/port> The 602 code would differ from the 601 code stop in that the client could come back to either server in the future. This would let a real "Client" could request keys from any server, but would have to ack back to the same server. When the "child" server runs out of keyspace, it would get some more from it's "parent" server. Just my $0.02. ...alex...