this depends entirely on how 'many' you really mean. If raw speed is
what you need then nothing can be a pure win32 socket approach. With
every layer you add, performance will suffer (but your application
becomes easier to write/manage).
Remoting can scale pretty well depending on the machine hosting it.
I've had machines with hundreds of remote object connections at any
given time without any trouble. But that depends a lot on so many
factors and what specifically you need out of the application.
Allen Anderson
http://www.glacialcomponents.com mailto: allen@put my website url here.com
On Sat, 29 Nov 2003 17:23:31 -0500, "Steven King"
[quoted text, click to view] <smking72@hotmail.com> wrote:
>Hello:
>
>If I build a server of modest complexity (standard data access stuff, etc.)
>are there any statistics to say approximately how many users can be
>accommodated concurrently before the system degrades? I understand that
>there are a plethora of variables so to keep this simple I'm assuming the
>following:
>
>Server:
>2 Intel Xeon Processors @ 750MHz each (minimum)
>1GB RAM (minimum)
>100 Mbps ethernet adapter
>
>+ Server is inside DMZ; accesses SQL Server located behind fireweall.
>+ Clients are outside DMZ, also located behind firewall. Clients may be
>webservers and/or Win32.
>
>I'd be happy to give any more details - as many as you need. Software
>architecture is like this:
>
>1 Solution file containing two projects (C#):
> - Windows Service application (EXE)
> - Component Library (DLL)
> + Contains 1 class that inherits MBR; WellKnownServiceType
>
>Clients register as WellKnownClientType; use "new" keyword to instantiate.
>Component library from server solution also shipped to clients because
>there's some components in that library that are non-MBR but serializable
>that must be sent as params to the MBR class' methods.
>
>THANKS IN ADVANCE!!!
>
>