Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>This can be done quite easily with WCF and <a href="http://msdn.microsoft.com/en-us/library/ms731064.aspx" rel="nofollow noreferrer">duplex contracts</a>. You can define operations that the client can perform on the server (like any web service) and in addition you can define operations that the server can perform on the client (i.e. a reverse web-service). Code wise, they're both just simple method calls. The client has methods that call operations on the server and it also must supply an object that implements the callback contract, which is an interface the server can call and the client must provide an implementation for. All serialization/deserialization of data and messages and all low level network operations are handled by WCF, so you won’t have to worry about it.</p> <p>WCF supports duplex contracts using two bindings (or 'protocols'):</p> <ol> <li><p><a href="http://msdn.microsoft.com/en-us/library/system.servicemodel.wsdualhttpbinding.aspx" rel="nofollow noreferrer">WSDualHttpBinding</a> - This entails two SOAP-based HTTP listeners, one on the server and one on the client. When the client wants to contact the server, it performs an HTTP request to server. When the server wants to contact the client, it performs a HTTP request to the client. The advantage of this approach is that any network connection is fleeting, and is not kept open (as with most HTTP connections), and so it can support a large number or concurrent clients. The main disadvantage is that it probably won't work with most client computers over the internet since they are usually behind NAT (a non-issue for server-to-server communications over the internet or any sort of communication inside an intranet or LAN). For more details, see my <a href="https://stackoverflow.com/a/4528171/149265">other answer</a>.</p></li> <li><p><a href="http://msdn.microsoft.com/en-us/library/system.servicemodel.nettcpbinding.aspx" rel="nofollow noreferrer">NetTcpBinding</a> - This basically opens a socket from the client to the server and keeps it open for the duration of the session. This allows two way communications even over NAT, but since connections must be kept open it is somewhat more of a burden on the server and therefore will be able to support less concurrent users (but probably still more than enough in most cases). This is my preferred way of doing duplex contracts on WCF since it’s easier to get working and is more reliable.</p></li> </ol> <p>The advantage of WCF is that you can switch between the two bindings without changing your code. All that is required is changing the configuration (.config file).</p> <p>Whichever way you choose, you'll be able to perform near-instantaneous communication in both directions (network latency permitting, of course). I don't see the need for SignalR when you have such a rich, powerful and easy to user framework such as WCF at your disposal. If you were constrained by running in a browser, then SignalR would make sense. Since you're running in .NET, it would just introduce unnecessary friction.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload