I've tried to read as much as possible about remoting, and its different types, but I'm not quite getting parts of it...
I'm developing an application which seems like a mainstream app. It's a client- server app (with .NET remoting between client and server). The user logs in to the client, the login gets verified using a server call. Later on the user will perform a lot of actions on the client that result in calls to the server.
Currently I'm in the process of adding the login logic to the server - but my concern is that the user logs in, but after that, how do I check who makes the calls? In a web application I'm used to having a Session object, but I'm not quite sure how to handle it in a remoting environment.
I also have some other information (apart from user credentials) that the server needs to store on a per-user basis (such as connection string, since the server will connect to different databases for the different users).
Currently I'm using WellknownCalls/SingleCalls since I want users to use different objects (they shouldn't share any data).
Changing to Singletons isn't too appealing since I don't want a call to make other calls wait. I won't have a huge number of users, but some calls might take a while (a few seconds).
Changing to Client Activated calls seems a bit strange. I do apparently get state then, but I currently have about 20 registered services with approximately 150 exposed methods in total, and I'm not sure if all 20/150 will share the same session/state. It also seems a bit awkward with some limits (I read some stuff that exposed methods/classes can't be inherited fully then).
So, this must be a rather common problem - and I can't seem to get the hang of it properly. Does anyone have a solid suggestion, or is it all about choosing the solution with the fewest number of flaws/problems? Or should I just send all state data to the server as part of every call I make, and thus keep the state on the client (it feels like a really stupid solution though)?