-1

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

closed as too broad by user22815, user40980, JeffO, Kilian Foth, GlenH7 Mar 9 '15 at 14:04

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • On a 1 gigabit network, the realistic maximum amount of data that can be sent in one second is one gigabit (about 100 megabytes), minus some overhead (say, 10 percent, give or take), if nobody else is using the network. It's very unlikely that you need that much bandwidth in a good design, however. – Robert Harvey Mar 8 '15 at 15:36
  • I want you to configure the networks I have to use. I rarely get that high a utilisation, I usually get around 70MB/sec, – Michael Shaw Mar 8 '15 at 19:32
3

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.

  • It's probably closer to 100 MByte, but yeah. I upvoted this answer because it's the only one that included an estimate based on the actual LAN speed. – Robert Harvey Mar 8 '15 at 15:36
  • the application are desktop apps, how does RESTFUL apply ? – Smith Mar 8 '15 at 19:04
  • REST is an approach that makes heavy use of the HTTP protocol to define the way the client and server communicate with each other. Think of it as a way of doing web pages that computers can understand. This is a well respected and heavily tested strategy that there are plenty of tools to help you implement and diagnose. You can write your own protocol and using a TCP connection or UDP packets, but you are increasing the risk that you introduce problems that become painful later, and you will have far fewer options to turn for guidance – Michael Shaw Mar 8 '15 at 19:24
  • Estimation on LAN speed is ... CRAZY. Unless you are a in a nerdish company that allow to keep servers directly under your desk (or as your chair), servers are in data-centers, clients are on LANS and there is a WAN in the middle whose performance greatly depends on where your clients are in the world. With nowadays parameters, a lient CANNOT TRANSFER more than 16KBytes/Rund-trip because that's how TCP works with M$ configuration defaults.... – Emilio Garavaglia Mar 9 '15 at 7:28
  • .... Even a 1Gb/s LAN that spans more than 2 Km with 4 switches in the diameter don't allow client/server transfer rate greater than 15-20MB/s. And having the LAN faster won't help, since after 1Gb/s the trasfer rate, with 16KBytes buffer is dominated by the signal propagation delay. Sometime software engeneer are so... abstract to even forget there is physics downside. – Emilio Garavaglia Mar 9 '15 at 7:29
3

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.

0

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.