Opinions on application design?

[Davey]

I am planning on developing an application which will involve skills that I
have very little experience of - therefore I would appreciate comments on my
initial design thoughts.
Overview on system:

I'm not going to divulge the exact aims of the application but the purpose
of it is to allow multiple client applications to retrieve data from a
database (on a db server) and feed this data into another Windows
application using it's C++ API (already provided to me). There could
eventually be thousands of client apps connecting to this server, and the
database could have millions of rows. Each row of data retrieved would
typically have around 5-10 fields of information and rows would only be
retreived one at a time ie each transmission between server and client would
be only one row of data.
Rough design plans:

I plan on having the following major components:-
- The source database
- The server-side application
- The client application which will run on Windows and will use an API to
control another Windows application on the same machine
- The database driven web application

I am planning on making the source database using mySQL due to the obvious
licensing benefits. This side of things is easy to me as I specialise in
databases (although primarily MS SQL Server).

The server side application will be written in Java and will use JDBC to
connect to the database. I am planning on implementing a cache into this app
so that database reads are relatively infrequent in comparison to data
requests from the client apps.

The client-side application will potentially run on thousands of client PCs.
It will request data from the server-side app which it will then feed on to
the other Windows application using the API. I am planning on writing this
in C++ as the API is in C++

The web application will connect to the database and will allow users to
manage the data. I will probably write this in PHP.

Issues/questions:

- What is the best method to allow the C++ client app to speak to the Java
server application (e.g. request, send and receive data) - what about SOAP?

- Will a Java server-side app cope efficiently with for example 10,000
simultaneous client connections with each requesting data roughly once every
10 seconds?

- In these plans I have given the web application a direct connection to the
source database. Is this a serious security risk and if it is what steps
should I take to minimise this risk?

- Is it easy to encrypt the data transmission between the C++ client app and
the Java server app?

- Should I consider any different approaches to the ones mentioned in my
rough design plans?
Please bear in mind that I have almost no experience of writing cient-server
applications so any comments, advice, tips or pointers to relevant reading
material would be greatly appreciated.

TIA.

[Davey]

"Roedy Green" <my************ *************** ***@munged.inva lid> wrote in
message news:nd******** *************** *********@4ax.c om...

On Mon, 03 Oct 2005 17:16:40 GMT, "Davey" <da***@hotmail. com> wrote or
quoted :

then sometimes not for another 10 minutes during typical
usage. Overall though they would use it for a typical working day i.e. 8
hours.
Sockets are for more or less continuous streams. One problem is a
socket takes up considerable resources on the server even when idling.
So sockets are not the way to fly. With HTTP you open a connection,
send in your packet, send back your response (which may take many
packets) then close the socket. Then you forget about that user and
his state (other than perhaps in the database.) They must identify
themselves afresh on each transaction.

The main problem with HTTP is the fussing about sending packets back
and forth to establish and shut down the connection.

I think HTTP is the way for me.
Most of the time you just live with it, but there is another option,
datagrams, not often resorted to. Their drawbacks are:
1. there is no assurance they were delivered. It is up to application
level software to deal with lost packets.
2. packets have to be kept quite short in the order of 100 bytes,
in both directions. to get the benefits.
3. there is no guarantee packets will be delivered in order.
4. all the usual tools presume HTTP, not datagrams.

Their advantages are:
1. no setup overhead.
2. work well peer to peer.

I would not normally bring that option up, but in your case, it looks
as though you have very high volumes, and very simple data structure.
I have *potentially* high volumes, and yes I do have a very simple data
structure.
What you might do is code first in HTTP, then as your load grows, spin
just some stable but significant part of it over to datagrams.

The datagrams suggestion is interesting and I will definitely read into it.

[Davey]

"Roedy Green" <my************ *************** ***@munged.inva lid> wrote in
message news:05******** *************** *********@4ax.c om...

On Mon, 03 Oct 2005 17:16:40 GMT, "Davey" <da***@hotmail. com> wrote or
quoted :

OK, my solution to this problem is reduce the number of users or build
more
servers. The 10,000 was just a figure I hoped I would fit onto one
server...

Some apps you can do that. Others you can't partition the data easily.

Presumably then the each group of users has its own private set of
data,

Yes, exactly.

[Davey]

"Roedy Green" <my************ *************** ***@munged.inva lid> wrote in
message news:tc******** *************** *********@4ax.c om...

On Mon, 03 Oct 2005 17:16:40 GMT, "Davey" <da***@hotmail. com> wrote or
quoted :

If you are trying to do this on the cheap, have a look at how
BitTorrent works. You might do something similar to distribute the
entire database over your users and have them hand it off to each
other.

see http://mindprod.com/jgloss/bittorrent.html

I would like it to be suitable for something like this but unfortunately
it
isn't.

Just making clear I am not suggesting BitTorrent itself, just the
BitTorrent technique of getting the users to store you database for
you and serve it up amongst themselves so you can scale up without
requiring a more powerful server. Users bring some storage, bandwidth
and compute serving power with them.

The problem is that this will not just be used by users at home - it will
also be used by businesses and the nature of the project is such that
bandwidth in these businesses will be stretched to its limit. This means the
distributed model of BitTorrent isn't appropriate for non-home users
(because they will have no spare bandwidth) - unfortunately.

[Davey]

"Roedy Green" <my************ *************** ***@munged.inva lid> wrote in
message news:7g******** *************** *********@4ax.c om...

On Mon, 03 Oct 2005 17:16:40 GMT, "Davey" <da***@hotmail. com> wrote or
quoted :

The data is changing constantly and will potentiall involve large volumes
(millions of rows).

That implies high end, read expensive, SQL engines. It also means
your severs will need a ton of ram. As I mentioned earlier, even the
cleverest SQL engine could not deal with your problem without having
most of the database in RAM.

Unless you have deep pockets, this project may be somewhat before its
time.

To get he sort of performance you need, you would have to store the
records physically on disk sorted by likelihood of use with a totally
in-RAM index with most of the likely records cached. I don't know if
you can get that in SQL.

Hmmmm.

The capacity issues that you are emphasising to me will simply be dealt with
by restricting the number of users per server. To be honest this project
could be successful whether there are 10000, 1000 or 250 simultaneous users
per server.

[Davey]

"Roedy Green" <my************ *************** ***@munged.inva lid> wrote in
message news:cp******** *************** *********@4ax.c om...

On Mon, 03 Oct 2005 17:21:55 GMT, "Davey" <da***@hotmail. com> wrote or
quoted :

Would this offer any benefits over the suggestions by Roedy of HTTP GET
and
sockets? Or would SOAP work in conjunction with these?
Soap in a protocol that piggybacks on HTTP.

HTTP just delivers raw bytes. They could be ASCII characters,
locale-encoded chars, UTF, XML, big-endian binary, little-endian
binary, serialised objects, downloaded files...

For your volumes, you want to pack your messages as tight as possible
and design them to require minimal processing. To me that means
binary.

Soap is a species of XML with envelopes to help you tell what kind of
data you have. If you have many different sort of messages going back
and forth, SOAP provides a way of identifying them and packing data in
a standard way.

The price you pay is obscene overhead.

OK, no SOAP then.
In your case you don't need
that flexibility. You only have one kind of message if I understood
you.

Well, yes I only have one primary kind of message sent from the server to
the client. However there will be different types of messages depending on
the response from the client. Overall, I would say there would be three or
four different types of messages sent.

[Davey]

"Roedy Green" <my************ *************** ***@munged.inva lid> wrote in
message news:s9******** *************** *********@4ax.c om...

On Mon, 03 Oct 2005 17:21:55 GMT, "Davey" <da***@hotmail. com> wrote or
quoted :

Thank you very much (to you and everyone else who has been helpful).

Usually someone with a project this expensive would not be taking
advice from use group denizens.

I hope all you are doing is checking out the viability of your project
should it take off. What you do for a prototype and what you do to
seriously handle these sorts of volumes are quite different.

The project is entirely my own idea, and I won't put any serious cash into
it unless I am confident it is up to the job. I have decent test kit
available and over 100 test users already available when necessary.

Thanks again Roedy.

[Branimir Maksimovic]

Davey wrote:

I am planning on developing an application which will involve skills that I
have very little experience of - therefore I would appreciate comments on my
initial design thoughts.
Overview on system:

I'm not going to divulge the exact aims of the application but the purpose
of it is to allow multiple client applications to retrieve data from a
database (on a db server) and feed this data into another Windows
application using it's C++ API (already provided to me). There could
eventually be thousands of client apps connecting to this server, and the
database could have millions of rows. Each row of data retrieved would
typically have around 5-10 fields of information and rows would only be
retreived one at a time ie each transmission between server and client would
be only one row of data.
Rough design plans:

I plan on having the following major components:-
- The source database
- The server-side application
- The client application which will run on Windows and will use an API to
control another Windows application on the same machine
- The database driven web application

I am planning on making the source database using mySQL due to the obvious
licensing benefits. This side of things is easy to me as I specialise in
databases (although primarily MS SQL Server).
mySQl has table level lock. No problem when just reading, but writes
would usually hang if there are lot of reads/writes.

The server side application will be written in Java and will use JDBC to
connect to the database. I am planning on implementing a cache into this app
so that database reads are relatively infrequent in comparison to data
requests from the client apps.
No need to cache as db and os will cache it for you.
Other side of things is wether java and mysql can handle thousands of
sim.
connections at all?
You can't have thousands of connections on mySQL I'm sure without
DOS'ing
whole system (or you'll need a very big machine).
Even if you do nio in java there is lot of overhead in interface
and all those conversions. In c++ just polling over several k of fd's
burns
a lot of cpu cycles.
Thread per connection is out of question in this case, so you should
cache pending connections and do perhaps num of cpu * 4 requests
in parallel and close connections as soon as possible in order
to reduce number of fd's polled.
IME there are out there rarely more then few dozens of simultaneous
parallel requests, whether you have more then max number of pending
connections or not.
You should meassure how much requests are simultanious and
according to that and number of cpus in the system adjust number
of worker threads. (leader/follower pattern is useful in this case)
If there are more parallel requests then #of cpus can handle (
system becomes unresponsive), the only choice is to buy some new cpus.
Obviously PC's have very limited max. number of CPU's so you should
resort to cluster of PC's in that case or buy some expensive multi cpu
machine (of course, if just link speed is not an limitation).

The client-side application will potentially run on thousands of client PCs.
It will request data from the server-side app which it will then feed on to
the other Windows application using the API. I am planning on writing this
in C++ as the API is in C++
Hm, you have C++ on non critical side and java on critical side?

The web application will connect to the database and will allow users to
manage the data. I will probably write this in PHP.
With php and web server connectiong to mysql with table level lock,
your server will be DOS-ed before you know with several thousand
connections.

- Is it easy to encrypt the data transmission between the C++ client app and
the Java server app?
Yes it is easy. You can use avail. libs (openssl is one) or write one.

- Should I consider any different approaches to the ones mentioned in my
rough design plans?

Yes, indeed. You don't need php if you have client app in java or c++.
Think about server side app. It can't do thousands of reqests in
parallel
on cheap machine without some extreme programmers effort and knowledge
..
Greetings, Bane.

[Roedy Green]

On Mon, 03 Oct 2005 21:36:59 GMT, "Davey" <da***@hotmail. com> wrote or
quoted :

The capacity issues that you are emphasising to me will simply be dealt with
by restricting the number of users per server. To be honest this project
could be successful whether there are 10000, 1000 or 250 simultaneous users
per server.

That gets you off a lot of hooks. It also lets you use cheap small
servers rather than great honking expensive ones. I was looking at an
ad the other day for one from HP where rackmount servers by the
dozens. Each had a 64 bit opteron CPU.

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

[Roedy Green]

On Mon, 03 Oct 2005 21:40:02 GMT, "Davey" <da***@hotmail. com> wrote or
quoted :

Well, yes I only have one primary kind of message sent from the server to
the client. However there will be different types of messages depending on
the response from the client. Overall, I would say there would be three or
four different types of messages sent.

Complexity happens.

So there is a good chance that number of message types will expand,
but you are still in the ballpark where you can compose those messages
with DataOutputStrea m or LEDataOutputStr eam without being overwhelmed.
This the fastest way to compose and disassemble messages.

When you have scores of different messages then you need generic tools
so you don't have to hand code the construction and taking apart of
each message, e..g. RMI or serialised objects or CORBA.

Messages coming back from the server are raw bytes. However messages
going in have to be ASCII text. To pass awkward characters or binary
in, you need to use URLEncoding. See
http://mindprod.com/jgloss/urlencoded.html
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

[Roedy Green]

On Mon, 03 Oct 2005 18:28:56 GMT, Roedy Green
<my************ *************** ***@munged.inva lid> wrote or quoted :

The main problem with HTTP is the fussing about sending packets back
and forth to establish and shut down the connection.

HTTP has a large number of optional fields in the header. These are
to help the browser deal with a generic source and render it. In your
case everything, even the length field is not really necessary.
Everything you need to know will be in an identifying header of the
message itself. Pruning those down will help speed transmission.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.