6

My application pre-fetches a large number of video frames using asynchronous HttpWebRequest requests. So, if there are 100 frames, the prefetcher will request all 100 frames asynchronously, all at once, and process when received back. i.e. it makes 100 asynchronous calls all at once. This can saturate the network card, but that is ok. I want to maximize network bandwidth.

However, while this prefetch is happening, the user may want to view one of the frames. So, let's say they want to view frame 56. Problem is, frames 1 - 100 have already been requested, and are in the pipe, so the request for frame 56 may take a long time to get a response.

What would be nice is if there is some way of re-prioritizing the asynch requests after they have been made. And to push the user request to the front of the queue.

If I can't do this, I suppose I will have to request the frames in batches, so that I can slip in my user request between batches, and avoid timeout.

Any ideas on how to design this properly would be very much appreciated.

Mat
  • 202,337
  • 40
  • 393
  • 406
Jacko
  • 12,665
  • 18
  • 75
  • 126
  • +1, interesting question. I would feel link it's not advised to interact with an async request once it's been fired off, so kinda defeats the purpose a bit. – Alastair Pitts May 13 '11 at 03:17

2 Answers2

1

This is not a programming question but a protocol question. If you use a greedy protocol that saturates the wire then you've effectively closed off even your own options using traditional protocols.

If you reserved a portion of the bandwidth for a second channel, you could use that second channel for individual frames instead of batch frames. To prioritize frames in the second channel in the presence of a saturated NIC you would need quality of service or some other link layer to prioritize traffic.

But we're getting ahead of ourselves. If you want a well-behaved functional application you need to sit down and define a real protocol with advice from protocol experts: NICs, switches, protocols, packet sizes, retry, etc. Once you get that all sorted out then you'll have a programming problem.

Rick Sladkey
  • 33,988
  • 6
  • 71
  • 95
  • Thanks, Rick. I wish I had the luxury of designing my own protocol! Unfortunately, I need to hack something over http. – Jacko May 13 '11 at 17:32
  • @Jacko: Then you can't be so greedy! If you place a hundred orders to the factory that you can't cancel, and then you need a special one in a hurry, you are out of luck unless you can give it priority. So you need to be more careful about placing orders in the first place. – Rick Sladkey May 13 '11 at 17:37
0

Ah, I would use a priority queue or heap to process "packets" of frames. Since you don't want timeout and you also want speed, create frame packets (power of two in size) and associate them with a priority ( Maybe 0 for not requested, 1 for user requested?). That way highest priority packets (user requested) will always be at the front of the queue or top of the heap.

xdevient
  • 56
  • 3