In theory you could also use object serialization / MessageQueue, right? I have tinkered with it for a while, but this does not substitute for real-world experience. I can't really tell what kind of performance you can expect, but probably it is not great compared to remoting.
Sergey Chemishkian Echelon Corporation -----Original Message----- From: Ian Griffiths [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 03, 2002 07:24 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Singleton without remoting Matthew Hunter wrote: > > Just wondering if anyone has come accross a way of > having a singleton object on the same machine as the > clients, but without using remoting. > > I now how to do this if the client objects are in the same > process (app-domain?) as the singleton, but not if the clients > are in different processes (as they do not see the singleton > in the other other process, and create their own). The only way that objects in different AppDomains can communicate with each other is through remoting. (Well...that or sockets, but that's a lot of work - you'll end up writing your own remoting infrastructure. In fact any communication mechanism can probably be made to work, but again you'll be rolling your own solution.)) The only supported (and indeed the only existing) means of accessing an object in a different AppDomain from yourself are remoting, and Web Services. I doubt that web services would be any more efficient... So if your objects are in different processes on the same machine, or even in different AppDomains in the same process, you *will* be using remoting. If they are in the same process you'll be using the relatively efficient cross AppDomain remoting channel instead of either the HTTP or TCP channels. But you're still using remoting, just with an in-process channel. (And for same machine, different process cases, I think someone has released a named pipe based channel, but this is not an officially supported part of the .NET framework.) > I don't mind using remoting so much to do this, but I would > like to avoid the overhead of remoting - seeing that the client >and server are on the same machine. Since your choices are remoting, web services, or roll-your-own-remoting-architecture, you don't have much choice. > Is there much overhead in remoting calls from a client to a server > if both are on the same machine? It's not dissimilar to cross machine, except nothing actually has to go over the network. This will probably translate to a small saving in CPU cycle terms, but a big improvement in speed - the main problem with remoting is having to wait for the packets to traverse the network. The named pipe channel might be better still. Or it might be worse. Try it and see... The main overhead in a non-networked scenario is the same for .NET as it was for COM. All of the same work has to be done for the in-machine case as it does for the cross-network case: parameters have to be marshalled and sent into the channel, and then unmarshalled at the other end. The same goes for any return values. In COM this was roughly 3 orders of magnitude slower than an in-process call. (I.e. cross process calls have always been expensive.) Actually quite a lot of that is the context switch... So it's going to be slow in any case, no matter what mechanism you use. Avoiding singletons may well be a preferable approach. -- Ian Griffiths DevelopMentor You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
