I never really cared about networking much beyond that needed to make sure clients on a lan can talk to their dns server… but we’ve been growing enough here at work that the needs quickly outpaced my prior skillset. And since I was the closest thing we had to a network admin, I got signed up for classes

It’s been fun and profoundly enlightening. I didn’t expect to have my way of thinking so radically altered, but I’m hardly complaining.

I’ll be starting up the second class in a week or two. This’ll include such topics as VLANs, IPv6, and fancy routing protocols. I’m stoked.

It’s funny. I never finished college (though I took classes for roughly 10 years), so this is actually the first certificate of education I’ve received since highschool.

The comment was made at work that I’d dinged as a sysadmin. I haven’t. I’m just cherry picking my next few levels in netadmin

Well, it's been months since I promised to post some usable socket policy service code, so I will.

The script here is meant to serve as a good starting point for people whose servers need to allow flash clients to make socket connections. I have not actually used this exact code in a production environment, but I have been using code that is 99% identical for a while now. I am confident that any blatant flaws are the result of simple copy-paste errors as I compiled the package. Please let me know if you find any.

I have however, stress tested the heck out of this service. One instance successfully served up over 16000 policy file requests fed into it as rapidly as I could send them. The same networking code has also handled requests from at least 100 different hosts at roughly the same time.

Everything has been combined into a single cli php script that requires no special installation. Just plop it down on the server and run it as root. It will take care of the rest. The config defaults should be safe, but you probably want to specify them more clearly - just to be safe.

The daemon is made of three classes:

• Logger - A rudimentary log file management class that I copy from project to project in one form or another. The included version is stripped down from some of the other versions I've written, and I'm planning on releasing a more feature-rich version in the future.
• Daemon - A simple class for daemonizing a process. Adapted and re-adapted countless times from an original php4 class I found on the net a few years ago by some guy named Seth (whose email domain no longer exists).
• FlashPolicyService - The meat and potatoes, a child of Daemon. Mostly, this is just the requisite networking code and glue to make everything work together.

As with any of my other code, this is licensed under CC Attribution 3.0.

Download:

• FlashPolicyService-09c.zip (4.4kb)

Source code after the jump.

Last week, Adobe finally released some help for people who need to provide socket policy services. They've got python and perl versions of the socket policy daemon that look like they can run either standalone or through xinetd. They don't claim that the code is production quality yet... but it's at least something.

Of course, I released sample PHP code 5 months ago... shrug.

My confederates and I have spent the intervening months sniffing packets, yelling at flash, rewriting daemons, etc... until settling upon a version of the service that appears to function reliably now. I am currently running it on 6 different servers and have seen it successfully handle requests from >100 simultaneous users during stress tests.

The biggest problem with my previous versions of the code was how I handled closing of connections. Previously, I had simply accepted connections and fired off the policy xml without waiting for a request from the client.

This worked 95% of the time over a good net connection, and more like 80% of the time over a poor connection.

The reason it didn't work consistently was because of weird tcp ordering issues. Connections would be closed out of order, the response would be received before the request was dispatched, etc..

My new version is much more robust and actually waits for flash to submit the request before sending the XML. I consider it release candidate beta quality code and hope to be able to release it later today.

update

Version 0.9.b is available now.

I'd been running pre-release nightly builds of the player since 9,0,60,x... and had noticed some strange warnings. Mysterious "Socket Security Error #2048" exceptions that were being thrown at random - even though I was serving an appropriate (for the time) crossdomain.xml file, unexplained timeouts attempting to talk to an xml socket server when I was very clearly not attempting to do any such thing, etc... My regularly repeated attempts to find documentation on what the warnings actually meant proved fruitless. I believe that is because the appropriate document was not actually released to the public until 9,0,115,0 was released.

Now, the bit where they improved the format for crossdomain.xml files doesn't really affect me one way or the other. I approve of the improvements but could really care less in this case. They don't really affect anything I'm doing.

The part that really chaps my hide is the fact that they've completely redone the way that socket security policies are handled. The important parts:

• A SWF file may no longer make a socket connection to its own domain without a socket policy file. Prior to version 9,0,115,0, a SWF file was permitted to make socket connections to ports 1024 or greater in its own domain without a policy file.
• HTTP policy files may no longer be used to authorize socket connections. Prior to version 9,0,115,0, an HTTP policy file, served from the master location of /crossdomain.xml on port 80, could be used to authorize a socket connection to any port 1024 or greater on the same host.

That's right. Your socket policy data can't live in the sitewide crossdomain.xml file that Apache serves any more.

Flash Player 9,0,115,0 introduces a concept of socket master policy files, which are served from the fixed TCP port number 843.

Socket policy files may be obtained from the same port as a main connection (the socket connection being made by ActionScript, which is authorized by a socket policy file), or from a different port, separate from the main connection. If you opt to serve a socket policy file from the same port as a main connection, the server listening on that port must understand socket policy file requests (which are indicated by a transmission of from Flash Player), and must respond differently for policy file requests and main connection requests.

• When a SWF file attempts to make a socket connection, even to its own domain, Flash Player will first attempt to contact port 843 to see if the host is serving a socket master policy file.

So... regardless of whether you're even using a custom port 843 client, the Flash Player is going to try to hit it. What if your firewall doesn't allow/route traffic to sub-1024 ports w/o special configuration? What if you don't have the access to bind to a sub-1024 port and can't rewrite your other server process to serve the policy data on its port?

• Socket meta-policies can only be declared in a socket master policy file. The syntax is the same as for declaring a meta-policy in an URL master policy file, using the <site-control> tag. Socket meta-policies cannot be declared in HTTP response headers, as HTTP is not involved.

This implies that you can't even tell apache to listen to port 843 and serve up the data. You HAVE to either maintain a separate server process specifically for the purpose of serving this policy data, or you have to edit the process that SWF's are connecting to and make them serve the data..

As of the time of this writing (10 days after moviestar's release), they have yet to release promised help on how to deploy a solution to these new changes. Granted, the one article they did release explains what needs to be done in high level terms. It was sufficient to help me out. I wrote a server that simply listens on port 843 and spews the required xml. But... I'd have really appreciated specific examples, and I suspect plenty of people would appreciate drop-in solutions to the issue.

A 5-minute skeleton implementation (not recommended for production use by any means) written as a PHP cli script might look something like this:

#!/usr/bin/php
<?
/**
 * Ugly Flash socket policy file service. This script must be run as root from
 * the command line. It binds to port 843 on all interfaces and waits
 * indefinitely for connections. When a connection is detected, the script spits
 * out a chunk of xml and disconnects. It can only serve one request at a time,
 * but that shouldn't be much of a problem.
 *
 * One potential problem with this script is that you can easily lock port 843
 * up for an indeterminate amount of time if the script doesn't exit cleanly.
 * The OS should clear the port up for you eventually, but you could be stuck
 * playing the waiting game.
 *
 * This particular version of the script has only been tested very lightly.
 * Deploy at your own peril YMMV.
 *
 * - Ammon Lauritzen [12/13/07]
 */

// define the xml policy "file"
$policy_file =
    '<'.'?xml version="1.0" encoding="UTF-8"?'.'>'.
    '<cross-domain-policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.adobe.com/xml/schemas/PolicyFileSocket.xsd">'.
        '<allow-access-from domain="*" to-ports="*" secure="false" />'.
        '<site-control permitted-cross-domain-policies="master-only" />'.
    '</cross-domain-policy>';

// make sure everything launches correctly
if( posix_getuid() != 0 )
    die( "You must run this script as root.\\\n" );

$sock = @socket_create( AF_INET, SOCK_STREAM, SOL_TCP );
if( !$sock )
    die( "Unable to create socket.\\\n" );

$succ = @socket_bind( $sock, "0.0.0.0", 843 );
if( !$succ )
    die( "Unable to bind to port 843.\\\n" );

$succ = @socket_listen( $sock );
if( !$succ )
    die( "Unable to start listening.\\\n" );

// start serving policies
while( true ) {
    $r = $w = $e = array( $sock );
    if( @socket_select( $r, $w, $e, null ) !== false ) {
        $conn = @socket_accept( $sock );
        if( $conn !== false ) {
            // somebody connected, just dump the xml and close
            socket_write( $conn, $policy_file );
            socket_close( $conn );
        } else {
            echo "socket_accept() failed?\\\n";
            break;
        }
    } else {
        echo "socket_select() failed?\\\n";
        break;
    }
}// end: listen forever

// clean up
socket_close( $sock );
?>

I'll try to make my production version of this a bit more suitable for public consumption and release it as soon as I can.

The random #2048 security errors continue, despite having deployed my port 843 policy xml server. Granted, they happen less than before... but they still happen. And even when my policy server isn't running, the errors aren't thrown 100% of the time. This just baffles me. If they were consistent, that would be one thing. But when you get a security error 1 time in 20... that's not security, that's not even a lame deterrent. It's just incentive to hammer the same port over and over again until something finally gives.

Now, I admit that I could be wrong here... but I've re-re-read the documentation on these policies a few times now, and cannot find any reason for the behaviors I'm seeing.

update

On April 22nd, 2008, I released a much better, much more reliable version of this daemon. Head over there for more details and source code.

Yes, I know you can do this via cURL. This was explicitly written for a case when that particular luxury was not available to me.

So... it's been a while since I've written a post, and I'm feeling the withdrawals. I've got 16 half-written posts waiting in the queue and two more that I want to write but haven't even started. It's also time for another round of anime reviews; I've got two video games I want to review...

And I am having to play the "too busy with RL" card.

In stead, I present a function that I wrote this morning. It's been done countless times before, and you can probably find incredibly similar code out there already, but it's the first time I've ever actually needed something quite like this.

/**
 * Send post data somewhere
 *
 * @param $host The domain name of the host to send the data to.
 * @param $path The path of the script to receive the post.
 * @param $data An array of key/value pairs to send.
 * @return       The HTTP response, headers and all.
 */
function http_post( $host, $path, $data ) {
    // build a query string from the data array
    $arr = array();
    foreach( $data as $key =&gt; $val )
        array_push( $arr, &quot;$key=&quot;.urlencode($val) );
    $data = implode( &quot;&amp;&quot;, $arr );
    // send that post
    $fh = fsockopen( $host, 80 );
    fwrite( $fh, &quot;POST $path HTTP/1.1\\\r\\\n&quot; );
    fwrite( $fh, &quot;Host: $host\\\r\\\n&quot; );
    fwrite( $fh, &quot;Content-type: application/x-www-form-urlencoded\\\r\\\n&quot; );
    fwrite( $fh, &quot;Content-length: &quot;.strlen($data).&quot;\\\r\\\n&quot; );
    fwrite( $fh, &quot;Connection: close\\\r\\\n\\\r\\\n&quot; );
    fwrite( $fh, $data );
    // get the response
    while( !feof($fh) )
        $buf .= fgets( $fh );
    fclose( $fh );
    return $buf;
}// end: http_post

This method could easily be modified to send GET data or to talk over a different port. It could also probably actually do something with the response buffer (check for 200, etc...). It could be a bit more fault tolerant, etc... but that's not what I need for the application at hand.

For other examples of how people have done similar/related things, take a look at the comments on the fsockopen() documentation page.

Pieces of the puzzle:

• Flash 9 has binary TCP socket support, but no UDP.
• Standalone projectors like MDM Zinc can add UDP capabilities to the mix.
• A projector and a SWF in the browser can communicate together very happily via the LocalConnection interface.

But web browsers are understandably reluctant to download and run a 3rd party UDP proxy application for you It's also not terribly platform independent to require something running in userspace outside of the VM.

Java has UDP support. You could write a UDP proxy in Java that uses a standard local TCP socket to talk to the SWF - both the SWF and the applet would have to load from the same page. Don't know whether Java's and Flash's security policies would allow this sort of behavior... probably not. I know applets have difficulties connecting to anything but the originating server - so they probably can't listen for traffic on the local host either. And if they can, there's probably some big security certificate you have to sign in blood and offer to the Sun gods or something...

Of course, the dumb option would be to have a remote TCP->UDP proxy... but that eliminates any sort of performance gain that might have been achieved by using UDP in the first place, so that's only valid in the weird case where you honestly need to talk to a UDP server for whatever reason and don't care about the lag.

No, the proxy must run locally, somehow.

Our current situation has computers in 3 rooms of the house: my office, wife's computer in our bedroom, and the PS3 in the living room. Oh, and the laptop, whenever it's turned on.

Well, we've been using wireless for maybe two years now - and through two wireless routers. We initially got an old D-Link router to go with our first cable modem, but it got fried during a power outage in our apartment (I'd neglected to put it on any sort of power conditioner). Much of the networking hardware died in that. Actually, that was my second wholesale networking hardware failure - the first one happened at our first apartment when (I am guessing) a spike came over the phone line of all things (fried dsl router and the switch it was plugged into).

Anyhow.

The cheap old D-Link 802.11g router was replaced by a Linksys model, since it matched my new modem. They stacked together, which I thought was neat... but it turned out to be a terrible problem. We've been suffering with the easily overheated router and modem for a while now without many problems, but then we moved into the new house.

Heat no longer was a problem, my office is huge. I have plenty of room to put the modem and router on opposite ends of their little shelf and not feel bad about it.

The problem in the new place is the relative position of my bedroom with respect to the office. Or, more appropriately, the position of the master bathroom and all of its glorious plumbing (2-head shower, hot tub ) in between the two

Tarma, my wife's machine, was using a little usb Linksys wifi adaptor, but it just couldn't get strong enough of a signal through all of the plumbing to be useful. So we bought her a new PCI card and plugged a ginormous antenna into it. And that worked, for a while, until the strain of a heavy antenna combined with an extended period of moving the machine around and fiddling with things broke the connector loose. It still works fine, but you have to jam it in there. I can probably just solder it in place, but I've been kind of lazy - and don't remember where my soldering stuff is packed anyway

And, we could have lived with that. The computer was stable and wasn't being moved around any more. Even with the connector loose, the big antenna meant that it could get 40-60% signal through all of the plumbing, except when water was running. Then she gets booted.

No, the last straw was our wireless router (the one that liked to overheat) finally giving up on talking to the modem. It... just refused to acquire an IP address any more. Modem's fine. ISP is fine. All of the computers in the house are fine. The LAN ports and wireless on the router are fine... but it simply ceased to be useful at actually talking to the internet. And that's no good.

So, thusly convinced that something needed to be done to feed her addiction, my wife approved the acquisition of some new networking hardware.

And when I arrived at the local emporium of all things expensive and electronic, I decided that 802.11n didn't sound like all that bad of an idea. It's backwards compatible with G (and B, for whatever that matters any more), and promises something like 6x the throughput and substantially higher signal range. Better signal means better chance of blasting through the hot tub...

So I bought a D-Link DIR-655 router and DWA-552 nic for Penny's machine. Set the router up, it worked flawlessly. It's got a decent admin interface, and all of my old 802.11g devices talk to it wonderfully. It also doesn't hurt that the wired ports are gigabit, which means the machines in my office are now talking to each other at the speed their ethernet adaptors intended

One thing I do like about the router is that it is capable of running a network in both WPA and WPA2 modes at once. This means that most of my machines are WPA2 encrypted, but those devices that don't quite support it (like the Playstation...) are at least able to fall back and use WPA. Say what you will about possibly questionable security practices, but I think that this is a fabulous solution - it gives me the highest security realistically available on every device on my network w/o having to spend gobs of money.

So, network upgraded, and all legacy clients confirmed to be operating with better signal quality and security options, it was time to tackle Penny's machine. This computer has been nothing but trouble since the day we got it. It has heat issues, it has power supply issues, it has WinXP MCE issues, etc... but, it's still a generally functional system and it still works like a TV+TiVo in our bedroom.

I popped the new NIC into the box and fired it up. Drivers were installed from the disk and networks were identified. Signal strength meter comes up - full bars. Connection speed identified itself at 300Mbit. Penny was filling the tub for Alanna at the time. I considered that a success at the time and called it a night.

Well, the following day, Penny started having stability problems with the machine. Nothing unusual about that. I look at Tarma funny and the audio decides to start stuttering for a month w/o any explanation and then go back to normal. The box is certainly near the top of my list of problem children over the years.

When I got a chance, I fiddled with the box a bit more, streamlined a few things, ran the obligatory spyware/av/adware battery of scans. Nothing came up, machine was clean. It... just lagged beyond reason. I took a look at the task manager and the cpu load was reported to never really drop below 90%, yet the box wasn't actually doing anything. 'System idle processes' were reported to be reliably occupying >80% of the processor's time.

My first thought was that it was the new wireless card, but it worked fine... it never lost signal, file transfers and net access worked fine. The machine itself was just so slow that we couldn't ever see anything like a decent transfer rate (so no streaming video from the file server). It couldn't even play the videos off of the hard drive any more. Heaven forbid you tried to watch television.

After a bit more pondering and discussing the problem with my father and with Danny, I decided to disable to network card and see if it was just the drivers pegging the cpu.

I finally did that tonight.

The instant the interface was disabled, the system load dropped to nil. I turned the device on, and load skyrocketed back to well over 90%.

A bit of very lazy searching didn't turn up anyone else reporting this problem. And I'd sat on the problem for too long to expect a return on the device from the store... so I decided to check if there were any new drivers.

Sure enough, D-Link had released a new driver last week. (Actually, the version number was several up from what came on the disc with my card, so I'll assume they'd released a few versions in the interim as well). I installed the new driver, and not only did it upgrade things to 802.11n draft 2.0 (from the draft 1 advertised on the box), it fixed the system load problem. I successfully streamed a 1.3gb video w/o a hitch.

I also upgraded the router's firmware at the same time, and haven't noticed any changes in its behavior, but the firmware upgrade process was painless and upgraded it to using draft 2 as well.

I'm happy. Penny's happy. Alanna'd prolly be happy too if she knew what the whole fuss had been about

I'm kind of annoyed at myself that I didn't check for new drivers and firmware the minute I installed the devices, but oh well. It works now, and I'm not out $100 for an unusable network card after all. (The Linksys card with the loose antenna connector will probably be put into service elsewhere, I'm just not sure where yet).

And yes, I know the syntax hiliting could be better. I'm looking into switching over to WordPress and a new stylesheet, so hopefully this sort of thing will all be resolved in the nearish future.

FlexUnit

FlexUnit is a powerful unit testing framework for as3/flex2 projects. There are two API's out there called FlexUnit, one is a SourceForge project and one is official from Adobe. The SF project is ancient and unmaintained, I will be referring to the official API.

FlexUnit also has some competition from the AsUnit project, but seems to be slightly less well suiteded for our needs when testing AS3 projects. It does, however, seem to offer fairly good support for AS2 projects. The two frameworks are generally very similar and switching between them should be fairly painless if necessary as they both evolved from and are modeled after JUnit, the industry standard for unit testing in Java.

FlexUnit is available for download from Adobe Labs. You want the zip file.

The official API documentation for FlexUnit is at http://weblogs.macromedia.com/as_libraries/docs/flexunit.

Warning: If your default run target in Flex doesn't use the right flash player version/options, it is entirely possible that your failures might not be documented. Run the swf again in the standalone debugging player and you should get the information you missed. I'm not entirely certain why this is happening but I don't much care at the moment.

Using FlexUnit

To make use of FlexUnit in a Flex 2 project only two bits of prep work need to be done:

• Add the flexunit.swc file (found in the zip on Adobe's site) to your project's library path.
• Create a test runner application in the project. This is Flex, so remember that applications have to be in the root of the project tree.

An example simple test runner (adapted very slightly from Darron Schall's howto post):

Test Cases

The way the framework functions is by running a series of test cases. Each test case is an instance of the TestCase class which may or may not do any number of things. Test cases may also be organized into TestSuites which are little more than a list of test cases which will be run in order if desired. TestSuite.add() may accept either individual TestCase instances or TestSuites.

The constructor for a test case accepts one argument, the name of the method to be called when the test is run. Thus it is possible and advisable to create a single class for each group of related tests and instantiate multiple copies, each instructed to run a different test.

When a test runs it counts the results of all assertion methods called. These methods are:

• AssertEquals()
• AssertFalse()
• AssertNotNull()
• AssertNotUndefined()
• AssertNull()
• AssertStrictlyEquals()
• AssertTrue()
• AssertUndefined()
• fail()

Each of the assertX() methods takes two parameters, a string describing the error to describe if the test fails and a value to be tested.

Fail may be used to throw error messages if you want to perform more complex tests than the prefab asserts provide.

A sample test case class:
[as3]
package test {
import flexunit.framework.TestCase;
import flexunit.framework.TestSuite;

public class SomeTest extends TestCase {

// declaring the redundant constructor saves you from having to cast when you construct
public function SomeTest( methodName:String ) {
super( methodName );
}// end: constructor

// this method returns a suite containing all of the tests provided by this class in
// the order they should be run
public static function suite() : TestSuite {
var ts:TestSuite = new TestSuite();

ts.addTest( new SomeTest( "testA" ) );
ts.addTest( new SomeTest( "testB" ) );
return ts;
}// end: suite

public function testA() : void {
AssertTrue( "True does not equal true?!", true );

var tmp:Object;
AssertNull( "Tmp should be null here.", tmp );
tmp = {};
AssertNotNull( "Tmp shouldn't be null any more.", tmp );
}// end: testA

public function testB() : void {
fail( "This test always fails" );
}// end: testB

}// end: class
}// end: package
[/as3]

Asynchronous Tests

FlexUnit offers good support for asynchronous event-driven test cases. AsUnit apparently has also recently (ie, as of early-mid October, 2006) added this support for AS3 projects.

There are a number of asynchronous methods that tests can call but the actual 1st-party documentation on how to use them is a bit thin. In stead, Adobe refers us to hunt down and comprehend the test cases written for the Mappr API. I've attempted a bit of this comprehension. The only one of their test suites to use asynchronous calls is the MapprServiceTest class.

Even in this case, they're only using one aspect of the functionality. That is the TestCase.addAsync() call. This function looks like it might be enough for what we need, it adds a checkpoint to the queue (and pauses it?) and then returns a proxy function that looks like it should clear the checkpoint and then execute the next function in your list.

The framework looks like it has more robust options than this for writing asynchronous tests, but I believe this is all we need for now.

A sample class that tests loading data from an external source might look something like this:
[as3]
package test
{
import flexunit.framework.TestCase;
import flexunit.framework.TestSuite;
import flash.net.URLLoader;
import flash.net.URLRequest;

public class RemoteXMLTest extends TestCase {
private static var TIMEOUT:int= 10000; // 10 seconds
private var loader:URLLoader;

public function RemoteXMLTest( methodName:String ) {
super( methodName );
}

public static function suite() : TestSuite {
var ts:TestSuite = new TestSuite();
ts.addTest( new RemoteXMLTest("doIt") );
return ts;
}

public function doIt() : void {
var request:URLRequest = new URLRequest("http://somewhere.com");
assertNotNull( "request is null", request );

loader = new URLLoader();
assertNotNull( "loader is null", loader );

loader.addEventListener( "complete", addAsync( onLoaded, TIMEOUT ) );
loader.load( request );
}

public function onLoaded( result:Object ) : void {
// don't actually have to do anything here, but eh, why not?
assertNotUndefined( "we got no result?", result );
}
}
}
[/as3]

We have a total of four computers currently on the network, and in regular use. Of them, Rincewind (the old server turned secondary windows desktop) and Vimes ("my" laptop that Penny monopolizes) generally shun the torrents, letting Hedwig (linux server) and Tarma (windows media center type bedroom computer) handle all the dirty work. Which is fine by them, since they're the machines with the big processors, big ram, and big hard drives (though Rincewind does have a gig of ram and 300gb drive of his own now, shrug).

Traditionally, I have always preferred the command line python scripts to bulky gui applications. So... Hedwig has had a long and only slightly besmirched career as our primary download and redistrobution center.

When Hedwig moved home from the office after I quit my last job, I expected some slowdown - after all, we only have a 5 mbit downstream and 512 kbit upstream. The results of my first batch of downloads led me to believe that the torrent itself was somehow bugged - they were all healthy files with 10 or more seeds and 100 or more general users, yet even after a few hours running, I couldn't manage to eke out more than 5kbps per torrent.

I let this slide for a while in the face of a new problem. One particular studio whose shows I was interested in watching was having problems with their single-episode torrents and recommended people to just use the batch torrents in stead. This is usually fine by me, but in this case, the batches were 25 episodes huge (~4.5gb) and I only needed one file out of the mix.

So, I hunted around for a client that would allow me to selectively download individual files from batch torrents, and was pleased to find BitComet. I installed it on Tarma and fired it up.

Instantly, I noticed a huge difference. BitComet was actually able to utilize my bandwidth and get me transfers at the rates my connection would actually support. It was great. But, I was still running the mud from home and didn't want to lock out players, so I throttled things way back - leaving plenty of bandwidth open for no less than 10 users to do their bidding w/o any problems.

Yet... even with a dedicated portion of the pipe, users suddenly began to complain about inability to log in to the game. Once an active socket was opened, there were no problems, but people were generally incapable of opening said sockets...

About the same time, Penny started complaining from the couch that the laptop was having problems browsing web pages. I noticed that I too began to have problems opening up outgoing connections from any of our machines. I throttled the torrents waay back - leaving 3/4 of our bandwidth unused. And still, the problem did not go away.

I quit BitComet. The problem did not go away. I rebooted Tarma. No such luck there either.

Finally, I gave our router a violent kick to the head and rebooted it forcibly. The network was immediately cleansed and back to normal.

This problem has repeated itself numerous times since that first event. It became so reliable - if I so much as looked at BitComet, my network would sieze up - that I stopped downloading files all together until the mud had left the building. And then, I got into the habit of stopping torrents during the day so I could work, and then turning them back on when I went to sleep. I had assumed that BitComet was somehow opening up so many connections that it managed to exhaust the router's capacity to handle them all.

Until today. [Cue dramatic music and lighting]

The answer (I hope) to all of my woes and problems finally hit me. BitComet was not leaving stale connections around. It has been overheating the router. See... they're both fairly new (<1 year old) Linksys models, and this particular line of networking hardware is designed to stack together, so the router was sitting directly on top of the modem.

I figure the high number of different sockets created when added to the high amount of wan communication and the fact that Tarma is connected to the network via encrypted wifi (high amounts of radio energy plus extra computational power spent on every packet to maintain security) probably generated more heat than anything else I've done to this network.

Since, previously, my high traffic transactions had been mostly one-way communication (sending a file between two machines) and my torrents had been on Hedwig (who is plugged into the network via good old fashioned cat6 twisted pair)... yeah.

When I checked on my torrents this morning (Sousei no Aquarion for Penny), I noticed that they were acting unusually sluggish. Like really really slow. So, since I needed to get onto the web anyways to work on things, I went in to physically reboot the router. It was almost painfully hot to the touch. The modem underneath it was also practically a puddle of molten plastic.

I smacked myself in the head and proceeded to fashion a cardboard stand for the router from the packaging of some Atari computer game or another. There is now at least an inch of airflow between the two devices and I've had torrents running all day w/o interrupting my work.

I can even post rants on here and stuff