By default, isconf 4.2.6 (specifically, isconf/Cache.py) has this behavior on the net:
| message type | tx to | |rx from |
| whohas | udp 255.255.255.255 | udp any |
| ihave | udp 255.255.255.255 | udp any |
| sendme | http to ihave src | http from any |
| hereis | http client | http server |
If the IS_NETS file is used, then 4.2.6 has this behavior:
| message type | tx to | |rx from |
| whohas | udp 255.255.255.255 and nets file members | udp any |
| ihave | udp 255.255.255.255 and nets file members | udp any |
| sendme | http to ihave src | http from any |
| hereis | http client | http server |
...in other words, all the 4.2.6 nets file does is add addresses to the broadcast list. We need a way to restrict participation to only members of the nets file, like this:
| message type | tx to | |rx from |
| whohas | udp nets file members | udp nets file members |
| ihave | udp nets file members | udp nets file members |
| sendme | http to ihave src | http from nets file members |
| hereis | http client | http server |
We can do this simply by adding an IS_NOBROADCAST environment variable which shuts off the 255.255.255.255 sendto, and causes checks after recvfrom, and before serving HTTP content, to ensure that the src is also in the nets file (doing netmask arithmetic). We can implement master/slave relationships, even tiered heirarchies, by setting IS_NETS to different files for different hosts in main.cf.
I explored several other alternatives, such as designating master nodes now (rather than later, for quorum counting), and all were more complicated and threatened to create code which would later conflict with the TCP mesh plan.
The only thing this plan doesn't do is allow for certain slaves to be write-only; you'll still be able to check in changes from any host that's listed in any nets file. I think that's a good thing; if you disallow checkins from production then there's always going to be that emergency change that someone had to make which has to somehow get back into the rest of the branch, and can't. The intent of this plan is to constrain network traffic, not to act as a major security measure (though it does help with the latter). For real security and change control workflow we need to be using HMAC and GPG.
XXX TODO:
- describe TCP mesh plan here
- describe SecurityPlan?
