>>It may not suit you but it might be worth looking at the MS Azure service bus:
>>http://www.windowsazure.com/en-us/home/features/service-bus/
>>
>>It will automatically set up a direct connection between client and server if one is available - otherwise it will continue to route via the 'cloud'. An additional benefit is that you can use it to queue messages for occasionally connected clients. We experimented with a 50-line console app installed on two laptops which enabled them to communicate with each other anywhere as long as there was an internet connection available....
>>
>>It's not free but, at 1c per 10,000 messages it shouldn't break the bank :-}
>>
>>
>>>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.
>
>It is interesting but we will not able to consider this possiblity.
>
>We really need to have something adjusted in our remote EXE for this support. As far as the server side, this is not yet decided but should not be a problem. The most important is to make sure we can preserve our remote EXE, but with an update to suppor this new functionality.

That's what I was suggesting. It would just be a question of adding a few lines of code to the client EXE to have it listening to the server and a few lines on the server to push messages over the protocol of your choice (I'd use TCP/IP) - but I accept the service bus idea may be overkill for your requirements.

If this was a browser based client you could look at the new HTML5 Server-Sent Events but your current WebSockets based solution is still probably the simplest solution.....