I have a WCF service which I host inside a WFP application, which acts as one of the clients of service as well. There is one more WPF app which acts as another client for service. After a timeout occurs and clients get disconnected, What is the proper way to clean up resources and connect the clients again. I am trying to create new proxies but I am not able to use them for communication. I know I can increase the recieve timeout on service but I need my clients to be able to communicate always not just for long enough. I have also tried continously sending a message to service at interval but that's something I don't want to go for. What approach is best for continous communication between clients and service? My service might need to be connected to clients for months or may be years.
Any help will be of great value.
Thanks in advance.
You can catch the CommunicationException or something like that and then restore the channel.
Related
We are making a web application in Go with a MySQL database. Our users are allowed to only have one active client at a time. Much like Spotify allows you to only listen to music on one device at a time. To do this I made a map with as key the user ids and a reference to their active websocket connection as a value. Based on the websocket id that the client has to send in the header of the request we can identify weather the request comes from their active session.
My question is if it's a good practice to store data (in this case the map with the user ids and websockets) in a global space or is it better to store it in the database.
We don't expect to reach over 10000 simultaneously active clients. Average is probably gonna be around 1000.
If you only run one instance of the websocket server storing it in memory should be sufficient. Because if it for some reason goes down/restarts then all the connections will be lost and all the clients will have to create them again (and hence the list of connection will once again be populated by all the clients who want to use the service).
However, if you plan on scaling it horizontally so you have multiple websocket services behind a load balancer, then the connections may need to be stored in a database of some sort. And not because it necessarily needs to be more persistant but because you need to be able to check the request against all the services connections.
It is also possible to have a separate service which handles the incoming request and asks all the websocket services if any of them have the connection specified in the request. This could be done if you add a pub/sub queue and every websocket service subscribes to channels for all its websocket ids and the service that receives the request then publishes the websocket id, and the websocket services can then send back replies on a separate channel if they have that connection. You must decide how to handle if no one is responding (no websocket service has the websocket id). Either the channel does not exist, or you expect the answer within a specific time. Or you could publish the question on a general topic and expect all the websocket services to reply (yes or no).
And regarding whether you need to scale it I guess depends mostly on the underlying server you're running the service on. If I understand it correctly the websocket service will basically not do anything except from keeping track of its connections (you should add some ping pong to discover if connections are lost). Then your limitation should mainly be on how many file descriptors your system can handle at once. If that limit is much larger than your expected maximum number of users, then running only one server and storing everything in memory might be an OK solution!
Finally, if you're in the business of having a websocket open for all users, why not do all the "other" communication over that websocket connection instead of having them send HTTP requests with their websocket id? Perhaps HTTP fits better for your use case but could be something to think about :)
I have a WCF service, hosted in a win form application, that receive the requests from the clients. One of this requests, is update the stock of the items.
Well, my idea is to use a client to send to the WCF service the new amount of items, then the service use Entity Framework 4.1 to update the database with the new stock.
How the service is duplex, when the services has finished the update, it sends a message to the client to notify that the operations is successful. That's if there is no problems.
However, I have a question. It's possible that the client send the command to the service to update the stock. The service receive the command correctly, but before the operation is finished, the client lost the connection with the service, so the services can't send to the client the status of the operation, so the user does not know if it's all ok or not.
My second question has the same logic, but with the WCF service. It's possible that the WCF service is installed in other computer different to the computer in which is installed the database. So it's possible that the WCF services send correctly the command to the database, but before the database notify that the operation is successful, the WCF service lost the connection, so it never receive a response from the database but the operation is successful. How can the user know if the operation is ok or not?
So my question is, in WCF, how can I be sure that critical operations are successful or not?
Thanks.
Daimroc.
I wonder how can I achieve this without UDP, I have a solution using UDP multicast: http://blogs.msdn.com/b/ncl/archive/2009/11/18/udp-multicast-in-silverlight-4.aspx
but since this is for a high profile customer who has an intranet with port TCP 80 and TCP 8080 only enabled this solution is not possible. Yes, the application runs in an intranet environment.
I need a simple example how to send messages to all Silverlight clients over WCF.
I found this solution, but I have no idea how to implement that into Silverlight:
http://idunno.org/archive/2008/05/29/wcf-callbacks-a-beginners-guide.aspx
I'm out of ideas guys, please help.
Instead of receiving notifications async the Silverlight client should use polling instead.
It can poll a WCF service that will fetch the data from a db...
This is the typical solution. Anyway, you have to handle the case in which the Silverlight client wasn't online and then it becomes online and need to know its state...
However, if you still want Silverlight to receive async notifications try searching for 'Full Duplex'.
Here are some starting points:
http://blog.developers.ba/post/2009/02/25/Silverlight-chat-application-using-WCF-full-duplex.aspx
http://weblogs.asp.net/dwahlin/archive/2008/06/16/pushing-data-to-a-silverlight-client-with-wcf-duplex-service-part-i.aspx
http://hindams.wordpress.com/2010/04/05/wcf-full-duplex-with-a-silverlight-application/
Can anyone think of a good way to allow the server to notify the client based upon server processing? For example, consider the following events:
A user requests a deletion of data, however, due to it's long-running time, we kick it off to a queue.
The client receives a "Yes we completed your transaction successfully".
The server deletes the item and now wants to update any local structures any clients may be using (I'd also like to notify the user).
I know this can be done by client-side polling. Is there a event bus type way to do this? Any suggestions are welcome, but please keep in mind I am using GWT with App Engine.
The standard AJAX interaction is that the client sends requests to the server and expects some sort of response back fairly quickly.
In order for the server to initiate a request to the client, you will need to use WebSockets, and experimental HTML5 feature currently only supported by Chrome.
Or, to simulate this kind of interaction, you can use Comet (long-polling), made available in GWT by the rocket-gwt project.
You want server events for GWT? Have a look at GwtEventService (they couldn't have chosen a better name): http://code.google.com/p/gwteventservice/wiki/StartPage
Of course, it uses a Comet implementation, but you can't do any different when using HTTP, the client always initiates the communication. Request, response.
could I send messages from one service to multiple service using service brokers?
Something like
BEGIN DIALOG CONVERSATION #dialog_handle
FROM SERVICE [SERVICE1]
TO SERVICE 'SERVICE2',**'SERVICE3'**
ON CONTRACT [MainContract]
Looking at the syntax, I do not think we could do this. What's the alternative?
Thanks and Regards
DEE
There is no publish-subscribe nor multicast built in into Service Broker. To send a message to multiple services you have to explicitly send it to each destination an o a separate dialog.
The typical solution is to send only one message from the application to a service that acts like a distributor. The distributor service receives this message and sends a copy of it to each interested service (Service2, Service3 etc). This way the application doesn't need to know upfront how many services it needs to send the message to, it just sends it to the distributor service.