Cacheboy presentation at AUSNOG

I've just presented on Cacheboy at AUSNOG in Sydney. The feedback so far has been reasonably positive.

There's more information available at http://www.creative.net.au/talks/.

Cacheboy status update

So by and large, the pushing of bits is working quite well. I have a bunch of things to tidy up and a DNS backend to rewrite in C or C++ but that won't stop the bits from being pushed.

Unfortunately what I'm now lacking is US hosts to send traffic from. I still have more Europe and Asian connectivity than North American - and North America is absolutely where I need connectivity the most. Right now I'm only able to push 350-450 megabits of content from North America - and this puts a big, big limit on how much content I can serve overall.

Please contact me as soon as possible if you're interested in hosting a node in North America. I ideally need enough nodes to push between a gigabit and ten gigabits of traffic.

I will be able to start pushing noticable amounts of content out of regional areas once I've sorted out North America. This includes places like Australia, Africa, South America and Eastern Europe. I'd love to be pushing more open source bits out of those locations to keep the transit use low but I just can't do so at the moment.

Canada node online and pushing bits!

The Canada/TORIX node is online thanks to John Nistor at prioritycolo in Toronto, Canada.

Thanks John!

Cacheboy is on WAIX!

Yesterday's traffic from mirror1.au into WAIX:

ASN	MBytes	Requests	% of overall
AS7545	17946.77	7437	29.85	TPG-INTERNET-AP TPG Internet Pty Ltd
AS4802	12973.47	4476	21.58	ASN-IINET iiNet Limited
AS4739	8497.92	2947	14.13	CIX-ADELAIDE-AS Internode Systems Pty Ltd
AS9543	2524.57	1241	4.20	WESTNET-AS-AP Westnet Internet Services
AS4854	2097.32	941	3.49	NETSPACE-AS-AP Netspace Online Systems
AS17746	1881.17	1050	3.13	ORCONINTERNET-NZ-AP Orcon Internet
AS9822	1425.44	456	2.37	AMNET-AU-AP Amnet IT Services Pty Ltd
AS17435	1161.01	411	1.93	WXC-AS-NZ WorldxChange Communications LTD
AS9443	1140.62	701	1.90	INTERNETPRIMUS-AS-AP Primus Telecommunications
AS7657	891.93	1187	1.48	VODAFONE-NZ-NGN-AS Vodafone NZ Ltd.
AS7718	740.74	272	1.23	TRANSACT-SDN-AS TransACT IP Service Provider
AS7543	732.11	423	1.22	PI-AU Pacific Internet (Australia) Pty Ltd
AS24313	527.38	252	0.88	NSW-DET-AS NSW Department of Education and Training
AS9790	436.80	389	0.73	CALLPLUS-NZ-AP CallPlus Services Limited
AS17412	365.13	228	0.61	WOOSHWIRELESSNZ Woosh Wireless
AS17486	349.27	116	0.58	SWIFTEL1-AP People Telecom Pty. Ltd.
AS17808	311.65	248	0.52	VODAFONE-NZ-AP AS number for Vodafone NZ IP Networks
AS24093	303.40	114	0.50	BIGAIR-AP BIGAIR. Multihoming ASN
AS9889	288.85	197	0.48	MAXNET-NZ-AP Auckland
AS17705	282.49	84	0.47	INSPIRENET-AS-AP InSPire Net Ltd

Query content served: 54878.07 mbytes; 23170 requests.
Total content served: 60123.25 mbytes; 28037 requests.

BGP aware DNS

I've just written up the first "test" hack of BGP aware DNS.

The basic logic is simple but evil. I'm simply mapping BGP next-hop to a set of weighted servers. A server is then randomly chosen from this pool.

I'm not doing this for -all- prefixes and POPs - it is only being used for two specific POPs where there is a lot of peering and almost no transit. There are a few issues regarding split horizon BGP/DNS and request routing which I'd like to fully sort out before I enable it for everything. I don't want a quirk to temporarily redirect -all- requests to -one- server cluster!

In any case, the test is working well. I'm serving ~10mbit to WAIX (Western Australia) and ~ 30mbit to TORIX (Toronto, Canada.)

All of the DNS based redirection caveats apply - most certainly that not all client requests to the caches will also be over peering. I'll have to craft some method(s) of tracking this.

Squid-3 isn't a rewrite!

G'day,

There seems to be this strange misconception that Squid-3 is a "rewrite" of Squid in C++. I am not sure where this particular little tidbit gets copy/pasted from but just for the record:

Squid-3 is the continuation of Squid-2.5, made to compile using the GNU C++ compiler. It is not a rewrite.

If Squid-3 -were- a rewrite, and the resultant code -was- as much of a crappy-performing, bastardised C/C++ hybrid, then I'd have suggested the C++ coders in question need to relearn C++. Luckily for them, the codebase is a hybrid of C and C++ because it did just start as a C codebase with bits and pieces part-migrated to C++.

Updates - or why I've not been doing very much

G'day! Cacheboy has been running on autopilot for the last couple of months whilst I've been focusing on paid work and growing my little company. So far (mostly) so good there.

The main issue scaling traffic has been the range request handling in Squid/Lusca, so I've been working on fixing things up "just enough" to make it work in the firefox update environment. I think I've finally figured it out - and figured out the bugs in the range request handling in Squid too! - so I'll push out some updates to the network next week and throw it some more traffic.

I really am hoping to ramp traffic up past the gigabit mark once this is done. We'll just have to see!

Preparation for next release; IPv6 checklist

I've been slowly working on tidying up the codebase before the next snapshot release. I've been avoiding doing further large scale code reorganisation until I'm confident that this codebase is as stable and performs as well as it should.

I'll hopefully have the next stable snapshot online tonight. I'll then re-evaluate where things are at right now and come up with a short-list of things to do over the next couple of weeks. It'll almost certainly be the remainder of the IPv6 preparation work - I'd like to prepare the last few bits of infrastructure for IPv6 - and make certain that is all stable before I start converting the client-side and server-side code to actively using the IPv6 routines.

The current IPv6 shortlist, if I decide to do it:

1. client database code - convert to a radix tree instead of a hash on the IP address; make IPv4/IPv6 agnostic.
2. persistent connection code - up the pconn hash key length to fit the text version of the IPv6 address. I'll worry about migrating the pconn code to a tree later on.
3. Importing the last remaining bits of the IPv6 related code into the internal DNS code.
4. Make sure the internal and external DNS choices both function properly when handling IPv6 addresses for forward and reverse lookups.
5. Import the IP protocol ACL type and IPv6 address ACL types - src6 and dst6.
6. Modify the ACL framework to use the IPv6 datatype instead of "sockaddr_in" and "inaddr" structs; then enable src6/dst6.
7. Make certain the source and destination hostname ACLs function correctly for both IPv4 and IPv6.
8. Test, test, test!

The last time I did a "hack" conversion to support IPv6 client side code I found a number of places which expected a newly-allocated struct to be zero'ed, and thus the "in_addr" embedded inside it to be INADDR_ANY. This caused some crashes to occur in production testing. I'm thus going to hold off on pushing through the IPv6 client side changes (which are actually surprisingly simple once the above is done!) until I've enumerated and fixed all of those particular nightmares.

The IPv6 server-side stuff is a whole different barrel of fun. I'm going to ignore a lot of that for now until I've made certain the client-side code is stable and performing as well as the current IPv4-only code.

I don't even want to think about the FTP related changes that need to occur. I may leave the FTP support IPv4 only until someone asks (nicely) about it. The FTP code is rife with C string pointer manipulations which need to be rewritten to use the provided string primitives. I'd really like to do -that- before I consider upgrading it to handle IPv6.

Anyway. Lots to do, not enough spare time to do it all in.