   Multiplexing w/ scheduling support to minimize waiting times?
  Hey guys,I'm having some problems coming up with a good way to stop from showing users a "please wait" screen when waiting on large amounts of data. I've tried to deal with sending large amounts of information by multiplexing the one UDP channel I have access to. I've used a thread-scheduling type algorithm to give priorities to "pipes" that are responsible for different things.For example, you could be in the middle of a game, as well as recving another player's profile picture and downloading the midi for that level. Obviously the game-related data here would have a much higher priority than the two other pipes. Once the profile pictures have arrived it'll be put up on the screen, and once the midi has arrived it'll begin playing.This is pretty much all I could think of to deal with this type of problem. It seems like a good solution when you have access to only 1 unreliable channel (for example L2CAP) to the destination. But even if you had access to more than 1 unreliable channel to the destination, I still think this method gives you greater control over the flow of data.My concern comes from the fact that all this extra processing might take away precious cycles from my game. Right now I'm grabbing UDP/L2CAP packets, putting them into the fixed-window system, validating them, copying over to the proper buffer, managing the buffers, figuring out what to reply, putting the reply into the proper pipe, finding which pipe to send next, blah blah blah blah blah. Since I'm working on a limited device, I pretty much need as many cycles as I can get. IMHO this doesn't seem like the most efficient solution. Does anyone know of a faster way to avoid wait times?   
  I separated that kind of data from my normal real-time data. It's actually pretty funny. I do requests on my web server with a PHP file that queries for the data either from my db or from my server. Very efficient since it normally doesn't bother what my server is doing at the moment. Might give you some ideas if you have a web server or another computer.   ;  Network processing deals with on the order of 1 kB/second to 100 kB/second. The memory throughput on a modern machine is on the order of 10 GB/second. That's between five and seven orders of magnitude difference. It's very, very hard to spend enough cycles on processing network packets on a client that it actually shows up in the profile. If you have 1,000 connections in the same place, then the amount of cycles per packet starts mattering. However, processing priority is still worth it; it's one of those features you need, and have to spend to implement right.Btw: if you use separate channels that don't know about each other, they will fight, and you'll get a less predictable gaming experience. Best is to schedule all traffic to the client with a global priority queue, where the real-time data is guaranteed some amount of throughput, and the balance is split on the other takers (and more real-time data, if available).   