Distributed application programming

[Tim Marsden]

I am new to distributed application programming. Could anybody give me
advice on how to accomplish the following? I am writing in VB.NET. I would
like to keep away from web services and IIS if possible. Perhaps using some
form of remoting.



I would like to develop an application which sits on a "server". (or a Pc
which sits in the corner)

This application would take requests from a "client" application; the client
app will sit on numerous PCs.

The server app would then process the request and pass the result back to
the client app.

The process taking place on the server could be lengthy, so I would like to
be able to run multiple requests at once (different threads). I would like
to set a maximum number of concurrent processes, the other requests would
queue up on a first come first served basis, waiting for a free thread.

I would like a graphical representation of which requests are being
processed and which are in the queue.



Please respond with any thoughts. Every response is appreciated.



Regards

Tim Marsden

 

[Peter Huang]

Hi Tim,

Now I am researching the issue, I will get back here and update you with
new information ASAP.
Have a nice day!

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Peter Huang]

Hi Tim,

Based on my research, the .net remoting will do many of the thread schedule
itself, if you do not care it, I think remoting will help you save much
time, what you have to do is build a server and client application, all the
client will try to post request to the server and then the server process
the request, if there is any error, the client will try to repost the
request.
For your senario, if you do want to control whole procedure, I think you
would better handle the threads yourself so as to guarantee the performance
and flexibility.

When to Handle Threads Yourself
Using the thread pool effectively is closely linked with knowing what you
need from your threads. If you need a guarantee of service, you'll need to
manage it yourself. For most cases, using the pool will provide you with
the optimal performance. If you have hard restrictions and need tight
control of your threads, it probably makes more sense to use native threads
anyway, so be wary about handling managed threads yourself. If you do
decide to write managed code and handle the threading on your own, make
sure that you don't spawn threads on a per-connection basis: this will only
hurt performance. As a rule of thumb, you should only choose to handle
threads yourself in the managed world in very specific scenarios where
there is a large, time-consuming task that is done rarely. One example
might be filling a large cache in the background, or writing out a large
file to disk.

I would just recommend to use and tune the thread pool provided by the clr :
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/ht
ml/progthrepool.asp

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Allen Anderson]

Sure, check out some of my articles on this subject. As for
concurrent requests, just create the object in any given thread you
want to access the server on and call to your hearts content.

http://www.glacialcomponents.com/ArticleDetail.aspx?articleID=CAOGuide

http://www.glacialcomponents.com/ArticleDetail.aspx?articleID=RemoteObject

Allen Anderson
http://www.glacialcomponents.com
mailto: allen@put my website url here.com