ASP.Net handler request stack

I've got a slightly odd requirement that I'm not sure how to properly articulate.

I essentially want to prioritise the most recent requests to an ASP.Net handler. I'm not sure if this should be client-side or server-side. I'm leaning towards server side to ensure it's enforced on all clients.

So, as requests come in, they're essentially stacked according to some internally-defined time interval, per c开发者_开发百科lient. Then, the top of the stack (most recent) request is processed first.

The reason for this is that the clients will be requesting resources as a user interacts with a client. But the user only cares about the most recent request that's made (think constantly seeking in a streamed file - I want to serve the most recent requests first, since that's where the user will want the media to begin playing).

How should I approach this? I was thinking something like a singleton, that all requests were sent to, and it handled stacking requests from each client, then sent them off to be processed.

I'm after some suggestions for other ways to implement what I'm suggestion (don't have to use a stack). Or pros/cons and pointers for what I've described here.

Update: This may be possible, but it is very difficult to get reliable. I can get the requests to be processed out of order, but they are sometimes missed or not received by the client. I'm starting to think that perhaps this is client-side functionality, rather than server-side. The client should manage requests more carefully.

Eg. implement a monitor/timer that only sends requests when it determines that the user will likely need the resource. This could be after seeking or if the position is change slowly rather than quickly.

This is an interesting theoretical problem so here's how you might do it in very broad strokes:

1. Create a singleton class containing a LIFO stack collection
2. At the beginning of the request pipeline, add a reference to the request thread to the queue.
3. Have the request thread peek the stack collection until the current thread is the next on the queue
4. Pop the thread reference from the Stack and complete the remaining request pipeline.

You'll probably run into some kind of catastrophe with the limited thread pool or race conditions or global thermonuclear war sooner or later, but you should expect that, seeing as you're trying something experimental to begin with.