Wrox Programmer Forums

Need to download code?

View our list of code downloads.

Go Back   Wrox Programmer Forums > .NET > Other .NET > General .NET
Password Reminder
Register
Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read
General .NET For general discussion of MICROSOFT .NET topics that don't fall within any of the other .NET forum subcategories or .NET language forums.  If your question is specific to a language (C# or Visual Basic) or type of application (Windows Forms or ASP.Net) try an applicable forum category. ** PLEASE BE SPECIFIC WITH YOUR QUESTION ** When posting here, provide details regarding the Microsoft .NET language you are using and/or what type of application (Windows/Web Forms, etc) you are working in, if applicable to the question. This will help others answer the question without having to ask.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the General .NET section of the Wrox Programmer to Programmer discussions. This is a community of tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developers’ questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
DRM-free e-books 300x50
Reply
 
Thread Tools Display Modes
  #1 (permalink)  
Old August 24th, 2007, 11:51 AM
Registered User
 
Join Date: Aug 2007
Location: Almere, , Netherlands.
Posts: 6
Thanks: 0
Thanked 0 Times in 0 Posts
Default Cross-domain synchronization

In my job I was confronted with the problem of testing concurrent use of a remote-object by client applications residing in different application-domains and/or computers. Some requests require locking mechanisms that have to be tested.
I have to devise a method to control client-applications in such a way that it is (almost) certain that they fire requests at the remote-object at the same time.
Although I have a few ideas of my own, I wonder whether anyone knows of existing solutions for this, especially those that DON'T require the aquisition of extra software-tools, but can be implemented using standard features of Visual Studio 2005 (C#).


Reply With Quote
  #2 (permalink)  
Old August 24th, 2007, 10:30 PM
planoie's Avatar
Friend of Wrox
Points: 16,481, Level: 55
Points: 16,481, Level: 55 Points: 16,481, Level: 55 Points: 16,481, Level: 55
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Aug 2003
Location: Clifton Park, New York, USA.
Posts: 5,413
Thanks: 0
Thanked 16 Times in 16 Posts
Default

Can you explain what the applications are doing in more detail? That may help us to provide an answer.

Disclaimer: I'm no remoting expert, but here's what I'd do:

If you know the clients that are going to be simultaneously connected I suppose you could use some kind of call blocking mechanism. Each client makes a call to some method on the remote class, this method forces a thread block while it waits for something (such as a ManualResetEvent). Some logic called by that method would check that all clients are present, then you "set" the reset event which unblocks all waiting threads. This reset event would need to live in a singleton class (or possibly a static member of a single call class) in order to work between the remote consumer threads.

For more:
http://msdn2.microsoft.com/en-us/lib...esetevent.aspx

Alternatively, the WaitHandle.WaitAll static method might work for you too:
http://msdn2.microsoft.com/en-us/lib...e.waitall.aspx

-Peter
Reply With Quote
  #3 (permalink)  
Old August 25th, 2007, 02:43 AM
Registered User
 
Join Date: Aug 2007
Location: Almere, , Netherlands.
Posts: 6
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Hi Peter,

Maybe I should explain the situation in some more detail.

A long living remote object (System.MarshallByRef) provides services for several client-applications thru Tcp and/or Http.
It provides an interface for an extensive logic-engine (a so called "facade").

The logic-engine contains collections of objects for several purposes. The whole engine is re-initialized every day.

In some cases the first time a contained object participates in a client-request it has to do some processing that changes its state.

Subsequent client-requests on the same object use the results of that initial processing.
The reason for this is that the processing involved is quite extensive and should not be done unnecessary. Once done it should not have te be repeated (lazy evaluation).

Client-requests are concurrent. Only one client-request may lead to a change of state of an object. Other client-requests can only be handled if the very first request is completed so sometimes a client request has to wait.
This is very easy to implement because the object that might have to change its state can us a "lock" on itself.

As far as the locking-mechanism is concerned this is a very simple situation, but there are far more intricate possibilities.

The problem is to find mechanism to test locking-mechanisms (and synchronization) using Visual Studio and have the logic-engine running in "debug"-mode. So what I want to do is:

Start a console application in debug-mode that hosts the remote-object (logic-engine)
Start processes that fire the requests to be tested. however they must fire the requests as simultaneously as possible so they are blocked until all released by another process.
Start a process that releases all other processes resulting in a non determined sequence od (more or less) concurrent requests.

Most locking mechanisms are local (same AppDomain), however in this situation every process can run in a different AppDomain.
I have a few ideas of my own, but I'm interested if this problem has been addressed before and I don't have to waste time on
re-inventing.

Reply With Quote
  #4 (permalink)  
Old August 25th, 2007, 09:42 AM
Registered User
 
Join Date: Aug 2007
Location: Almere, , Netherlands.
Posts: 6
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Quote:
quote:Originally posted by planoie
Disclaimer: I'm no remoting expert, but here's what I'd do:

If you know the clients that are going to be simultaneously connected I suppose you could use some kind of call blocking mechanism.  Each client makes a call to some method on the remote class, this method forces a thread block while it waits for something (such as a ManualResetEvent).  Some logic called by that method would check that all clients are present, then you "set" the reset event which unblocks all waiting threads.  This reset event would need to live in a singleton class (or possibly a static member of a single call class) in order to work between the remote consumer threads.
I guess I reacted to hastily. Your suggestion clearly resembles my own ideas on this matter.

Secondly, I often hear from .NET-experts that they know little about .NET Remoting. I'm under the impression that this part of .NET is undervalued.

Nico


Reply With Quote
  #5 (permalink)  
Old August 26th, 2007, 02:15 PM
planoie's Avatar
Friend of Wrox
Points: 16,481, Level: 55
Points: 16,481, Level: 55 Points: 16,481, Level: 55 Points: 16,481, Level: 55
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Aug 2003
Location: Clifton Park, New York, USA.
Posts: 5,413
Thanks: 0
Thanked 16 Times in 16 Posts
Default

Quote:
quote:Originally posted by NicoDeBruin
 Most locking mechanisms are local (same AppDomain), however in this situation every process can run in a different AppDomain.

Your consumers are all running in different app domains, but they are all connecting to a single program that is hosting the remote class. While each remoting call from the consumer may be in different thread, those threads are still within the context of the same app domain. This is the point of the lock or WaitHandle mechanism: to allow different threads in the same app domain to interact and influence each other.

From a standpoint of testing this behavior, could you introduce some manual overrides to the remote class behavior such that you could forcibly delay processing to simulate the simultaneous consumer calls? For example, put a "Console.ReadLine()" call in the process. Your console app that hosts the remote object would wait at this line until keyboard entry. That way you can fire up the multiple test clients to simulate processing delay to show that the thread blocking is working. Once you hit a key in the test host the threads should finish and the consumer will be released.

Quote:
quote:Originally posted by NicoDeBruin
 Secondly, I often hear from .NET-experts that they know little about .NET Remoting. I'm under the impression that this part of .NET is undervalued.

Hardly. I think that remoting is phenomenal! The hard part (personally) is finding applications for it. I work primarily doing ASP.NET web applications so I don't have a regular occasion to work with remoting. If you build an application that is distributed then you are far more likely to have a solid use for it.

-Peter
Reply With Quote
  #6 (permalink)  
Old August 26th, 2007, 03:34 PM
Registered User
 
Join Date: Aug 2007
Location: Almere, , Netherlands.
Posts: 6
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Quote:
quote:
Your consumers are all running in different app domains, but they are all connecting to a single program that is hosting the remote class.  While each remoting call from the consumer may be in different thread, those threads are still within the context of the same app domain.  This is the point of the lock or WaitHandle mechanism: to allow different threads in the same app domain to interact and influence each other.
Exactly my thoughts, every invocation of a method in a remote object generates a new thread. This thread is dedicated to a process in another Appdomain, but still it is a local thread for the remote object (or service) so "local" locking mechanisms can be used.

Quote:
quote:
From a standpoint of testing this behavior, could you introduce some manual overrides to the remote class behavior such that you could forcibly delay processing to simulate the simultaneous consumer calls?  For example, put a "Console.ReadLine()" call in the process.  Your console app that hosts the remote object would wait at this line until keyboard entry.  That way you can fire up the multiple test clients to simulate processing delay to show that the thread blocking is working.  Once you hit a key in the test host the threads should finish and the consumer will be released.
It doesn't have to be a console application that hosts the remote object. That is only convenient for debugging purposes.
Normally I would use IIS hosting or a windows service.
For simulating processing I use "Thread.Sleep()" combined with "Console.WriteLine()" for trace-information.

I've done some testing in the meantime and it works very well when one or more "WaitHandles" are owned by a remote object (not necessarily the same as the engine) that are accessible to all client-processes as properties or through methods. What I've found out so far is that you can define specialized remote "schedule"-objects that implement synchronizing mechanisms that work cross-domain and even over a LAN, simply by publishing waithandles like AutoResetEvent and ManualResetEvent (Monitor is a static class and therefore less easy to use).
The fun of it is that it can be used over IPC TCP and HTTP.
Quote:
quote:I think that remoting is phenomenal!  The hard part (personally) is finding applications for it.
Remember me mentioning "lazy-evaluation". This technique and other related techniques require statefull (even perpetual-state) objects. Remoting is i.m.o. the easiest way to implement this kind of objects. Especially applications that incorporate extensive logic rather than data-access (e.g. mathematical models) are best implmented as remote-objects, aside from specific security issues. You can allways define web-services as a gateway to the (preferably state-less) web-world.

Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Cross Domain Cookies kokkee Javascript 1 May 21st, 2007 10:02 AM
Same pages for sub domain from main domain vivek_inos ASP.NET 1.0 and 1.1 Professional 1 February 13th, 2007 10:15 AM
Active Directory/SQL server cross domain trusts tuffnet SQL Server 2000 3 December 1st, 2005 01:11 PM
cross-window synchronization mikeg Javascript How-To 2 April 28th, 2005 11:10 AM
XML Synchronization prashant_dnmmkpk Biztalk 0 January 17th, 2005 09:16 AM



All times are GMT -4. The time now is 03:33 PM.


Powered by vBulletin® Version 3.7.0
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.