I ran into an issue where I was unable to run more than one system test at a time without the second (and all other tests) failing. These particular tests involved starting an HTTP server to act as the external API that the application would interact with during the course of the tests. The problem was that after the first test completed, the HTTP server would fail to start, getting an “address already in use” error.
I’ve made several toy games with friends, but whenever it came around to adding some simple multiplayer support, getting the networking running was always a royal pain. It seemed like each game had so many special cases for how game-state needed to be synchronized between players that it was impossible to decouple the netcode from the game logic. I wished for a network library that could handle all the state synchronization for me, but I could never find one.
The trouble is that most existing “game networking libraries” are actually mostly data transport protocols (built over UDP). These help ship the data to its destination more responsively than TCP and more reliably than UDP, but usually don’t help much with the coordination/synchronization of game-state between players. So I decided to make one myself! And I did! (It only took me 3 years; turns out it’s kinda tricky.)
I find that when writing applications for Mac OS and especially iOS, it’s quite common to need to interface with a simple REST web service that delivers JSON payloads. Unfortunately, Cocoa’s networking APIs can be a bit cumbersome. To address this for my own needs, I wrote a simple asynchronous wrapper around NSURLConnection a few years ago. As needed, I’ve evolved it to take advantage of new Objective-C features, and I’m finally making it available on github in the hope that others may find it useful.
A quick list of features:
- Asynchronous transfer
- Block-based API
- Automatically parses and encodes JSON
- Compatible with Mac OS & iOS
Recently, Mike English and I needed to set up a rather simple network share which could be used for storing and sharing documents, image artifacts, and large binary files. This was to replace our previous network share solution which I inadvertently rendered unusable after a system software upgrade. We intended the network share to be fully accessible to everyone on our internal LAN, without the need to authenticate.
Our operating system of choice was Ubuntu 10.04 LTS. The plan was to use NFS to allow clients to retrieve and place files. After some progress, however, it became clear that NFS alone wouldn’t fulfill our needs. Most clients to the network share were Mac boxes (which historically haven’t played nice with NFS), and a few Windows boxes (which do not come with a built-in NFS client).
Read more on Setting Up a Network Share – Part I: NFS…
Justin Kulesza and I have been using Puppet to manage the configuration of some virtualized servers. Recently, we added some modules that introduced unexpected dependency cycles. As we worked to untangle the complex series of dependencies, it became difficult to keep track of just how everything was connected.
In order to make sense of the complex web of chaining relationships, I decided to take advantage of Puppet’s ability to generate DOT graph files of resource relationships. Although it’s still sparsely documented , this option can be specified either on the command line or in puppet.conf.
I love choices! But there are a lot of binary serialization formats out there. I recently surveyed them for a project with fairly loose requirements for transferring text and binary messages between servers and embedded devices.
The result was a list of most of the available binary serialization formats and libraries, with comments on each. I’ll spoil the ending and say that for the project in question, we chose MessagePack. But along the way I learned how little I knew of this list before I really dug in to the task. I’m certain the research will come in handy some day when I need to make the same choice with different constraints, and maybe it can help you make your own choices, or at least know where to start.