When a user updates some data in our .net application our server sends updates out to interested clients telling them that this data has updated. Currently each client is also a server (ie. they listen on a port) the server keeps track of which clients are logged in and sends them update messages via remoting.
This works well but has potential problems as firewalls must be configured to allow access to client PCs.
There are a few ways I see to get around this but each have their drawbacks. I am currently investigating wcf or a queueing system like msmq, however I don't have any experience with these and the learning curve seems steep. Other options I have in mind are:
- Geting clients to call a server method that does not return until a message comes in - potential problems with timeouts, disconnections, etc?
- Change to WCF and use callbacks - not sure if this requires the client to be an endpoint?
- Use a timer and check for messages every few seconds - potential to flood the network
Is there some other way this could be implemented? I see this as a problem that has probably already be solved so hopefully implementation will be straightforward. Ideally no connected client should miss a message and this could be used for other types of updates - eg. progress updates of server jobs, etc.