>In your situation, what do you see as the potential advantages of socket programming?
>
>As I understand, it's not well supported across the public Internet. Increasingly, routers and firewalls are only allowing traffic with recognized protocols (http, ftp etc.) Also, it's usually viewed by antivirus software as hack attempts and is blocked by default. To get it to work you usually have to set up firewall and AV exceptions.
>
>You still see this sort of thing occasionally. Some walk-up network printer/copier/scanner (AIO) devices have optional "communications utilities" you can install on PCs on the LAN. You can then set up soft keys on the device, and do things like scan directly to various PCs on the LAN. The PCs are constantly listening for incoming traffic from the device.
>
>As you know, there really is no such thing as "push" technology. To get something that looks like push, you have to set up a server (listening) process on the client with a fast (enough) polling interval. When you do that, you open up a lot of security issues. Security wasn't top-of-mind in the '90s but it is today.
>
>With that in mind, it's not too surprising that some vendors are actually using web servers for the kind of technology and features I mentioned above with the AIO device. For example, some HP network AIO devices install an Apache Tomcat Java server on client PCs as part of the standard (massively bloated) client software installation. That lets things happen like the PCs getting alerts about out-of-paper, low ink/toner, status of printed jobs etc.
>
>There are "lightweight" web servers available you could consider for client installation if that would meet your needs: http://en.wikipedia.org/wiki/Comparison_of_lightweight_web_servers

Thanks, but this is a no-installation component on the client side but the actual EXE we already have. This EXE is updating by itself when needed. So, if we add support for this listening, it will be smart enough to return back to expected result to the server. So, basically, instead of client to server, we need server to client. Whatever it takes locally as far as configuration, we can do. If it requires to open a port with a high level of encryption for the transmission, this is doable.

Basically, I need to open a channel between the two. The market software does that, aren't they? I wouldn't think they would hit a WS for every second when they need to update their graph. They need more power so I assume they have a direct channel with a server.