0

I'm building a stock ticker that requires continuous real-time updates. JavaScript on the client talking to .NET WCF 4.5, which introduced support for WebSockets.

Users' feeds vary significantly. For example, many users follow popular big-caps like FB, GOOG and MSFT, but each user follows many other "niche" stocks that may be unique to him.

We all know there are a few options for refreshing the browser in real-time.

  1. Polling. Pros: Easy implementation. Cons: Doesn't scale, primitive, wastes bandwidth and cycles.

  2. Long-polling. Pros: Efficient, scalable. Cons: Antiquated?

  3. WebSockets. Pros. Efficient, scalable. Cons: None I can think of as most modern browsers support them as per caniuse.com.

Would anyone pick anything other than 3.?

Assuming I go with 3., how are the server's open connections kept track of? For example, if we design such that we keep a pool of FB "followers" (i.e., client connections interested in FB's price changes) so that we know whom to update when a price change occurs, how is this pool maintained? By a service that runs constantly in memory? Also, if a FB follower closes her browser, does the service need to catch this event and update FB's follower pool? This is where I get fuzzy quickly.

S. Valmont
  • 941
  • 2
  • 11
  • 25

1 Answers1

1

Take a look to this post about the hard sides of long polling : Hard downsides of long polling?

how are the server's open connections kept track of?

Probably there is a way in WCF WebSockets to have connect and disconnect events. If not, you definitely should keep an eye in other frameworks. I took a look to WCF websockets some time ago, and it didn't look like something I would like to use, put aside you need Windows 8 or Windows 2012 to use it.

You should consider websockets like just and endpoint. You should develop your stock ticker software with a event driven architecture approach, and then provide endpoints for receiving/delivering events, that would be a totally different part of the app. For event management I recommend you to take a look to MassTransit project.

When you have that clear then you can define how user will connect to your service and interact with it. In a web event driven architecture, websockets make a lot of sense because it is a full duplex, persistent connection and also a broadly supported web standard.

In order to provide websockets to .NET, WCF is not the only option, and it may not be the best neither. In order to add a websocket endpoint to your architecture, I recommend you to take a look at WebSocketListener, that is a very small component for providing websocket capability (disclaimer: I developed it), or XSocket.NET if you want a more complex solution that does many things. Take a look to this example done with XSocket.NET : https://github.com/codeplanner/Simple.StockTicker

Community
  • 1
  • 1
vtortola
  • 34,709
  • 29
  • 161
  • 263