I am using SignalR to setup a connection between my client and my server. I would like to store some user data on init. When the user calls a method I want access to these variables to do some calculations and send a response back to the client.
I can not use static variables because I want these variables to be individual for each client. Saving these variables in one global dictionary seems not performant for a lot of users. Saving the data in a database is not an option because the client will call a method approximately every 15-30 seconds and this for a few minutes and then the hub can be disposed.
What I am trying to archieve is one hub instance per client. One open connection with the server, 1-on-1. Is this possible with SignalR and how or do I have to look for another library?
Thanks a lot,
Have a great day!
by trying to get a hub instance per client connection is pretty hard since hubs are designed to be just the opposite (a way to talk to some or all clients connected)
you are probably looking for the Persistent Connection API
PS: I don't really see why you rule out a db so quickly since you could always use an in memory cache like redis.
Related
Is there any way to call a method / function in an API rest in C# if it is a specific time without any request?
The goal would be to know when a person would have left the interface prematurely (or in case of power failure).
Or in case of prolonged inactivity.
In my case : the front is in angular4
In other words, you tring to achive the ability to commuincate with the client from the server.
It's called WebSockets, there are some implimation for that.
The best implantation for C# WebSockets is SignalR
The way you should use it' is that in your server you would 'ping' all your connected clients, and those who are not responding, assume as disconnected (you might add some delay to prevent unwanted disconnections)
The second option, is to created an interval on your client, and each time send an 'ping' to the server that the client 'is alive', that's pretty messy and i don't like that approach, but its little bit easier.
Good Luck!
I've to design a web application to support multiple clients.
I'm thinking to have a MongoDB with the username or email of each user and the name of the connection string of each user.
And with the connection string get the SQL database of the client.
But I'm not sure if this is the best approach.
Do you have any other suggestion?
Had situation close to you.
We used 1 common db(parent), where stored connections per clients and simple iterface to control child database's(they are separated, you can create manualy or automaticly as many db's per client, as you want or as many clients.
Based in what way you want to find clients. Our system used client per url/ Every client had own url and own db. So in code, we check url, then get from main db connection string and init context with specified connection.
You need provide more details, to get more info. Based on your goal, solution can be different.
I saw some projects with URL based approach... However, if you want your application more dynamic like let say migrating from server side to client side application and you don't want your URL change... I would say, your "user based" approach is more ideal in my opinion. Good luck.
If you have many clients with their databases then you must made different web application, even if they are copy/paste the one to the other
If you have many clients under the same url, under the same web application, then you can have one database and there you separate them, inside the database.
The web.config is not offering for frequent change the connection - you setup this ones to work and you forget it.
Every time you change the web.config you create a serial of events, and restart the application, recompile it if find some reason... etc
I am trying to migrate logic from a real-time .NET based socket server into a RESTful based ASP.net web api. The reason is because our game design changed and we no longer need to do any real-time stuff with socket servers.
In order to migrate, I need to do the following e things, but I have no experience with Asp.net so wish someone could point me in the right direction:
1) In the socket server, when a player makes a connection, we load all of that player's data from the database into an instance of the Player class, such as the player's inventory. We keep this instance alive on the connection object on the server side so that as long as the tcp socket connection is alive, this Player object acts sort of as a cache in memory holding the player's data. But I can't figure out what the equivalent place to put this Player instance in Asp.net Web API, would this be on the session state?
2) The game has static data that's available to all connected clients such as how much damage a weapon does. We load this data from the database into a StaticData object on the server's application instance. What's the place to hold application-wide data in Asp.net web api?
3) We do not use a MVC architecture and currently the way we communicate between client and server is we make a request (say selling an item), the server validates and process the request, and sends the updated state back to the client by serializing the updated data into an object[] array. It seems with asp.net MVC a lot of things are "automatic" and what would be the equivalent of doing the "send request to server -> server process and sends back updated state -> client deserializes the state" in the asp.net web api world?
1) Yes, you could store that in Session.
2) Similiar to Session, ASP has Application.
3) Sorry, but the question is a little too broad to be answered. The MVC pattern is not magic and you will still have to write code. You send a request to the server. It get's processed by the controller which can manipulate a model which in turn updates a view, i.e. the output of the whole process. Try this tutorial to get started and get a better idea of the MVC pattern in ASP.net.
Last but not least you should be aware that you might be setting yourself up for some problems further down the road if you store data in the Application. As your order of magnitude of users gets bigger you may want to run your application with more than one IIS worker process. Each of those worker processes has it's own Application object. Depending on how much memory the static data takes up you might run into memory problems. You should think about using memcached, redis, etc. as shared cache instead. The same goes for the Session data.
I am developing a Windows RT application that needs to get data from a MVC WebApi server.
The problem is that the response can take from few seconds to 3 minutes.
Which is the best approach to solve it?
For now, I call async to the web api and put a long timeout value to avoid exceptions. Is it a good way? I do not like too much because the server have a open connection opened all time. Can it affect significantly to the server performance?
Is there some thing like "callback" but for web services? I mean that the server calls to the client to send the data.
Yes, there are ways to get server to callback client, for example WCF duplex communication. However, such techniques will usually keep the connection open (in most cases this is TCP session). Most web servers do not support numerous concurrent requests and thus each prolonged call to the server will increment the number of concurrently connected clients. This will lead to heavy resource utilisation at the point where it shouldn't be. If you have many clients, such architecture is bound to fail.
REST requests shall be lightweight, small and fast. Consider using a database to store temporary results and worker servers, to process the load. This is a server-side problem, not client-side.
Finally I solved it using WebSockets (thanks oleksii). It keeps the connection open but I avoid to poll for the result repeatedly. Now, when the server finishes the process, sends the data directly to the client. WebSockets is a protocol that relays over TCP and has been standardized.
http://en.wikipedia.org/wiki/WebSocket
Hi I have an application that operations like this..
Client <----> Server <----> Monitor Web Site
WCF is used for the communication and each client has its own session on the server. This is so callbacks can be used from the server to callback to the client.
The objective is that a user on the "Monitor Website" can do the following:
a) Look at all of the users currently online - that is using the client application.
b) Select a client and then perform an action on the client.
This is a training system so the idea being the instructor using a web terminal can select his or her target client and then make the client application do something. Or maybe they want to send a message to the client that will be displayed on the clients screen.
What I cant seem to do is to store a list of all the clients in the server application, that can then be retrieved by the server. If I could do this I could then access the callback object for the client and call the appropriate method.
A method on the monitoring website would look something like this...
Service.SendMessage(userhashcode, message)
The service would then somehow look up the callback that matches the hashcode and then do something like this
callback.SendMessage(message)
So far I have tried without look to serialise the callbacks into a centralised DB. However, it doesnt seem possible on the service to serialise a remote object as the callback exists from the client.
Additionally I thought I could create a global hash table in my service but im not sure on how to do this and to make it accesible application wide.
Any help would be appreciated.
Typically, WCF services are "per-call" only, e.g. each caller gets a fresh instance of the service class, it handles the request, formats the response, send it back and then gets disposed. So typically, you don't have anything "session-like" hanging around in memory.
What you do have is not the service classes themselves, but the service host - the class that acts as the host for your service classes. This is either IIS (in that case you just need to monitor IIS), or then it's a custom app (Windows NT Service, console app) that has a ServiceHost instance up and running.
I am not aware what kind of hooks there might be to connect to and "look inside" the service host - but that's what you're really looking for, I guess.
WCF services can also be configured to be session-ful, and keep a session up and running with a service class - but again: you need to have that turned on explicitly. Even then, I'm not really sure if you have many API hooks to get "inside" the service host and have a look around the current sesssions.
Question is: do you really need to? WCF exposes a gazillion of performance counters, so you can monitor and record just about anything that goes on in WCF - wouldn't that be good enough for you?
Right now, WCF services aren't really hosted in a particularly well-designed system - this should become better with the so-called "Dublin" server-addon, which is designed to host WCF services and WF workflows and give admins a great experience monitoring and managing them. "Dublin" is scheduled to be launched shortly after .NET 4.0 becomes available (which Microsoft has promised will be before the end of calendar year 2009).
Marc
What I have done is as follows...
Created a static instance in my service that keeps a dictionary of callbacks keyed by the hashcode of each WCF connection.
When a session is created it publishes itself to a DB table which contains the hash code and additional connection information.
When a user is using the monitor web application, it can get a list of connected clients from the DB and get the hashcode for that client.
If the monitor application user wants to send a command to the client the following happens..
The hashcode for the sessionn is obtained from the db.
A method is called on the service e.g. SendTextMessage(int hashcode, string message).
This method now looks up the callback to the client from the dictionary of callbacks and obtains a reference to it.
The appropriate method in this case SendTextMessage(message) is called on the callback.
Ive tested this and it works ok, Ive also added a functionality to keep the DB table synchronised to the actual WCF sessions and to clean up as required.