I'm interested in all of - opinions about why this is a good or bad idea - pointers to similar proposals or products that already exist - implementation suggestions This is meant for real time applications that have small available bandwidth and so they have to consider carefully what's the best way to use that bandwidth. I imagine that things happen that cause them to continually reevaluate what's the most important/urgent thing to send next. I want to make it possible for them to delay the choice until the OS is actually ready to send that next packet. The reason they can't do this now is that the OS enqueues packets. Suppose an application uses udp or tcp to tell the OS to send some data. It then discovers that data is obsolete. The old data might still be in the queue to be sent but it's too late to recall it. One way to avoid that is to always delay telling the OS to send something until the OS is almost ready to send the next packet from the queue that your data will enter. But that's not so easy to do, and there's a big penalty if you wait just a little too long. What I want, at least conceptually, is that the application maintains its own queue of data to be sent, ordered by priority. Whenever the OS is ready to send the next packet for that application, it removes the highest priority packet (if any) from the queue and sends it. _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc