I need to build a real-time network (client-server) application, where
many clients will send data on a continual basis and the server will
process the data, dump into database and send response back to the
client. So the server needs to be a heavily multi-threaded application
with real-time database writes and with a capability of real time
response. I need to know which language and platform are best suited
to write my client and server application? Client will be a GUI
intensive complex application which will receive huge amount of UDP
packets and shall be required to display the same on a real-time
basis.

I m wondering of using java for my client application development as
it shall make my client platform independent as well as provide good
support for GUI development as well as network accessibility. But i m
not too sure abt the performance that java shall be able to provide as
it has to be a real time application.

Now for my server, I am confused between java and C/C++. I have heard
that writing networking applications is easier in Java and even as a
whole, writing and maintaining code in Java is much easier. Also
database interaction is a factor here. But performance-wise i m
extremely worried. Some googling told me that Java is no longer slower
than C++ but i m sceptical. They say that JIT compilation (some
dynamic compilation funda) makes java actually faster than C++. Is it
true or just a theory? I am not a geek and has been using delphi
sockets for so long. But there have been serious issues in delphi
sockets and I want to look for something else. Can anybody please
help. I am willing to go any extra mile to do the coding in C/C++ but
is it worth the effort. Will the performance difference be
significant?

I have tried creating a sample server Java app, which will spawn one
thread for each client socket connection. I tried connecting 5000
client sockets to this blocking server socket and got "Out of Heap
memory" error in Server! This was concerning as my server application
is expected to handle a much higher number of client connections.
Is it a Java's limitation or my ignorance of better java uasabilty? Is
there any other suggestion than sockets?

I know it was a very lengthy posting but any help shall be extremely
helpful as i m badly trying to battle it out in this technological
web. Thanks to anybody who cares to read this post.

anup.kalbalia wrote:
[..]
> significant?
>
> I have tried creating a sample server Java app, which will spawn one
> thread for each client socket connection. I tried connecting 5000
> client sockets to this blocking server socket and got "Out of Heap
> memory" error in Server! This was concerning as my server application
> is expected to handle a much higher number of client connections.
> Is it a Java's limitation or my ignorance of better java uasabilty? Is
> there any other suggestion than sockets?
>
[snip]

A couple of questions:
- What do you mean by "real time"?
- Why did you choose to use UDP instead of TCP?
- How much data and how many clients do you expect?
- What kind of data is it?
- What kind of database will you use?

Bjørn

On May 24, 10:13 pm, "B. Augestad" <b> wrote:
> anup.kalba...@gmail.com wrote:
>>
>
> [snip]
>
> A couple of questions:
> - What do you mean by "real time"?
> - Why did you choose to use UDP instead of TCP?
> - How much data and how many clients do you expect?
> - What kind of data is it?
> - What kind of database will you use?
>
> Bjørn
>
> --
> Looking for an embeddable web server?[..]

1. I would correct myself by replacing the term real-time by "having
bounded response times". By real-time I meant that the server has to
respond extremely quickly.
2. There shall be both UDP and TCP packets sent to the client. But
there is some data (like ticker data where guaranteed packet delivery
is not essential) which does not require to be TCP as it can do away
with the associated overhead.
3. Clients can be around 10000 or even more...scalability is a big
issue. Data will be huge and shall be of the range of 20-50 Kbps
during peak hours
4. UDP Data shall be generally binary data.
5. Database can be Oracle/SQL. I am also keen on using some in memory
database to improve performance. still tinkering with them. Any
suggestion on that shall be helpful too.

anup.kalbalia wrote:
> On May 24, 10:13 pm, "B. Augestad" <b> wrote:

>
> 1. I would correct myself by replacing the term real-time by "having
> bounded response times". By real-time I meant that the server has to
> respond extremely quickly.

And what do you mean by "extremely quickly"? ;-)

> 2. There shall be both UDP and TCP packets sent to the client.

To the client or to the server? I assumed that the client sent the data
to the server, is that incorrect?

> But
> there is some data (like ticker data where guaranteed packet delivery
> is not essential) which does not require to be TCP as it can do away
> with the associated overhead.

Is there really much overhead to use TCP if you're going to use both TCP
and UDP anyway? (Assuming that the network isn't a bottleneck and
drops/retransmits)

> 3. Clients can be around 10000 or even more...scalability is a big
> issue. Data will be huge and shall be of the range of 20-50 Kbps
> during peak hours

So you'll have 10000 clients, each sending 50 kilobytes per second. (or
is that bits per second?) That's 488MB/s of data.

If you plan to shove that much data into an Oracle database, you have an
interesting project. Even assuming that you meant bits instead of bytes
and that you have a significant protocol overhead, you still have to
move dozens of MB/s.

Even if you can make the TCP/UDP server fast enough, the database server
and the IO subsystem will probably become a bottleneck.

Q: Any idea of the transaction sizes(KB) and the number of
transactions/second?
Q: Any thoughts on what hardware/os you plan to run this on?

> 4. UDP Data shall be generally binary data.

Can you accept packet loss?

> 5. Database can be Oracle/SQL. I am also keen on using some in memory
> database to improve performance. still tinkering with them. Any
> suggestion on that shall be helpful too.

Berkeley DB?
[url down]

BTW, you probably want to read this asap: http://www.kegel.com/c10k.html

Bjørn

anup.kalbalia wrote:
> I need to build a real-time network (client-server) application, where
> many clients will send data on a continual basis and the server will
> process the data, dump into database and send response back to the
> client. So the server needs to be a heavily multi-threaded application

Why heavily multi-threaded? PostgreSQL, for instance, has an excellent
asynchronous client interface. You could get by w/ one thread, or maybe
several, and come out way ahead of any "heavily" multi-threaded design.

"heavily multi-threaded" and "real-time" don't sit well together, unless you
have an eternity to debug, and then another to tune.

anup.kalbalia wrote:
> On May 24, 10:13 pm, "B. Augestad" <b> wrote:
<snip>
> 1. I would correct myself by replacing the term real-time by "having
> bounded response times". By real-time I meant that the server has to
> respond extremely quickly.

Bounded reponse time is the very definition of real-time. But, you won't get
it unless you're actually on an RTOS, like VxWorks or QNX (nor if you're
depending on commiting the data to a SQL database, unless you can make
likely unreasonably special provisions for how data is stored on the
hardware).

> 2. There shall be both UDP and TCP packets sent to the client. But
> there is some data (like ticker data where guaranteed packet delivery
> is not essential) which does not require to be TCP as it can do away
> with the associated overhead.
> 3. Clients can be around 10000 or even more...scalability is a big
> issue. Data will be huge and shall be of the range of 20-50 Kbps
> during peak hours
> 4. UDP Data shall be generally binary data.
> 5. Database can be Oracle/SQL. I am also keen on using some in memory
> database to improve performance. still tinkering with them. Any
> suggestion on that shall be helpful too.

Assuming you must commit the data to your database, you shouldn't even begin
tinkering w/ such an optimization until you've built-out and evaluated the
larger application. Likely you'd be better off handing that extra RAM to
Oracle.

Without being condescending, maybe the best answer given what you've told us
is "just throw hardware at it", and use whatever language you're most
proficient in.

William Ahern <william> wrote:
> anup.kalbalia wrote:
> > I need to build a real-time network (client-server) application, where
> > many clients will send data on a continual basis and the server will
> > process the data, dump into database and send response back to the
> > client. So the server needs to be a heavily multi-threaded application

> Why heavily multi-threaded? PostgreSQL, for instance, has an excellent
> asynchronous client interface. You could get by w/ one thread, or maybe
> several, and come out way ahead of any "heavily" multi-threaded design.

> "heavily multi-threaded" and "real-time" don't sit well together, unless you
> have an eternity to debug, and then another to tune.

Particularly in this case, where it seems all you're doing is effectively
moving bytes. Granted, it can prove to be a challenging task, but there's no
need to add more complexity than necessary.

thanks Augestad.

See, the client will send request to the server. The server will
process that request, dump into the database and send back a response.
There can be thousands of such clients sending such requests
parallely. This shall be through TCP. In the meantime the client and
the Server both shall listen to another UDP socket to get UDP data
which can be at max 20-50 Kbps (which shall happen very rarely during
peak hours). So the data is not being multiplied by 10000. This data
is being used to update some memory list in the server and in the
client it shall be displayed on the GUI after some processing. For
TCP, each packet will be of at max 1 KB. and each client can send a
max of 1 packet per second (at max 2).

For Severs i have still left my options open...whichever (Linux/window
2K) gives me better performance, i will go for that. for clients, it
has to be platform independent. it may well be browser based
also..though not yet decided whether to have separate browser based
app and a separate desktop app.

For the UDP data we can accept packet loss. But for interactive data
for the transaction we shall be using TCP as packet loss is not
acceptable in that case.

Beakerley DB seems a good choice. I am also looking at Times Ten from
oracle. Thanks for the info buddy.

Thanks William,

I agree. There are asynchronous I/O and non-blocking sockets that can
help me do away with heavy multi-threading, where context switching
will actually make my app slower.

By Bounded response time, I mean soft binding, where my response time
needs to be short. About database commit, I am also looking at in-
memory databases. I am not looking at any RTOS as that is not what I
am looking for. May be, rather certainly, I expressed my requirement
incorrectly by mentioning "real-time" and then improperly redefining
it. Ya I agree about the hardware being thrown theory, but will java
be able to handle what is required even if it gets the hardware?
Scalability is an issue here and I am worried about the performance
also that I can achieve out of JVM. is C not better equipped to handle
this?

Thanks William,

I agree. There are asynchronous I/O and non-blocking sockets that can
help me do away with heavy multi-threading, where context switching
will actually make my app slower.

By Bounded response time, I mean soft binding, where my response time
needs to be short. About database commit, I am also looking at in-
memory databases. I am not looking at any RTOS as that is not what I
am looking for. May be, rather certainly, I expressed my requirement
incorrectly by mentioning "real-time" and then improperly redefining
it. Ya I agree about the hardware being thrown theory, but will java
be able to handle what is required even if it gets the hardware?
Scalability is an issue here and I am worried about the performance
also that I can achieve out of JVM. is C not better equipped to handle
this? Can PstGreSAQL handle thousands of client connections?

anup.kalbalia wrote:
> Thanks William,

> I agree. There are asynchronous I/O and non-blocking sockets that can
> help me do away with heavy multi-threading, where context switching
> will actually make my app slower.

> By Bounded response time, I mean soft binding, where my response time
> needs to be short.

I think we all knew what you meant. The critique is mostly that you were
already answering your own questions, which is not the best way to start
asking for advice.

The best way to approach the dozen or so groups you've posted ;) is to come
with very specific, technical questions; you shouldn't expect us to make
your business or architectural decisions for you, because we're simply not
equipped to do so. You and a library of books will fair better.

> About database commit, I am also looking at in- memory databases. I am not
> looking at any RTOS as that is not what I am looking for. May be, rather
> certainly, I expressed my requirement incorrectly by mentioning
> "real-time" and then improperly redefining it. Ya I agree about the
> hardware being thrown theory, but will java be able to handle what is
> required even if it gets the hardware? Scalability is an issue here and I
> am worried about the performance also that I can achieve out of JVM. is C
> not better equipped to handle this?

Java can scale just as well as C, the only difference from this perspective
is the fixed marginal cost of using Java over C. Only you could make that
determination (the fact that this seems like a custom job discounts the
marginal cost considerably, so don't distract yourself w/ the fodder thrown
about by Java, C, C++, C#, Python, Ruby, et al fans).

But, certainly if you're more proficient in Java than C, and there are no
other overriding restrictions, then by all means choose Java. This is the
most important factor, because the [good] languages won't do the work for
you.

anup.kalbalia wrote:
> thanks Augestad.
>
> See, the client will send request to the server. The server will
> process that request, dump into the database and send back a response.
> There can be thousands of such clients sending such requests
> parallely. This shall be through TCP.

Why do you need a server? Can't the clients 'dump' the data into the
database directly?

> In the meantime the client and
> the Server both shall listen to another UDP socket to get UDP data
> which can be at max 20-50 Kbps (which shall happen very rarely during
> peak hours). So the data is not being multiplied by 10000.

That changes things quite a lot, you had me worried earlier. :-)

> This data
> is being used to update some memory list in the server and in the
> client it shall be displayed on the GUI after some processing. For
> TCP, each packet will be of at max 1 KB. and each client can send a
> max of 1 packet per second (at max 2).


I assume that the clients connect to the server, sends 1..n packages and
then disconnects. Is that correct? If so, what's the appropriate value
for n? IOW, for how long is a client connected to the server?

>
> For Severs i have still left my options open...whichever (Linux/window
> 2K) gives me better performance, i will go for that.

POSIX(UNIX, Linux, Solaris, *BSD) and C will give you the performance
needed, assuming that you have the adequate people and hardware. I don't
know of a faster framework. YMMV.

Bjørn

[snip]

>I need to build a real-time network (client-server) application, where
>many clients will send data on a continual basis and the server will
>process the data, dump into database and send response back to the
>client. So the server needs to be a heavily multi-threaded application
>with real-time database writes and with a capability of real time

Not clear that it needs to be multithreaded. That's asking for
hard-to-find bugs and limited portability. How about an event-based
server?

Have you considered modeling this as a web application? Doing so would
allow you to use a prefabricated Java application server such as Tomcat
or Jetty or Glassfish on the server side and a standard web browser on
the client side. The amount of infrastructure already in place to
support such a setup is staggering and, although you may not think you
need to communicate via HTTP, it's as good a protocol as any. All socket
interactions are handled for you, server-side debugging is a joy using
Eclipse or Netbeans ... I used Tomcat for a client/server app even
though I had no need for HTML/GUI interaction on the client side and
have never regretted it.

HT

On May 25, 1:04 am, "B. Augestad" <b> wrote:
[..]
>
> POSIX(UNIX, Linux, Solaris, *BSD) and C will give you the performance
> needed, assuming that you have the adequate people and hardware. I don't
> know of a faster framework. YMMV.
>
> Bjørn
>
> [snip]
> --
> Looking for an embeddable web server?[..]

Thanks a ton mate.

Client cannot dump the data to the database as they will be in
separate network. they shall connect to the server and only server
will have access to the database. n can go upto 10000 or more in the
longer run. The Server should be scalable to handle this load. The
clients are connected through out the day (say 8 hours continuous). In
between they may wish to login and log out.