This sounds like a really interesting project. I'm not sure if the size of the "life" problem is really big enough to warrant the infrastructure you're creating for it, but it's definitely interesting as a proof of concept, in any case :)

As for your questions:

1. It sounds like your main problem in #1 is synchronizing your intercommunicating processes. Each process only wants to take "the next step" when it has results from all of its neighbors for the previous step.

Both of your solutions are essentially "polling": running a relatively tight loop, checking for a condition until something interesting happens. This can suck up CPU time like crazy. It's much more efficient to tell the OS "I'm not doing anything right now; wake me when something interesting happens" so the kernel can give another process use of the CPU. You can do this in a few ways. The easiest way is to continue polling, but put a "sleep" in your loop. This will greatly slow down your process, since the shortest sleep time is 1 second. But it'll give other processes more CPU time. Easiest, not best.

Depending on your design, it may be a Lot better to use select or IO::Select to wait for input from all of your peers. This is more difficult, but also much more efficient. I'd check the IO::Select perldoc and post a followup if you need more help with it.

2. Does tcpdump let you inspect the loopback? If so, there are other tools such as trafshow that may give you similar but more readable information. I'm not really sure on this one.

3. I'm also not sure what to do for debugging. However, I'd suggest creating a test environment and simplifying things while testing. Instead of running 10 interconnected processes, run one process which is connected to a parent test process, just to make sure it works with one peer. Then try having the parent test process open multiple connections to the child, and test that. Once you're sure the child works very well in a sandbox, spawn a bunch of them in an interconnected way and it should be much easier to ferret out the few remaining bugs.

As for particular debugging tools: people seem to like  ddd a lot, and it looks cool from what I've seen, but I haven't spent the time to become very familiar with it. This is probably also very difficult to use with multiple processes.

In any case, if you have all your processes log to the same file, and use file locking on that file so each child's output is sent all at once instead of being interrupted by other children, debugging would be a lot easier than trying to read a streaming STDERR.

I hope this helps :)

Alan