ActiveX can lose events? Java to Socket is much more reliable?

You're right... they make no mention of .Net. But considering they note VB & ActiveX as a way to connect to the service, I get the feeling they haven't really kept their public API up to date.

That being said, my point (that I didn't make clearly) is that if they support socket connections via java and c++, then a socket connection from .net will work just as well. There is no magic sauce to socket communication that makes it language-specific. They may not give you any help troubleshooting a problem if you are building something on .net, but there is no technical barrier preventing you from making the socket calls from a .net application. The Java samples should provide enough information that you could port them to .net.

Ultimately, it probably comes down to what you are most comfortable with. If you are a Java whiz, write it in Java. If you know .Net, you can probably use the Java samples as a basis and go from there creating something amazing. But I would avoid VB & ActiveX not just because they advise against it but because it is a bad choice for a custom app. Especially if you are micro-trading with your solution.... you need responsiveness and sockets will give you the best performance.

That is nearly impossible to predict. It depends on so much... how fast you process events, the specs of the machine it is running on, what else may be running, etc. There are some things you can do to help avoid problems such as making sure your loop which receives the data is fast and tight. So maybe all you do in it is grab the data and push it onto a queue for later processing by a background thread. That way the data exchange is as fast as possible and you push the heavy lifting out of the data exchange.

The same sort of principle applies for any high-data rate application. If there is a risk that it will take longer to process the data than the interval in which the data could arrive, then you have to decouple the process of getting the data (making it high priority) from processing the data (making it low priority). For example, if it took two seconds to process a data packet and the packets arrive every second, then you need two processing threads to handle the data as it arrives. Anything less and your queue would eventually overflow and you would lose data. If setup properly, the issue then boils down to an issue of managing the queue.

If your data rate became too much for regular threads on a multicore processor, then shifting data processing over to a GPU may provide a solution. But at your proposed data rate that doesn't seem like something you would need to do. (Unless you are doing something like a FFT on the data.)

Of course, the complexity of the solution increases as the demand for speed increases. I can only advise you on what the options are, you have to make the evaluation for your project. I do think that if you aren't doing a bunch of heavy processing on a chunk of data, a simple mechanism to receive the data via ActiveX, push it onto a queue, then have a background worker pop the data off the queue and process it would probably work very well for your app and easily handle your proposed data rate. If you are concerned, you can profile your app while it is running and get an idea of actual execution times for each part as it runs.

Hope that helps!
Jason