I answered this question myself. I could not find the information in the MSDN, so I made a test app. that connected to the service. The connections were done from 256 threads that then proceeded to make 50,000 calls at the same time. The server registered these calls and marked the begin and end of each call along with the thread ID. The trace log indicated multiple calls were being executed at the same time with no problems. So the answer seems to be that he remoting proxy is thread safe, and will make multiple calls per connection instance instead of sequencing the calls over one connection. The only other thing I need to do is sniff the wire to see if multiple connections are being made, or if they are getting to the server over one connection. BTW: Anyone know if after a remoting call over a TCP channel if the TCP connection is dropped, or does it stay connected for the life of the proxy?

Assert(this);

Hi, I'm writing a web service that talks to a windows service via remoting. The windows service is configured to remote the object as a singleton. Since multiple web service threads can be spawned by multiple client requests the Remoted object has been written to b thread safe, but what about the web service (client) proxy to the remoted object? Worded another way - I have multiple threads firing methods on a single remoting proxy that is connecting to a singleton object. Will there be any problems with the proxy itself? Here's some psuedo code:

static RemoteObject remObject; <-- globally stored

main()
{
remObject = GetRemoteConnection(); <-- obtain connection
...
// Create some threads
...
DoSomethingThread1.start();
DoSomethingThread2.start();
}

static void DoSomething()
{
remObject.DoSomething(); <-- Will get called by two threads at virtually the same time.
}

Thanks in advance for any insights.

Assert(this);

I have found that timeouts and keep-alive messages are a must when using socket connections. I know this doesn't answer your question, but did you know that if you have 3 switches in between the client and the server, then the middle switch dies, and your applications will still think the connections are fine until they try to send a message? The spec. for the keep-alive of the so called connection-oriented TCP/IP is optional.

Assert(this);

Hello, I'm setting up a remoted object and was wondering about overriding the lifetime service. I overrode the method that allows me to define my own lease settings, but I was curious about what happens when I return null instead of the lease. The object is supposed to now have an infinite lifetime if you return null. So if I applied this to a Client Activated object, then every object a client makes will NEVER get garbage collected. Is this absolutely true? If so, is there a programmatic way that the client could tell the server that it is done with the object and it's OK to clean it up, even though the lifetime is set to infinite? It just seems odd to me that if a client activates 1000 objects and then sets them to null, and heck, even shuts itself down, the server will keep those objects hanging around. I don't want to build in any kind of sponsoring or lease renewal, I just want the object to stay around without keep-alives and 1 call that says I'm done using it. If something bad happens to the client and a couple objects get left hanging around, then so be it.

Assert(this);

Hello, I'm using .NET 2.0 and setting up a remoting interface for a Windows Service. I like to be in control of how other applications use the service so I wanted to specify that client applications should only use the remoted object via an interface. My question is - Can I setup a client activated object so that clients don't have to know about the object class type (beyond the interface)? So far I have made this work for the server activated (singleton) styled remoted object. This works fine using (ISomeInterface) Activator.GetObject( SomeInterfaceType, ....), but when I try something similar with Activator.CreateInstance( SomeInterfaceType, ... ) the system complains I need a MarshalByRefObject type :( . I understand why it's refusing to activate the object, but I'm wondering if there is a way around this. BTW: If you are wondering why I want to use Client activated, it's because there is a future possibility of per client session information that needs to be evaluated per call. If each client has it's own object, then the instance can contain the session information. If I had to store per client session information in a singleton it would involve a lot more management complexity (add more code to maintain, slow things down at runtime, etc..).

Assert(this);

What happens when you compile evertything with the references working and then put it on a machine without the office programs? It should throw an exception when you try to create an object based on the references. Examine the description for that and you should be able to then do try->catch on startup to tell what is installed.

Assert(this);

I have a little asynch. socket listener that notifies me when data is read. inside of the OnRead callback event it seems that my notifications were overlaping (future notifications triggered before past notifications 1.2.3.4.5. becomes 1.2.5.3.4.). The code goes like this:

private void OnReadComplete( IAsyncResult ar )
{
... copy the m_byBuffer data into byOut ...
... do some work ...

lock(m_ReadLockObject) <-- should block the next read attempt.
{
// Continue reading
if (m_netStream.CanRead && (m_Socket.Connected || m_netStream.DataAvailable))
m_netStream.BeginRead(m_byBuffer, 0, m_byBuffer.Length, m_callbackRead, null);

// Trigger Read Data event.
if (bytesRead > 0)
	ExecOnDataRead(this, new CClientInfoEventArgs(m\_EndPoint, byOut));

}
...
}

The data keeps comming in all jumbled up. Now I can patch this by putting in a sufficiently large delay, like a trace before and after I call ExecOnDataRead to check the current thread ID, OR I can re-arrange the ExecOnDataRead before the BeginRead. The thing is that I know ExecOnDataRead can be quite expensive and I do perform some work before I pass the data on, so I want the next BeginRead to be running while I'm doing that. Note that a simple trace or debug seems to straighten out the data (obviously time sensitive) so I can't observe what is happening except through the end results. Even putting in a second lock inside ExecOnDataRead, or a static mutex.WaitOne() does not seem to straighten out the data, but as soon as I put in a Trace to print out the thread ID's that are running the ExecOnDataRead to see if they are overlapping, everything straightens out!! Ahrrgg! It's almost like the lock is not locking.:sigh: Thanks in advance

Assert(this);

If your DLL has any custom functions in DllMain then move them out ASAP. I ran into a lock problem on the DllMain of a COM object loaded under .NET; It's not quite the same problem but Microsoft told me to move all my code out of there. Assert(this);

This is a re-post of an article I put in the COM section. It refers to .NET, COM and RPC so it's kind of hard to get coverage by people with appropriate skillsets. Here is the problem: As soon as I installed XPSP2 the startup code in a COM object instantiated by a .NET Service hangs. This in turn cause the service to hang. Observations: The COM object is instantiating an RPC Listener when it hangs. It specifically hangs on an endpoint registration, though raaaarely it continues through after getting an error code. The function in question is RpcServerUseProtseqEp and it returns 1740 (duplicate endpoint) or hangs. I am very sure the endpoint is NOT already registered. If I manually start my service it will work. If I delay the service start by 5 minutes (in code) it will start. If I add almost every service dependency I can it will still hang. If I have another service start the COM object (query a web page in background) it starts fine!! This all seems to work fine under 2000 SP4 and under the previous XP. I may just require a service environment (if it works under 2003), but I would really like to fix this behavior. This requires .NET, COM & RPC familiarity so I may have to move this to another forum. Assert(this); -- modified at 11:21 Monday 3rd April, 2006 Ok, found the fix for this. The RPC listener code was initiated in the DllMain section of the COM object. The DllMain section is a bad section to put any init code in due to lots of system locks etc... being set when that is called. Evidently XPSP2 has added some that were not there before and a previously working app. can now lock up.

Have you checked sourceforge or sites like that? I think I've seen this project a few years ago. Assert(this);

Hmm, I'll try changing it to Read. I'm guessing that an incomplete character could cause a block, I guess I'll just have to waste the memory in triple allocation (stream, array, string). It's kind of hard to specify a buffer that is the same size as the stream though since with multibyte I won't know the number of chars that are actually in the stream until it's decoded. Assert(this);

I have a network application that is reading an incomming message. The message should be UTF-8 formatted and could be transfered with garbage. I am currently using the StreamReader and BinReader to read from the stream, but I am unsure if I am using these objects properly. When I use the StreamReader to ReadToEnd() will it stop when it has reached an incomplete character? Will it leave the stream position after these incomplete characters, or will it go past them and just not include them in the results? Assert(this);

You may want to look up simple encryption/decryption routines in Perl first, and then get that to work. After finding out what already exists on the Unix box, you can then program to it using .NET. Assert(this);