March 8, 2012 - Have migrated to a new server, which should help with maintaining full uptime for the webcounters.
August 25, 2011 - Dealing with a hacking attempt from China that may be disrupting the server.
July 7, 2011 - Fixed some preview issues with the heart, flame and netbaby counters. These should now let you
change their colors correctly. The heart counter had some colors transposed, so if you made yours in 2008 or later you
might want to check your colors! If they're off, you can fix them in the editor.
June 9, 2011 - Added some extra URL filtering logic to the counter system, as a lot of malformed counter urls may have been hosing the system. Hopefully things will be more stable now.
December 7, 2010 - The server experienced some downtime as one of the
processes exploded and locked up. Things have been restarted!
May 3, 2010 - Counter service is being impacted by a network routing issue with the server hosting company. IP addresses
are going to be shifted around this month, and the old one for the counter server is not routing properly.
February 7, 2010 - The counters were down for about 10 hours when a support process exploded. Not sure what the issue
December 18, 2009 - The database suffered some corruption this week, and about 424 counter instances were affected,
having their values set to the maximum of 2147483647. For those that haven't had any hits in the previous 7 days, there
is no way to restore them to an accurate value I'm afraid. I will try to restore those that have log records, but can't
promise anything. To avoid generating errors these instances will be reset to 100. Sorry for the inconvenience!
October 14, 2009 - There will be an outage on Sunday, October 18 while the server is moved to
a new datacenter. This can last from a few minutes to a few hours, depending on how tricky the migration
is. All counter data will be backed up Saturday night as a precaution.
June 8, 2008 - There is a network issue at my host that is effecting the counter service,
where connections are not getting through or are being hung. It's being looked into, but may also
be from a denial-of-service type attack.
May 14, 2008 - Policy Change: 'sharing' counters out among multiple people, posting your counter
code for such and 'rebranding' (creating overlay counters, etc. and then just giving out the code) is
cause for account deactivation. These practices are pointless since the 'count' is totalled for all of the
different pages hosting it, and is thus meaningless. If people want to offer custom images for Overlay
counters, that's fine - just give the URL for the picture and point folks here to get their own account
that they have control over.
February 25, 2007 - To get around people simply copying counter URLs and using them on their own
pages (effectively 'stealing' your counter) a new feature has been added: URL Keys. Click on the 'Edit URL Key'
option for a counter, and you can set a string to 'match' against the incoming URL for the page the counter is
being requested from. If the match fails, the counter will not display or record the request. Enter in a domain, directory
path or just a unique substring. Examples are given in the account manager.
February 22, 2007 - There was a glitch in the new setup that had random display options showing up
for some counters, including counts from other accounts. This has been fixed, and the counters won't vanish
after 10,000 hits per day - but the log files will be restricted to under a megabyte each. So tracking info
and other stats won't be recorded beyond a certain point.
February 22, 2007 - As an experiment, I'm limited counters to about 10,000 hits per day to see
how this affects overall performance. Only a few users get more than this, and they tend to get a huge
amount of traffic. So for the time being, once a counter instance's log file exceeds 800K the counter
will simply vanish and be replaced by a blank pixel. I know these counters are popular, but they really
aren't meant to be used for sites getting 50,000 hits per day! Hopefully this will make the system
more responsive for the majority of users while subtly discouraging high-traffic users (generally a few
NeoPets related resource pages).
September 28, 2006 - In an effort to cut down on login issues, the Counter Manager will
September 22, 2006 - Service was down for awhile today due to a nameserver switchover.
It should clear up soon.
August 28, 2006 - Service broke down last night and this morning due to overloading. To
compensate, more database tweaks have been added and the service autotest-and-restart process
checking has been reduced from once every five minutes to once every minute. There are still a
few users generating over 100,000 hits per day - if stability issues come up again I may have
to set a max count-per-day, disallow high traffic pages, or start charging for high counts.
PS: I'm not dead yet - Paul Osze
June 2, 2006 - Due to people being unable to log in (firewalls/blacklists blocking permanent
cookie) the session cookie is back to being a temporary cookie - although logout will still clear
it for people who allow permanent cookies. This should solve all the login difficulties people
have been having.
June 23, 2006 - In an effort to keep things going smoothly, I've implented logfile size
limits in the account manager and count program. This means that after a certain size is reached,
the counter stops writing to the log file and the account manager stops trying to parse them. This
should clear up the locking situation where the account manager was hanging and locking up the
database. Anyone getting over 5000 or so hits a day probably doesn't need to see statistics at
that point. There are perhaps two or three Neopets users generating 90% of all counter activity
June 14, 2006 - Added 'Logout' option in Counter Manager. The session cookie is no longer
a temporary cookie, but it expires in 1 hour. Logout will clear it completely.
June 9, 2006 - All of the log space on the server got used up(!) this afternoon and brought
down the counters. This has been fixed for now (by turning off the webserver log). The issue
came up since some of the Neopets pages are getting upwards of 60,000 hits per day and thus
eating up a lot of space when it comes to the tracking logs. These logs are so huge that the stats
pages in the account manager can't even load them up. There isn't much that can be done though,
short of creating a separate system on a dedicated server just to handle high-activity counters.
May 24, 2006 - The new server locked up this morning and has been rebooted.
5 August, 2005 - The server was locked up this morning and had to be rebooted.
23 April, 2005 - The server locked up today for about six hours and had to be rebooted.
3 March, 2005 - Flame counter update. By request, I've added the option of choosing the color for this counter.
25 January, 2005 - Connections from the 165.21.154.x network
do not appear to be transmitting cookies to the counter server! This may be a side-effect of rerouting done after the loss of a communications
satellite, or just due to a router doing heavy filtering on packets. This primarily affects counter owners in that area
(Singapore/Southeast Asia) who have 'Ignore My Visits' cookies set but are having their visits counted anyway. I'm still
monitoring this to see if other networks are having the same issue, but there really isn't much I can do at this end of
things. Repeat visits from cookie-less connections are based on tracking the IP address, so the 'drift' in the counter
from people visiting their own pages should be minimal until the network is working properly again. Other cookie-based
sites do not seem to be having this problem however, which makes it even more frustrating.
18 May, 2005 - Fixed a glitch in the account manager that wasn't allowing new
counter instances to be created (the new server didn't like mixing query strings and path
info, for some reason). Still trying to get the email functions to work on some of the
12 May, 2004 - It looks like all of the glitches have been worked out and things
are running properly on the new server, including email (I probably lost a few weeks worth
during the changeover). The drop-dead date for converting your counter URLs from the old
IP address is still May 31. I'll try to get an email announcement out this week to the
people still using the old server IP.
8 April, 2004 - I've put 'cgi.boingdragon.com' back into the install instructions.
This is because I'm planning to upgrade the server in the next few months, and the IP
address will probably change as a result. I'll send an email announcement to existing
users who are using the IP address before the changeover though.
12 March, 2004 - Counter response should be quicker now during the mid-day
traffic crunch. I tracked the slow-down to having 20 count processes trying to handle 140
queued requests. I've upped the process count to 50 now. It still puts a high load on the
server, but the response time is faster as there aren't more than 3 requests queued up on
11 March, 2004 - Many of you probably noticed the counters acting wonky for
the past 24 hours. It was likely due to my trying to lock out a specific user account
who was using the same instance on multiple NeoPets shop pages, thus racking up over
10,000 hits a day. I've gone back to the non-blocking version of the counter to fix
things, but I'm still trying to figure out what is causing the high database load
that is slowing down the counter system.
5 March, 2004 - The IP Locator service changed URLs last week, and a user
finally pointed it out to me! I tracked down the new URL though, and now the option
to locate visitors is working again.
5 October, 2003 - I've had to patch the counter system to ignore counters placed on
Neopets market-listing pages, as they were running up huge but essentially meaningless
counts (since 10 shops are listed per page). They will still work on all other Neopets
pages however, including the actual shop pages. I had to do this because the database was
getting too bogged down and causing lags of up to 30 seconds for the counters to appear!
5 August, 2003 - Well, I just tweaked the database to activate the query cache, which
seems to have improved performance a bit! This should better let the system deal with high
traffic websites that generate about one unique hit for every 10 or so repeat hits and get
thousands of hits per day. The system load on the server itself dropped by half after I
activated the cache as well! I'll still be monitoring things to see how overall performance
is affected, and whether or not the error count goes down as well.
29 July, 2003 - It looks like the server is getting bogged down with requests again,
causing counter-image lags up to several minutes! There are a dozen users who are generating
over 2000 hits/day - one close to 20,000! - that are overwhelming the generators. I'm going to
try to switch those accounts to use generators on a second server to ease the load a bit.
14 June, 2003 - Yet another fix! I had to implement auto-expiration on the counter
processes so that they'd each 'die' after handling 5000 counts - then a fresh process would
be spawned to fill in. Apparently letting the same processes run constantly for 5 days
caused them to bog down with high CPU loads.
So, last week the problem was that the processes were being killed too fast, and this week
the problem was that they weren't getting killed and refreshed at all. How's that for irony?
9 June, 2003 - Okay, I've found what's been killing the counter processes: someone
had a counter link to a non-existant account on a high-traffic messageboard page. This was
causing the process to segfault. I've added some more checks to prevent crashes from mangled
URLs (like not having the instance number, etc.), but haven't been able to recreate the
problem with my test processes - so I've created an actual counter to be called by that
page for now. That seems to be working!
Note: Someone asked about special counters for sites like LiveJournal that could capture
the name of the user reading the page. Since that info isn't stored in the page URL, though,
it's not possible to capture. That sort of data is usually stored in a cookie, and the counter
can only read cookies that it issues itself.
7 June, 2003 - I still haven't worked out exactly what's been killing the counter
service for the past few days, since there doesn't seem to be any unusual traffic or
strain on the system. I've recompiled the service to use the latest libraries and am
now running it with static binaries in case there was a memory leakage problem.
The account manager is now back to running as regular CGI, since the FastCGI version
had strange problems. Hopefully the login issues won't cause problems again though.
4 June, 2003 - The counter database has been overloading, causing the processes
to lock up. I've implemented more count processes and upped the check cycle to every
minute to make sure enough are running, and I'll be upgrading the database this weekend
as well. The account manager has also been acting up a little as well, so I may switch
it back to the straight CGI version instead of FastCGI.
Addendum, 9:30pm: MySQL 4.0 is now running. Hopefully it will be able to
handle the counters without the problems of the last few days.
22 May, 2003 - Follow up to last entry: it looks like there is one user who is
generating about 30,000 hits/day, which may be the cause of the database overload. While
the high load does not affect the counters themselves, which have dedicated persistent
connections, it does make it harder for new connections to be opened for the Account
Manager, which is why so many login attempts are failing.
I've emailed the person with the super-active counter to please remove it from the one
page that's generating so many hits, and I'm going to see if I can get the Account
Manager to work as FastCGI to allow for persistent database connections.
21 May, 2003 - It looks like the MySQL database is getting overloaded, causing
outages in the counter service. I'm looking into possible causes, such as one or more
users just racking up huge amounts of traffic, and will also see about getting Oracle
to see if it runs any better.
5 May, 2003 - The counter management system has been reworked so that users
need to log on initially, but will still be asked for password verification on critical
operations, such as deleting counters, changing the password or editing user information.
25 April, 2003 - I rebooted the server today around 2pm Pacific to clear up some
memory corruption. The database and server had been running for 109 days since the last
reboot and needed to do some housekeeping.
13 April, 2003 -
Two new Wolf counter types have been added! A lot of you keep asking about
wolf counters, so I finally made some new ones. Check them out on Counter Types
page or in 'Add A New Counter' in your Account Manager!
10 February, 2003 -
New navigation has been added to the Account Manager, as well as a new
stats readout: visitor tracking by day! This will let you see user visits
for the last 7 days for all instances, and give you the option to find out
where in the world that visitor came from. New donation options added as
24 September, 2002 -
For whatever reason, the count processes began dying as soon as they
were started up today. I've changed the user they run as, though, which
seems to be keeping them up.
9 September, 2002 -
After a bit of hacking, I've gotten the new server to run the counters off
of its 2nd IP address, since I seperate webpages (Apache server) from the
webcounters (Xitami server) for maximum speed and reliability. There should
no longer be any problems with people behind firewalls not being counted.
In related news, I've gotten some of the image generators for the counters
working as FastCGI, which should also minimize overall load. I eventually hope
to have all counter-related elements running as persistent processes. While the
service is currently only running about 9800 active accounts, I expect these
changes to allow it to scale up to 20K-30K accounts before having to move to
a multi-server solution. At it's height before the DOS-attacks in 1999, I had
about 15,000 users.
21 August, 2002 -
DNS is pretty stable now through Verisign, so I sent out 1,787 emails to counter users
who were using the IP address for their counters to change to the domain instead, to
make things smoother when I eventually move the counters to a new server. Amazingly, only
384 of their email addresses were bad! A mere 21%. Now I just need to search all of their
websites to see if they have updated contact info.
22 July, 2002 -
DNS went down on Saturday or Friday due to a spam-tracking alert. I've switched
nameserver hosts, and hopefully locked down my mailserver so that it can't be
used as a relay anymore. Someone decided that cgi.boingdragon.com would be good
to send their spam through. }:P Hopefully this will be resolved within a few
3 June, 2002 -
I've changed my DNS hosting to the more reliable DynDNS system. This is partly in
anticipation of moving the server to a new provider, so in the near future I will
be sending out emails to older account users advising them to switch their counter
urls from the IP address (126.96.36.199) to the domain (cgi.boingdragon.com). This
will make the transition to a new server easier down the road.
10 May, 2002 -
The color selection pages on the counter manager were hanging while loading, causing
the imagemap for the color-palette to not be loaded! I've rearranged things so that
the colormap loads up and works first, even if the rest of the page hangs a bit.
1 May, 2002 -
After a lot experimenting, I now have the counters set up to cache IP addresses
of visitors to determine whether someone is a unique hit or not in the absence of
a cookie. This will take care of the Internet Explorer 6 issue and general cookie
related problems with some browsers. The visits 'expire' after 2 hours, after which
a visit from the same IP address will be counted as a new visit again.
28 January, 2002 -
The default security settings in IE6 do disable session cookies, resulting
in the re-counting of returning visitors. Since the same feature also prevents
a permanent cookie from being set (except from the counter management page)
I'm working on a way to 'cache' that last few visitor IPs to compare against
the current visitor. This may cause problems due to the way proxy and firewalls
work though, since everyone behind them will appear as the same user.
6 January, 2002 -
Happy New Year! If you use Internet Explorer 6 with default Privacy settings,
please let me know if you encounter problems with counters incrementing on
repeat page views. Reload-blocking is handled via a session cookie, so some
privacy settings will disable it.
3 October, 2001 -
For an as yet unknown reason, the counter webserver (not the machine itself)
died at 5:20 am Eastern this morning. I restarted it at 6:35 pm Eastern, after
trying to figure out what stopped it in the first place. It seems to be working
fine now, though, but I'll keep on digging to see if anything recorded the process
shutting down. While the logs show lots of attempts to access files vulnerable to
the recent Sircam virus, the server itself is immune to it (Xitami, not IIS).
It may end up that after running for 64 days straight, there was just too much
memory garbage. I will be adding a new check process to make sure the server
restarts if it goes down again.
6 August, 2001 -
I went nearly crazy last night trying to figure out why none of the counters
were animating! I checked the server setup, code, logs, everything I could.
Then it occurred to me that I hadn't gotten any email complaints about it. I
recently purchased AdSubtract
to filter out adbanners and pop-ups, since I have a dialup account wanted the
speed savings it provided. Sure enough, when I checked the configuration it was
set to filter Animations, which is why my counters weren't animating! I switched
off that option, and everything worked again.
This isn't really a bug report, I suppose, but thought it would be handy for
those out there who might be using ad-filters as well and notice problems with
22 August, 2001 -
Email is working from the counter server again! I'll be running a script to
send out the registration notice to everyone again, just to make sure the
people that registered during the email 'blackout' get their info.
options editing page that was keeping counters setup with it from displaying
21 August, 2001 -
Don't Panic! Some of you probably noticed the PayPal donation button at the
bottom of your counter management page. This doesn't mean the service is in
any danger of going away, it's just that I'm still unemployed and am looking
for anything that helps cover the $295/mo bill for the counter server.
On an unrelated note: I'm not getting domain-lookup error mails when the
registration page isn't able to find a user's email domain, but I know that
some of those emails aren't getting out! I'll try to track down the DNS
glitch again today.
16 August, 2001 -
I finally tracked down and fixed a bug that affected caused re-edited counters
to lose their color options when no color changes were made in the edit. Yay!
Now instance names and other options can be changed safely.
31 July, 2001 -
A name-resolution glitch is causing outgoing emails to bounce, so registration
emails may not get out today! The problem seems to be in the network, and not in
the counter server itself, so should be taken care of quickly. If you register
for a counter today and suddenly get an email response, don't be surprised if you
get a second response later in the week as I resend registration notices that may
not have gotten through the first time!
6 July, 2001 -
I've checked the records, and over 300 registration emails to AOL users got
bounced because AOL couldn't resolve 'km-cd.com' in the From address!! I've
switched all the email links in the system over to 'boingdragon.com' in hopes
that this will clear up the problem.
2 July, 2001 -
I finally added a way for people to recover lost passwords or resend themselves
the email describing how to set up their counters; just click on the "Recover lost password or account information." link
6 June, 2001 -
The 7-Day Statistics page for your counters now displays both the unique hits
(the ones that get counted) and the repeat/return hits (the ones that don't get
counted) plus the combined totals. This should help people get a more complete
view of their traffic. The hits-by-url section has also been cleaned up a bit.
5 June, 2001 -
It's taken me awhile to get the interface working, but the new Overlay counter is
now available! This lets you use just about any image as your background, with 3
different font styles to choose from. Vertical or horizontal placement anywhere
you want on the image! (Note: Animated gif backgrounds may not animate in all Netscape
Browsers. I don't know if other browsers have problems with animated cell backgrounds).
Also fixed a bug in the 'Edit Options' feature.
30 May, 2001 -
I've started keeping track of non-unique hits (that is, if a person revisits a
page with a counter on it within the same browser session). While they won't be
counted, they are now being recorded. This way I can show both unique and non-unique
page view statistics. This will be handy for those of us that use the counter on
every page of our websites. Expect the 7-Day Statistics page to show the new
values near the end of next week, so that there will be 7 days of actual data to
12 May, 2001 -
There's a flaky router somewhere that's causing West Coast people to not get through to the
counter server in Florida. It's sporadic, but hopefully will be ironed out soon.
1 May, 2001 -
The Netbaby counter is back again. Go to the Counter Types page to see it.
The next counter I'll be working on will be the Overlay counter.
19 April, 2001 -
The Flag counter has been added! Go to the Counter Types page to see it.
23 March, 2001 -
Updated the downloadable image generators to accept command-line arguments. This will let them work with many
pre-existing counter systems.
16 March, 2001 -
Fixed a recent glitch in the Counter Creation script that was causing creation to fail.
6 March, 2001 -
Added two new secondary nameservers today, so hopefully by next week people won't be
having trouble resolving 'cgi.boingdragon.com'.
Until DNS is working, I've switched things to use the IP address instead, and made sure
the cookies will remain compatible.
2 March, 2001 -
Fixed some issues with Netscape browsers not recognizing the links for adding new counters, and
problems with display settings being unset when editing an existing counter.
7-Day statistics added, showing hits per day for each counter and each recorded URL, as well as
averages for hits per hour.
Fixed some form problems with the Flame and Heart counters, and fixed a glitch in the Flame counter
that kept appending two extra zeros to the end of the count.
1 March, 2001 -
I've seen a few counter entries with the display settings missing and one with the image-generator link missing
something. If you edit your counter and it suddenly doesn't display, please let me know what you tried to edit.
And please, don't mess with the Image Generator URL yet! This is all still Beta, but already I think I'm going
to add another column to the counter database.
For those of you that had your display settings erased somehow, I've restored them to defaults so your counters
will show up again. You can edit them back to the colors you want in the UI.
28 February, 2001 - Everything seems to be working, so I'm opening up the counters for registration
and crossing my fingers!
27 February, 2001 -
The counters will be ready for registration by this weekend! Really! I mean it this time! }:)
I've gotten the counter control functions of the user interface done, gotten them to work whether or not
pages and the install instructions. Oh, and the email with more instructions you get when you register.
What's not going to be in this first version are the counter statistics. You'll be able to see the
current count for all of your counters, but no monthly/weekly/daily/hourly breakdown yet, unless I get really
inspired before Saturday. Or, I could work on getting the Flag counter running again.
Other stuff to do, unrelated to letting people get counters: database replication/failover, log management, general backup,
and setting up downloadable versions of the image-generators.
13 January, 2001 -
I'm still working on the counter management interface, mainly because I've been tied up with research and job
related projects. In order to get out something people can use quickly though, I'm going to release it before
any of the tracking or statistics are available. This way, people can set up their counters and then get the
stats and such later. Instructions will be pretty minimal too, since I don't have time to check out all of the
currently-used page editors. There will be a big disclaimer letting folks know that if they haven't added a
counter before to their page then this one will require a bit of research on their part.
19 December, 2000 -
Previews are ready for Eric Schwartz' Amy the Squirrel, Amy Walking, and Amy Swishing.
16 December, 2000 -
A preview of the counter preferences setup is ready, click to see the Dragon
it fails with, I'll try to put in some work-arounds. This especially applies to older AOL users, WebTV and Amiga
browsers, which I don't have access to at the moment for testing.
In answer to J's question in the guestbook, "Yes, the counter only counts you once per session, and it also checks
for a permanent version of the cookie so you can have your own counter ignore your own visits to your site."
The ability to handle multiple instances in each cookie will be tested soon, when I add a test instance for the
Unicorn. I haven't decided yet if it will also record total hits vs unique hits in the logs. The main problem
with the counter logging right now is that it isn't resolving IP addresses, which kills the 'top 20 visitor domains'
part of the reporting (the older counters had this, and I'm trying to maintain all of the same reporting features).
14 December, 2000 -
Things are stable so far. The unique-visitor cookie is working correctly,
and the random digit-placement is also holding up, so I'm going to start
working on the some of the other counters now (Amy Walking*, Amy Swishing*,
Cat, Faery*, Angel*, Flame, and Unicorn*). I don't know when the Overlay will be ready
again though, as it has the trickiest setup. I'll see if I can get the
color editing page for the dragon working.
* - these counters will have new looks and options.
13 December, 2000 -
Progress! There should be a little dragon counter running at
the bottom of the page, which is my testing one. I still have
to convert over the other counters and set up a management
system for them, but so far so good.
In other news, I've been laid off for December, but should be
working again in January. My DSL line fell through because I'm
too far from the CO }:(
The new dragon counter will have three different options for
digit placement: Weightlifting (all the digits bob up and down at
once with the snores), Hotfoot (the one below, where they jump up
when the fire hits them) and Spinehugger (the digits follow the
curve of the dragon's back). I'm working on a 'random' setting
as well to switch between them.
20 November, 2000 -
The new server is finally online, now I just need to install
all of the counter software again (although I'm still rewriting
it all). I'll be working on it this week and weekend. In other
news, my DSL line will be brought in on December 4, and hopefully
be clean enough once hooked up to let me run a backup server on
it. Wish me luck }:) The new server is a LOT beefier than the old
one, and not dependant on older unsupported versions of Linux.
9 November, 2000 -
Slight (hopefully) delay on things: the counter server is dead!
If the damaged libraries can't be reinstalled by the technicians,
then the system will have to be reinstalled from scratch, wiping
out all of the old counters, and setting me back a bit as I try
to reinstall all of the new components. There were problems with
getting MySQL to install correctly, which probably led to the
I'll be looking into getting a newer server for the counters at
the same time. For now though, the km-cd.com domain is down.
6 November, 2000 -
It's getting close }:) I've got the underlying part of the new
counter technology mostly working, which involves a fast DB,
persistent CGI code and a fast new multi-threaded webserver. I hope
to have the basics done by the end of the week. Since I need to
keep the existing counters running while the new ones come online
though there are still some issues I haven't worked out. Some of
the old counters will no longer be available in their current form,
as I'm switching most of the 'overlay' ones (fairy, unicorn, etc)
back to optimized inline images. I'm also working out features of
the new user interface, such as whether to use frames for certain
especially Amiga browsers, as my own Amiga is in storage right
now so I'm not sure what the latest browsers are like for it. I'll
also be trying to make it more friendly to WebTV users.
At launch, the instructions for different publishing systems will
be rather sparse, and all problems will have to be reported through
a form: I just can't do the same level of email support I had before
the DOS attack last year, since I just don't have that much time.
The counters are going to be limited to 2000 hits/day at first, so
it really counts as a beta test for how much the system can
handle. Later, there will be downloadable local CGI generators that
high-traffic users can run on their own webservers. In the past I've
found that 1% of the users had been responsible for 70% of the traffic,
so this limit shouldn't affect many.
21 March, 2000 -
Update, update, where is the update! Okay, sorry to vanish again,
but things have been hectic. The synflood attack has finally stopped
(coincidentally at the same time Yahoo, CNN, and other big sites
started getting attacked. Bet the FBI wishes they'd done more now) so
I've taken off the firewall. So far so good, and it saves me $95 a month!
Email for km-cd.com is still dead, but I'm hoping to get a new primary
server up and running over a DSL connection soon. I haven't had much
chance to work on the new counter system due to working full time now,
but hopefully I'll be able to start on it again as soon as the new
server is ready (the one the counters currently run on doesn't have
the features needed for some parts of the counter setups, and isn't
easily upgradeable. It was only meant to handle the image generation
half of things).
7 December, 1999 -
The nightmare is nearly over! The counters will be back online
this week, thanks to a rebuilt server and hardware protection
against flood attacks.
The FBI may still try investigating, since the attack is still
actually going on, but I'm not counting on them at this point.
Sorry about not keeping you all more up to date on things, but
since it was likely that the attacker read the update page I
couldn't risk tipping him/her/it off to what was being done.
I'm taking this oppourtunity to upgrade the counters again, so
even though they'll be back up I won't be accepting any new
counter registrations until the new features are in place.
Here's the list of features I'll be adding:
- Multiple instances with unique settings
- This means that you only need to register once, and you
can create new counter instances, change counters, mix cats
and dragons and so on, and view or manage them all on one
- Advanced Statistics on Demand
- Advanced tracking can be assigned to any given counter
instance, as needed. I will no longer be charging for the
advanced tracking features, so long as the server can support
- Problem Report Forms
- This is so I don't have to dig up people's info from their
email address, or make guesses about what software they're using.
- Full and Overlay Options for some counters
- This will let people on eBay, etc, use the faery and angel, etc, again.
- Simplified installation
- Counter urls can end in '.gif' so publishing programs won't choke on them.
I'll also try to embed more information into the headers to prevent publishers
from saving snapshots and browsers to stop caching the images.
- More detailed installation instructions.
- Screen captures of how to add them in various publishing programs.
- Email Confirmation
- You'll have to enter a real email address now, so that instructions can be emailed to you as well.
For the curious, the flood attack began on August 31, and was
directed specifically at the webcounter service as a Denial of
Service attack (a felony in the United States, with high fines
and mandatory jail time). Along with the counters, it brought
down the primary nameserver and webhosting service, costing an
estimated $10,000 in lost revenue. The cost of getting a new
server and trying to defeat the attack has personally cost me
close to $1500.
I still don't know why this person decided to destroy my free
counters, but if I hadn't started a new job in June so as to
be able to afford to fight back it would have succeeded.
My email is still down for now, and I'll try to get things up
and running as soon as possible. Between moving, working full
time, and fighting off the flu I haven't been able to devote
as much time as I used to to the service.