Ok, here is the scenario:
This will not be an internet application and it will not require security -
nothing fancy anyhow.
The client application is key from image data entry application where
information is read from an image and keyed
by the de operators and the data is sent back to a sql server.
The client starts up and requests a batch of images to data enter.
The unc paths to the image are pulled from the database.
Currently the application is used by only those that are joined to our
network and so they have access to the unc path and
can download the image directly from the file system.
It has been requested that we allow our sister companies (residing all
around the US and some over seas) be able to help out with data entry.
To this point they cannot use the application because they cannot access our
file system.
I am planning on using remoting or tcp server to get around this issue.
Either way, I will pull down 10 to 50 images on a background thread while
the user is performing data entry on a batch.
The max users are currently 20 to 40 users. The max potential probably
around 100 users.
I would like to do load balancing by having the each instance of the host
service that is running on multiple server (~6), whether remoting or tcp
server, update a db table with it's current cpu usage every five seconds.
Before the client starts downloading images it will first see which instance
of the service has the lowest cpu usage, by calling a stored proc, and use
that server to download the images.
The 6 servers are dual Pentium II (650mhz) with 1 gb ram.
There are several applications that run on these servers.
The database is MSSQL server cluster running dual Pentium II processors.
The clients will be WinXp Pentium III or IV.
Thank You,
Michael Lindsey
"W.G. Ryan eMVP" <Wi*********@NoSpam.gmail.com> wrote in message
news:ue**************@TK2MSFTNGP11.phx.gbl...
Hard question Michael in that there's a lot to be considered. I'd agree
that Sockets will be faster but I don't know how much - because it
depends. If you have a lot of users or expect that the user base could grow big
time, then the trade offs are a lot to consider in both directions. Remoting is
a LOT cleaner and a lot easire to deploy, maintain, update etc. You can
also piggy back off of IIS Security quite easily. On the other hand, if you
need every bit of performance you can get, then it's a trade off.
I'd need to know a lot more about the architecture before I could
responsibly make a recommendation. One nice thing about Remoting though
is that you can easily move stuff around and split up the load - we Remote
TONS of stuff and performance hasn't been an issue in more than a few large
scale enterprise apps.
can you tell me a little more about the scenario?
--
W.G. Ryan MVP (Windows Embedded)
TiBA Solutions
www.tibasolutions.com | www.devbuzz.com | www.knowdotnet.com
"Michael Lindsey" <mi**********@alltel.net> wrote in message
news:yQ**************@fe61.usenetserver.com... I need to write a server app to send images to client GUIs that are
outside of the server's domain.
The client will have the file system path to the image but can not
access the file system.
I am trying to decide if I should use remoting vs. writing a server that
uses networkstreams.
I have read that networkstreams\tcp programming should be faster than
remoting and is a better choice for what I am doing but that it is
difficult to code.
I'd like to get
1. a recommendation on remoting vs socket programming for what I'm
doing and
2. If socket programming is recommended ... the url of a full sample
of an ansychronous server\client file sharing application.
Thank you,
Michael Lindsey