Provide "quality of service" information from the TCP primitives

[AristosQueue (NI)]

When you are generating data from a source and sending it across a TCP connection, it would be useful to be able to get information about when packets are being dropped and resent in the connection. If lots of drops are being detected, a program might be able to slow down the data acquisition or take other action to reduce the amount of information being transmitted to account for the lower bandwidth connection. Currently there is no way to get this information from the TCP primitives.

This idea comes out of the Certified LabVIEW Architect Summit held yesterday and today at NI headquarters in Austin, TX.

[Mr.Mike]

Just to be clear, this is different than Quality of Service control mechanisms for TCP, this is just for TCP status information

[_Chris]

Would be nice, but how do you expect LabVIEW to provide information not exported by the TCP stack? rewrite a TCP stack? add a BDS packet filter and check the ones that have been acknowledged, then LV has to estimate the the internal TCP buffer (which is implementation dependent)? Also dropped packets have different meanings depending on the TCP algorithm (Reno, Vegas, Westwood,...). On OSX the TCP stack returns the needed info. Anyway this is a very interesting topic and I'll be interested to contribute.