what are the limits of the client server architecture [closed]

i have developed a POS app as a stand alone app with its own database.
A customer needs 10 of the app in different PCs, but it should use one database.
This quickly brings a solution to mind. A Client/Server solution, in which the client apps talks to the server app. The server app will now be the one with the database

for each sale, the clients will be pulling current stock data/customer data/etc and also sending sale data to the server (at least every 20sec)

I need to know the realistic limits of data size that can be sent per second in a lan
Is my solution a good one

Are there any other solution that would be faster and better.

Please take note that each clients needs to login before performing anything on the client or server

An the clients activity needs to be monitored by the server

EDIT

The app would work in an office with four computer, the space between each client and the server is less that 100m

For now, there are only 10 client and one server

The lan speed is about 100 MB/s

The limitations of Client / Server implementations are well known. Moving from a stand alone application to a client/server approach introduces some new issues for you to manage.

The Server will have multiple connections simultaneously. Handling this efficiently enough without having different clients causing contention on the database should be straight forward to solve with only 10 clients talking to the server.
Adding a network and a server adds latency. as its on the same LAN, this is will not be huge per request, but keep an eye on how chatty your client needs to be with the server.
You have to decide the protocol that the client and server use to communicate and understand each other. A RESTful web service may well be a suitable approach for your needs
Change management. When its one block of hardware, updates happen in isolation of other systems. Now, when you need to roll out an upgrade, you have multiple clients talking to a server, rolling out upgrades needs a little more thought.

As you are interested on what kind of performance you can expect over a LAN, here is my view…

The typical network in an office is 1GBit Ethernet, that’s capable of transferring to the server a maximum of around 50 MByte of real data a second. If you are reaching this limit you have a serious design problem in your client server protocol.

If you have performance problems, the solution will be to make the client/server protocol more efficient, and that may mean more changes to the way the client side works than you are currently expecting.

This kind of project is interesting work, and may take you some time to deliver it right. Make sure you have the spare time (and budget) for coping with the new learning you will be doing.

Answering this question with hard numbers would require knowing the number of clients, the quality of their network connections, the distances between them, each other and the server, how quickly the server responds to every possible request (at peak times!), and all sorts of other details. I would guess that the quality of their connections is probably where the hard upper limit lies.

The only reliable way to find out the concrete limits of an architecture is to build a prototype and test it. This is why “agile” methodologies are all the rage these days. Since you’re talking about a LAN, it should be pretty simple to grab a dozen machines, hook them up in a similar fashion to your clients, and put simple programs on them that bombard each other with fake stock information.

P.S. To answer the more general question your title appears to be asking, the architectural limits of client-to-server are all about what the server(s) can do. When you add a lot more clients, you’ll eventually need to add more servers (and load balancing), no matter what the app is; some apps may scale better with peer-to-peer. And of course, all network architectures are limited by speed and bandwidth of the network connection.

The first thing you’re going to want to do is figure out the requirements. If the customer says they currently need 10 clients, how many clients will they need in 5 years time when they shift to a larger premises? Will they want to have to completely redesign their POS system if/when that happens? Will they want to add other functionality later on (like stock management, or generating reports)?

The second thing you’re going to want to do is figure out how you’re going to approach fault tolerance. If the server goes down for any reason, do you want 10+ clients that are unusable and 10 checkout operators getting abused by impatient shoppers? Can you cache information at the client until the server comes back online? Do you need fall-over? How will you be doing backups (will you need to take the server offline to do the backup)?

The third thing you’re going to want to do is decide on the protocol that clients will use to communicate with the server. Can it be raw SQL (with nothing more than a database running on the server)? Do you need additional layers in the server?

The fourth thing you’re going to want to do is create a simulation/model of it. The idea here is to determine if the plan is viable (where are the bottlenecks, will the server’s LAN connection need to be faster than the client’s to keep up, how many clients could it handle, etc). You do not want to have one team of developers working for 6 months building the client software, and another team of developers working for 6 months building the server software; and then find out that it can’t handle the load after its too late.

Filed under: softwareengineering - @ 17:59

Thẻ: client-server, networking, tcp

Thiết kế website giá rẻ

Danh mục

what are the limits of the client server architecture [closed]