Re: [Sks-devel] Introduction + some ideas ...

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Sebastian Urbach wrote, On 10/03/2010 04:02 PM:
...
> 
> Im well known for "direct and plain speaking and get stuff done", so
> lets get started with a few ideas of mine regarding this project. As i
> understand the owner of sks-keyservers-net is also on this list.
>

Indeed so


> Here are a few ideas:
> 

Always appreciate new inputs

> Problem 1:
> 
> Definitely not a good idea to base the server weight on just
> one single probe from your server, probably physically based in the
> United-States. This is resulting in very unrealistic values and is
> getting even worse with every mile further away from the US and seems
> to be unfair for the most servers which are not US based.

Its actually located out of Norway, which is why the SRV weights are
only used for the EU pool as described at
http://sks-keyservers.net/overview-of-pools.php

> 
> Solution:
> 
> Pick a few server on every continent to be redundant (if available) and
> let them do checks right there. So we may get some realistic values.
> This is just a rough plan, details should be figured out if you are
> willing to change the procedure.



> 
> Problem 2:
> 
> Pool checks are, as i understand, just performed once for
> about 12 hours ? If someone has a short problem. lets say reboot or
> something during the check, he will be excluded from the pool for at
> least 12 hours, as it happened with our keyserver a few days ago.

is this really a problem, though? as long as there are sufficient
keyservers in the pool which of the servers is of lesser importance.

> 
> Solution:
> 
> Repeat the test after 5 or 10 minutes or so. That should prevent the
> mentioned situation from above. It shouldnt be that hard on your
> traffic or server load to do that.

I'll consider increasing the update interval. One of the issues is that
I haven't parallelized the process so it runs in sequence. I guess I
have a way to go in the code base for this.

> 
> Problem 3:
> 
> "The key differ value" is just based on your own number +/- afew
> hundred as i recall. That seems to be a problem because the servers
> have very different statistic times in reality and that could be result
> in a difference that is too large by the time your value kicks in.

+/- 500 indeed. But I refer to my comment above, individual servers not
being included is of lesser importance as long as there is sufficient
servers in the pool that are responding timely.

> 
> Solution:
> 
> Just sum up all key numbers from the servers which are in the pool by
> that time and divide it through the number of keyservers. It could be
> posted on the status page so that everbody can read it. Maybe like:
> 
> Total key number (all servers) / number of servers = xyz
> 
> You should be in the range between xyz and xyz keys to be included in
> the pool.
> 
> Finally:
> 
> I know a lot to read but if we want to make some progress it had to be
> discussed. I dont want to tease you, my ideas should be just a
> starting point for a hopefully good contentual discussion and the only
> possibility for that is this list ...
> 
> Have a nice weekend.
> 
> Greetings from the warm and sunny germany which is really confusing
> for this time of the year ;-) 
> 

Just came back from Octoberfest in Munich myself, must admit I found
Lãderhosen to be surprisingly comfortable to wear -  sadly it was more
cloudy then - The Zurich trip last week otoh was great, sunny and 25C :)

have a nice weekend!

- --
- ----------------------------
Kristian Fiskerstrand
http://www.sumptuouscapital.com
- ----------------------------
Potius sero quam numquam
Better late then never
- ----------------------------
This email was digitally signed using the OpenPGP
standard. If you want to read more about this, visit:
http://www.secure-my-email.com
- ----------------------------
Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)

iQIcBAEBCAAGBQJMqJC3AAoJEAt/i2Dj7frjXAYQAISnZRMwS2lXfvOqIvJjZEVs
ez1jx0LGwad2AnVSFQemDgkN/NyynK4ISbhyD1VphQAjZo/KkBUxaPG/KNendIxM
jpQDLDSznYfyKfTsa6b/jgNZQY1AkNYzxlxDRfHLWNecgXQcVrUuV5NTS8yoPlgx
1KpGBHooyAsOtggBXogOCLjDu68nQuGqVyaqZr8CtFqCjq64qgLhPyW8hFN/xWon
odyqCjQcOpXYDysesrWLtammNBQPtdOopVVp/7usda7jH2ypTZi7wQO4RzgaQrW2
2xt0JY7a2sUqIgYwcEKqhzAOc7qFBX9DLskMwK5olLLH0UZukLVGzbUMypyHukEA
kmkh6GEc45ILa7UzovTRJ7c7m4Izca5YdyKxUkdJ4+pR3PCm+Sb74ukFdEkMz7TF
zMowMCqWpaJFLDPtDqCs4M+KXCEqJGuHjMY34eFaJCUmHNC2XLuUU6w+YY2zPXUb
l3QNjPI3UFo2k3Lg8STtdJbeZAwOp8FQVG9unLIuBsAfinItx1m3Yqg0CiqF9M3a
Wib0WpIuWRPtcZr/DsWap+5bfc7FBY80ldj8GUJ3mw0Rsm4/wwHNNEhEBjv+3aKQ
xaFrfaG0corTnjsZY+czZAtdMenVuFnMBJuUY1ukLovpg0xZFnOwkvtQiEIpSFes
OJRMBcubBf+DTcqTG1Zn
=q4qa
-----END PGP SIGNATURE-----