If that was a fair 1d20000 (or 1d30000) on each reload, what are the chances that out of 11686984 throws, only 72 end up matching one particular number? It's obviously rigged.
What CARP/pfsync does is transparent balancing on IP level. Each client connection is redirected to an arbitrary available server. This works for applications where each server can independantly handle a client request, like serving stateless HTTP or DNS from multiple servers.
For SQL, clustering is much more involved. One client might insert data that must propagate to the other server, or locks across all servers must be obtained, etc. This cannot be done transparently on IP level, the servers themselves must support it.
Search for replication, clustering or redundancy together with postgresql, you'll find erserver etc. Except for very special cases (like read-only databases), this way beyond IP level packet filtering;)
Filtering ordinary traffic (not extreme test-cases of minimal packets, average number of packets/connection) statefully at 100Mbps doesn't require much hardware. Even little Soekris boxes (embedded 486 133MHz) can do that.
For Gbps, the limiting factor is the NIC and its driver. Some cards/drivers are reported to reach more than 70% of the maximum throughput. The reason they don't (yet) go further is not packet filtering, though.
If you want specific names/models, the mailing list archives contain the reports.
@openbsd.org addresses are already readily available for harvesters through cvsweb, mailing list archives and usenet gates, putting one in a/. posting couldn't make things any worse.
The upside is that after a certain amount of spam received, people get really good at filtering it. That's where the motivation behind some of the anti-spam features in OpenBSD comes from, I guess:)
Slashdot Mirror
The official release has just happened. Here are the official announcement, the undeadly.org thread and a torrent for the i386 binaries (149MB, matching MD5 which might beat some of the mirrors). Cheers ;)
If that was a fair 1d20000 (or 1d30000) on each reload, what are the chances that out of 11686984 throws, only 72 end up matching one particular number? It's obviously rigged.
There's an inofficial Bittorrent link, just make sure you verify MD5 checksums against those listed on the official ftp server.
Jeremy Andrews from kerneltrap.org has just published an Interview with Ryan McBride, which makes for an excellent read on CARP and pfsync.
For SQL, clustering is much more involved. One client might insert data that must propagate to the other server, or locks across all servers must be obtained, etc. This cannot be done transparently on IP level, the servers themselves must support it.
Search for replication, clustering or redundancy together with postgresql, you'll find erserver etc. Except for very special cases (like read-only databases), this way beyond IP level packet filtering ;)
For Gbps, the limiting factor is the NIC and its driver. Some cards/drivers are reported to reach more than 70% of the maximum throughput. The reason they don't (yet) go further is not packet filtering, though.
If you want specific names/models, the mailing list archives contain the reports.
The upside is that after a certain amount of spam received, people get really good at filtering it. That's where the motivation behind some of the anti-spam features in OpenBSD comes from, I guess :)