One strategy I've seen is to allocate blocks of IDs at a time. When you connect, grab the "next ID", increment by ten, and then those ten IDs are yours to use in that connection. Go back for more when they're exhausted.

Update: Since you already have a table of next IDs (each row is an ID, independent of the other rows), you could have multiple rows that you go to. Say you make 20 such rows, each with a different ID in it to start. Each process can go to one of those rows, get the ID, and then increment by 20. You can choose a row at random or according to your process ID or something.

Both of these strategies winds up allocating IDs out of order. Also, they basically "put off" the scaling problem by a fixed factor. If you have more than 20 clients, they'll start waiting on each other.

If you want to be able to scale indefinitely, you have to generate your ID some way. Since you have 64 bit integers, maybe you could generate them the old fashioned way. Start with time and $$ (see perlvar) and mix in a per-process serial number.

use English;
# Assumes 16-bit PID and 32-bit time
my $unique_number
    = ($serial_number++ << (16+32))
    + (time << 16)
    + $PID;
[download]