Potential fastcgi request ID collision

[unix1]

On line 45 of cowboy_fastcgi_handler.erl the line says

RequestId = MicroSecs rem 65535,

where RequestId is subsequently used for uniquely identifying a FastCGI request. However, if I'm reading this right, there's 1 in 65536 chance that current request might have the same ID as the previous one. The likelihood of having a duplicate ID goes up as the number of concurrent requests to the application go up.

Simple but not entirely foolproof solution - just increment the previous ID, then wrap around when you reach 2^16.

[marcelog]

You might have a point and we could use ets:update_counter for such a thing, but a few points can be made:

• The requests have to start at exactly the same microsecond for this to be an issue (which is unlikely, at first). But also, I doubt that under those circumstances this is your main problem, because that would mean that there are way too many requests to deal with in a given second, and can easily exceed the capacity of 65535 requests per worker (it doesn't matter how you'd like to count them because that's the limit per worker, 65535).

• This is only a sample application, with the sole purpose of illustrating how one could use erl_fastcgi, and not a real world application suitable for production :)

[unix1]

The requests have to start at exactly the same microsecond for this to be an issue.

Not necessarily. Just that rem 65535 has to be the same.

that would mean that there are way too many requests to deal with in a given second

The requests don't have to start within the same second (even though they could) for their rem 65535ed IDs to collide.

not a real world application suitable for production

OK. Feel free to do as you see fit with this report. I just noticed and thought I'd point out.