By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,168 Members | 1,564 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,168 IT Pros & Developers. It's quick & easy.

Remoting/Threading

P: n/a
I am somewhat new to the concept of remoting in c#. Here is my
scenario, if anyone could give me some tips I would really appreciate
it:

I have a server program running that updates a database and a binary
file every hour - this process takes approximately 10-15 seconds to
complete. There are going to be 300-400 client machines that will
have a client program running that connect to this server program
every day at random times (such as whenever a user logs in). This
client program calls a function on the server that returns certain
data from it's databases. I want to make sure that while the server
is updating, the client machines will wait at a lock or something
similar from threading until it is finished.

Currently, I have all the server and client calls encapsulated in one
large static class, figuring that making everything static would cause
less collisions. I don't know if this is good design, though. From
reading I get the impression that I should separate them into two
classes, but I'm not exactly clear on the best practice for making
this all work in the context of remoting. Any guidance or suggestions
would be appreciated.

Thanks,
Daniel

Feb 21 '07 #1
Share this Question
Share on Google+
2 Replies


P: n/a
One problem that I see, I think you're going to have to distribute the the
large static class to all the clients when they don't really need it. You
might be better off defining an interface that the static class implements.
Then, the clients just need the interface definition. You'll wind up with a
client exe, an interface dll and a server exe. The only piece that needs to
be on both ends is the interface dll. That also gives you more options when
you upgrade the server. You don't want to get yourself into a situation
where you need to upgrade the server and all of the clients at the same
time.

"da********@yahoo.com" <da********@gmail.comwrote in message
news:11*********************@m58g2000cwm.googlegro ups.com...
>I am somewhat new to the concept of remoting in c#. Here is my
scenario, if anyone could give me some tips I would really appreciate
it:

I have a server program running that updates a database and a binary
file every hour - this process takes approximately 10-15 seconds to
complete. There are going to be 300-400 client machines that will
have a client program running that connect to this server program
every day at random times (such as whenever a user logs in). This
client program calls a function on the server that returns certain
data from it's databases. I want to make sure that while the server
is updating, the client machines will wait at a lock or something
similar from threading until it is finished.

Currently, I have all the server and client calls encapsulated in one
large static class, figuring that making everything static would cause
less collisions. I don't know if this is good design, though. From
reading I get the impression that I should separate them into two
classes, but I'm not exactly clear on the best practice for making
this all work in the context of remoting. Any guidance or suggestions
would be appreciated.

Thanks,
Daniel

Feb 21 '07 #2

P: n/a
That's actually exactly how I have it. There is a common library that
has an interface that the Server implements, which basically just
calls functions from the static class.

On Feb 21, 10:15 am, "John Vottero" <JVott...@mvpsi.comwrote:
One problem that I see, I think you're going to have to distribute the the
large static class to all the clients when they don't really need it. You
might be better off defining an interface that the static class implements.
Then, the clients just need the interface definition. You'll wind up with a
client exe, an interface dll and a server exe. The only piece that needs to
be on both ends is the interface dll. That also gives you more options when
you upgrade the server. You don't want to get yourself into a situation
where you need to upgrade the server and all of the clients at the same
time.

"danielh...@yahoo.com" <dahrnsb...@gmail.comwrote in message

news:11*********************@m58g2000cwm.googlegro ups.com...
I am somewhat new to the concept of remoting in c#. Here is my
scenario, if anyone could give me some tips I would really appreciate
it:
I have a server program running that updates a database and a binary
file every hour - this process takes approximately 10-15 seconds to
complete. There are going to be 300-400 client machines that will
have a client program running that connect to this server program
every day at random times (such as whenever a user logs in). This
client program calls a function on the server that returns certain
data from it's databases. I want to make sure that while the server
is updating, the client machines will wait at a lock or something
similar from threading until it is finished.
Currently, I have all the server and client calls encapsulated in one
large static class, figuring that making everything static would cause
less collisions. I don't know if this is good design, though. From
reading I get the impression that I should separate them into two
classes, but I'm not exactly clear on the best practice for making
this all work in the context of remoting. Any guidance or suggestions
would be appreciated.
Thanks,
Daniel

Feb 21 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.