Brian Pane

Bad: I lost my work-supplied Blackberry a few days ago.

Good: I alerted the IS/IT folks, and they were able to remotely disable and reset it.

Unseemly: This remote reset, I learned today, didn’t clear emails or calendar entries already on the device.

Good: A good samaritan found the Blackberry and attempted to track down its owner.

Good (from an information security perspective): There was insufficient information on in the device to identify me or the company.

Bad (from an odds-I’d-ever-get-reunited-with-the-Blackberry perspective): There was insufficient information on the device to identify me or the company.

Good: The aforementioned good samaritan called the phone’s own number, in hopes that its voice mail greeting might identify an owner.

Bad: I’d never used that device as a phone.  (I already had a personal cellphone that I liked, so I continued using it for voice after getting the Blackberry.  The Blackberry served only as an email client.)  I’d never set up a voice mail greeting.

Good: The phone number of the Blackberry was previously that of my former boss.  The voice mail greeting for the phone number was still the one he’d created a couple of years prior, directing callers to his personal cellphone number.  (He, too, liked to use a personal phone for voice and a company-supplied phone for work email.)

Bad: The aforementioned former boss had long since moved to the other side of the country to work at another company.

Good: Despite moving across the country, he’d kept the original phone number for his personal cellphone.

The net result of these many arbitrary decisions was that the person who found the Blackberry was able to track me down and return it.

Recently, needing a break from spreadsheets at work, I did some performance testing of lighttpd.  Using an HTTP load generator client without keep-alive connections, I soon ran out of ephemeral port numbers on the Mac that ran the client.  Once the connections in TIME_WAIT cleared up, I could resume load testing for a very short while.

OS X 10.5 has a reasonably large default range for ephemeral port numbers:

net.inet.ip.portrange.hifirst: 49152
net.inet.ip.portrange.hilast: 65535

Other than widening the range, the usual way to support more short-lived connections is to reduce the amount of time that closed connections can spend in TIME_WAIT state.  On Linux, for example, this can be done as:

echo timeout_in_seconds > /proc/sys/net/ipv4/tcp_fin_timeout

It took me a while to find the equivalent setting for OS X, although I did find a few discussion forums where people had asked how to change the TIME_WAIT interval to less than 2MSL and been told it couldn’t be done.

What ended up working for me was to change net.inet.tcp.msl:

$ sysctl net.inet.tcp.msl
net.inet.tcp.msl: 15000
$ sudo sysctl -w net.inet.tcp.msl=1000
net.inet.tcp.msl: 15000 -> 1000

1000ms is too small a value for an Internet-facing system (the default 15 second interval is arguably aggressive enough already), but when testing over a local network it enabled me to do webserver testing at the rate of several thousand new connections per second from one client host.