-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Roger Hayter wrote:
| Presumed results | | a) The vast bulk of, say, 598 nodes form a functioning network. | | b) The development builds are unlikely to be numerous enough to | damage this network, but, if they do, the build number can be raised | immediately to disenfranchise the harmful build as soon as the signal | is received (see above).
That makes sense. Even with a separate, reasonably large developer network, the true test of a new node would only be in having it interact with the full scale production network. At some point in time you would have to upgrade the production network no matter how conservative your are.
Apart from being able to disenfranchise these potentially harmful nodes (in some controlled manner - what if I start my own 5999 node today?), issues that come to mind for observing and controlling them are:
- - Self-monitoring of correct behavior. Some statistics on for example (ratios of) certain message types could indicate proper or improper behavior. Should a node shut itself down if it exceeds certain boundaries?
- - Protection against harmful or evil nodes. Some of the recent fixes already address this, as have concerns for DoS attacks. If a peer node seems to misbehave, a node can put it on a (temporary) black list. If some buggy nodes can cause this amount of performance degradation, what would a targeted attack be able to achieve?
- - The ability for a user to prevent his production node from interacting with development builds at all. It should interact by default, but I think it's legitimate for users to go for maximum stability and focus on content instead of development. Even if it keeps misery only one extra hop away, it provides the user with some level of control and confidence, while avoiding a split up of the network.
Features like these can be added gradually.
Apart from dreaming about features, I think a slower release rate of development builds and a more structured reporting of their operational statistics could help get more insight in and control over what's happening. By the time I've sort of found out how well release X is doing, we're typically already at release X + 3, making the analysis pretty useless. But maybe I'm just too slow here :-) And it's not that hard to get Bugzilla running.
At the same time, thorough testing of unstable builds in a separate environment (local or non-local) could still eliminate a large number of bugs and ensure that the development versions introduced in the production network aren't too far off. But setting up such an environment, preferably with some automated regression testing, would require a significant effort. I doubt if there's a willingness to make that investment with the limited resources available. (And my own contribution here would mostly be limited to some hardware and bandwidth...).
| c) I thought NG Routing was supposed to be able to work even | surrounded by really stupid nodes, unless they actually DOSed each | other, which 598 probably didn't, so you could carry on developing | NGR on the main network.
But dysfunctional NGR nodes could give their surrounding nodes a hard time of course.
Anyway, a hybrid model with separate, possibly local, development network(s) for getting the worst bugs out, followed by highly controlled insertion of release candidates in the production environment sounds to me like a pragmatic and acceptable way to go.
Thoughts?
Menno
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQE/hCrR9m/IbJq4o8sRAuYaAJ9Cq524YGtGMdyP4pCGOAmTAdFMXgCeK5s9 IY+91nJPrIrt60hbUS3NTyo= =T0Kf -----END PGP SIGNATURE-----
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
