Re: Client Server application design

Hi all,

Thanks for the detailed inputs. Let me make it very simple and then
I think I can build on the simple model.

It will be somewhat similar to a web-server in terms of the
functionality
it has to offer. So for the time being we can assume it to be a
web-server handling multiple client connection requests and
processing them at the same time.

For such a client-server model what is the recommended model to work
on.
Client status is not a very important thing, it will be just client
name and whether
it is reading data to the server or getting data from the server. It
is not a must
requirement. Even if it is not there, it is fine. Most important
thing is how the incoming client connections are handled. What is the
best workable approach for that.

For now it is will be a hosted application.

Thanks and Regards,
Pushpa


On Jun 21, 9:07 am, David Schwartz <dav...@xxxxxxxxxxxxx> wrote:
On Jun 19, 7:24 am, push <pushpakul...@xxxxxxxxx> wrote:

I have to design a client-server application with both server and
client on Unix platform. I have the following pre-conditions for the
same.
1. The server has to support minimum of 5000 clients at any point of
time. It should be extendible also.

It's very hard to do this with a thread-per-client approach unless you
have a lot of control over the hardware. Is this a hosted application
(that is, only you will run it), or is it a product (that has to run
on varied hardware over which you have less control)?

2. Also at any point of time I would need to know the status of the
client. I need to store the
status of the client somewhere.

The more shared state you have, the more sense it makes to use a
single process. You can also store state in the filesystem, in shared
memory, or in a database. What makes the most sense depends on how
much state you have, the ratio of reads to writes, and many other
factors.

For scalability, it's often best to use a database back end. This
makes it easier to scale to multiple servers in the future.



3. Client essentially sends some data to the server and also gets the
data from the server.

Since the server has to support so many clients is it advantageous to
use a multithreaded approach
or a multiprocess approach. Is it advisable to keep a pool of threads
to service the clients. Or is it
advisable to create a thread whenever a client request comes in to
service the same. If the creation
of a process is not prohibitive enough can a process be created to
process each client's request.
Does it make sense to create a pool of processes to service the
request. Keep the list of processes
and then attach it to each client. I am not sure how a process can be
attached to a client request.
Is there any way to do that on Unix.

It is possible, though generally very difficult, to use a pool of
processes much the same way you would use a pool of threads. You have
to hand off file descriptors if a process doesn't already have the one
it needs (you can essentially keep a 'cache' of client file
descriptors in each process, whether or not the process happens to be
using that descriptor at the time).

You can't just use shared memory directly as you can with threads. You
either have to have a common parent process that makes the mappings
before 'fork'ing off the children or you have to map the shared memory
separately in each process, possibly at a different address (which
means pointers must be offsets and have to be translated in each
process).

I don't recommend process pool approaches unless you're very
experienced with multi-process and multi-thread I/O approaches and
synchronization already. It's a lot harder.

IMO, the only advantage of process pool that makes it worth the
additional effort is if you have to run code that's not fully trusted
and don't want to risk killing the entire process and losing all
client connections. However, even in this case, I still prefer to
encapsulate the untrusted code in its own process. (You can hand off
the file descriptor, have the main server proxy, or whatever makes the
most sense for your situation.)

For storing the status of the client is it advantageous to use
database/in-memory/file-system considering the
fact that I need the fastest response time. Since I have to stored the
status of all the 5000 clients, what is
the best way to store and retrieve the same.

How often does the status change? How big is the status? Is each
client identified by a well-known name? You can also have a data
storage service process and have multiple client-handling servers talk
to the one data storage service. Again, it depends on the details of
your application. There are a lot of approaches that are neither
always wrong nor always right.

How should I handle the client requests which cannot be accepted.
Should it be queued up in some
datastructure or any other approach.

What do you mean? Why wouldn't you be able to accept a client request?
And how much control do you have over the client? (Are you writing it?
Or are you implementing a protocol over which you have no control?)

If someone can give some inputs on this, it will be great.

I can't really answer your questions because a lot more information is
needed. But I hope I've pointed your thoughts in a useful direction.

DS

.

Relevant Pages

  • Re: What doesnt lend itself to OO?
    ... >> proxy and instructs the server to constuct the real object. ... rather than client code. ... If 'clock' is instantiated in the server, ... > for the server interface at the OOA level. ...
    (comp.object)
  • This is going straight to the pool room
    ... or not the client has privilege to do what they're trying to do, ... The server environment is this: ... 3GL User action Routines that Tier3 will execute on your behalf during the ... Routine Name: USER_INIT ...
    (comp.os.vms)
  • [Full-Disclosure] R: Full-Disclosure Digest, Vol 3, Issue 42
    ... Full-Disclosure Digest, Vol 3, Issue 42 ... SD Server 4.0.70 Directory Traversal Bug ... Arkeia Network Backup Client Remote Access ...
    (Full-Disclosure)
  • Re: What doesnt lend itself to OO?
    ... > rather than client code. ... no way to do that without also touching the object with clock semantics ... will not encapsulate both clock semantics and network semantics. ... The server can do whatever it wants ...
    (comp.object)
  • RE: Fax monitor incoming + outgoing calls?
    ... problem between the client computer and the SBS server. ... Client is using the internal IP address of the SBS server as the ... To the folder redirection GPO issue: ...
    (microsoft.public.windows.server.sbs)