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.

First of all, before you start a fight between C++ and Java fans, which one
is faster is inconsequential to your application. The reason is that Java
is not well suited at all for real-time applications. One reason, the garbage
collector. In fact, for truely real-time apps, your best option is C and
assembly. Reading your post, I think that you really don't understand what
real-time is especially as it concerns your system. Maybe some background
reading on the subject would be helpful. Once you do that reading, you will
probably come to the conclusion that what you want to develop is a system
that maintains soft real-time (bounded response times) performance in the
face of at most XXXXX clients (asynchronous tasks) with YYYY resources available.
This may mean that you need a real-time operating system (RTOS), if you
are pushing the limits of your hardware.


By the way, you can increase the amount of memory that the Java VM will have
access to so your heap won't fill so quickly.


---Matthew Hicks

anup.kalbalia@gmail.com wrote:
Yes.

Yes, although other languages are much better than Java.

Java can be much slower than C++:

http://www.ffconsultancy.com/languag...r/results.html

Java might be faster when lack of GC makes C++ prohibitively difficult to
write.

This depends entirely upon what you're doing.

C++ is not worth using anymore. A combination of high-level languages and C
works better.

Again, there are much better languages for asynchronous processing, like F#.

No idea. There will be information out there on which techniques to use when
you need massive parallelism. You might try asking in an OS-specific ng.

Have you considered C#?

--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/product...ournal/?usenet

On May 24, 10:05 pm, Matthew Hicks <mdhic...@uiuc.edu> wrote:
Apologies if it seemed to be so...
I correct myself in accepting that it is not a Real-Time application
in true sense. I accept i m not geek. By real-time I meant real fast
response time. C and assembly may give me that performance but then
assembly shall be an overkill i guess. Is it really required to go to
that low-level? As I mentioned that code maintainability shall also be
an issue and that is the main reason of my confusion over the choice
Java and C/C++. Suggestions on this shall really very much appreciated.

On 24 May 2007, anup.kalbalia@gmail.com wrote:

Just a little word of warning: "real-time" and "network" rarely play
well together when "real-time" is supposed to mean deterministic and
fast and "network" means IP. There's nothing particularly "real-time"
about the typical TCP/IP stack, even when you're using UDP.

That said, I suspect the platform(s) you host the client and server on
will have more to do with performance than whatever language you choose
to implement them in (unless you choose really badly ;-), and how much
and what kind of "network" is between the clients and server will
determine what kind of "real-time" expectations are reasonable.

BTW, I also doubt that your server will profit from having more threads
than there are CPUs. Massive numbers of threads lead to much time
wasted doing context switches and poor memory usage. Take a look at
the archives of comp.programming.threads for more information.

Dave

--
D.a.v.i.d T.i.k.t.i.n
t.i.k.t.i.n [at] a.d.v.a.n.c.e.d.r.e.l.a.y [dot] c.o.m

On May 24, 10:45 pm, David Tiktin <dtik...@nospam.totally-bogus.com>
wrote:
Hey thanks Dave....that was really nice piece of advice. I agree with
u that network applications cant be real-time. What i need is a fast
response actually. What platform would u suggest? The network will
generally be LAN or a VPN. the latency associated with the network is
acceptable. But the Server need not added to that and should also be
scalable. Any suggestions whether Java can handle that? I agree that
even more number of threads may not be a solution due to the inherent
context-switching issues. Non-blocking I/O or asynchronous IO is also
something i tinkering with. Suggestions shall be very highly
appreciated.

On May 24, 10:39 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
Which ones? So what should I go for?
What does that mean? If we can write C++ then should we go for it?

1. Receive and send response through Sockets. 2. Database Interactions
in each cycle. 3. Some memory calculations (Searching in memory lists
and updating them)

Which high level languages are you recommending?

interfacing?

Parallel threads was my idea of servicing client request separately.
Is there a way to avoid that like asynchronous I/O?

Not exactly. Dont know whether that shall be a good substitute or not.
Does that not limit the possibility of writing the app only on
windows?

Thanks for the response

anup.kalbalia@gmail.com wrote:
Probably the bottlneck will be the server so Java should probably be ok,
but as an alternative you might want to consider using Curl instead, see
http://www.curl.com (disclosure: I work for Curl).

It can be, but only if you are skilled enough. If your server is not
especially complicated you are probably best off writing it in Java and
later rewriting it if the performance is good enough.

- Christopher

anup.kalbalia@gmail.com wrote:
Java may in some cases use a bit more CPU to do equivalent things, but
even if that is the case, it is not important. The reason is this:
your bottleneck will not be the CPU usage; instead, it will be the
design of your application. Design decisions like your threading
model (how many context switches, etc.) will make more of a difference
than whether Java uses a little more CPU to get the same work done.

You need to look at the documentation for your JVM. It should have
an option to increase the maximum heap size. This is the limit you
are running into. With the Sun JVM, the option is "-Xmx". For example,
to give your JVM 512 megabytes (maximum) of heap, you would do
"java -Xmx512m" instead of just "java". If you are using a different
JVM, there may be a different method of setting this.

Second, having a thread for each connection is not very efficient.

One of the good things about Java in this area is the capabilities
that java.nio has. It makes it pretty easy and pretty clean to use
a non-blocking I/O model. Then you can have a few threads, perhaps
a number close to the number of CPUs (or CPU cores) you have, and
each of them dealing with many clients. This should result in
better performance.

If you need to handle more than 5000 simultaneous connections,
you are may have to tune the OS as well. I recently tried this
on Linux, and I found that I needed to increase the per-user limit
on open files in order to even have that many sockets open. This
will be an issue no matter what language you use.

Also, you mentioned the client will be using UDP. If that is the
case, then I'm not even sure you need to have a separate socket
for each client. You should be able to have one UDP socket that
sends and receives packets for all the clients. This might
simplify matters.

On the other hand, if you have to talk to a SQL database over a
TCP connection, that is going to make things tricky, because you
will have to wait on the database. That means you probably need
threads to talk to the database since probably you can't control
whether the database calls will block.

- Logan

Matthew Hicks wrote: ** and top-posted - fixed **
A good answer. But ...

Please do not delete attributions for material you quote.

Please do not top-post. Your answer belongs after (or intermixed
with) the quoted material to which you reply, after snipping all
irrelevant material. See the following links:

--
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/> (taming google)
<http://members.fortunecity.com/nnqweb/> (newusers)



--
Posted via a free Usenet account from http://www.teranews.com

anup.kalbalia@gmail.com wrote:
Yes, to all practical purposes. Avoid it.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net


--
Posted via a free Usenet account from http://www.teranews.com

On May 24, 12:41 pm, anup.kalba...@gmail.com wrote:
Spawning a thread for each client connection is like using a sledge
hammer to pat a baby on the head. Not a good idea.

All the problems of high speed communication with huge numbers of
clients serviced in parallel have been considered and solved by
thousands of people in the development of web servers like Apache and
(even) IIS, which are available for free. As such, you should make
herculean efforts to map your problem onto one of these general
purpose engines.

You mentioned the need for UDP with no explanation for why UDP is
necessary. It's pretty likely that an application that starts out
with UDP facilities will end up with socket streams. Why? U =
UNRELIABLE, and it's very common for a spec that seems satisfied by
UDP to need reliability in the final analysis or else in the first
rev.

Continuous-seeming "real time" update connections can be maintained in
HTTP. See http://video.google.com/videoplay?do...82187051229467
on XML11.

Once you decide that the services you need can be mapped onto HTTP,
the implementation language is fairly unimportant. You can pick based
on good software engineering reasons like maintainability rather than
performance-dictated ones. Network services in assembly language.
Argh....

Good luck...

anup.kalbalia@gmail.com wrote:
Not at all.

Matthew's post is actually wrong in several ways, so I wouldn't worry.

The phrase "real-time application" includes everything from flight control
on an aircraft to the renderer in a computer game. When real-time deadlines
must be guaranteed (e.g. people would die if the deadlines are not met),
this is referred to as "hard real-time". Most real-time applications
(primarily graphics) are soft real-time.

So you were quite correct to use the phrase "real time".

Exactly.

Not really overkill, they are the wrong tools for almost every job nowadays.
Assembly is good for compiler writers and C is good for systems
programmers.

Absolutely not. There are many high-level tools that provide hard real-time
guarantees.

We develop professional visualization tools for scientists and engineers and
we use garbage collected languages exclusively. The arguments against the
suitability of GC for soft real-time applications and high-performance
applications have been invalid for years now. There is no reason to avoid
GC. Indeed, we are particularly interested in worst-case performance, which
we improved five fold by ditching C++ in favour of OCaml (a high-level
garbage collected language).

C++ programs typically deallocate in cascades of object destruction, leading
to significant stalls. In contrast, a modern garbage collectors are
incremental, spreading the work over several invocations and greatly
improving worst-case performance.

Just from your description I would definitely choose Java for this task (of
the two languages). GC makes things simpler and Java has much better
support for databases. Java is a cleaner language, but there are much
better languages out there.

--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/product...ournal/?usenet

On May 24, 1:41 pm, anup.kalba...@gmail.com wrote:
Possibly of interest:

"Tame is a new event-based system for managing concurrency in network
applications"
http://www.okws.org/doku.php?id=okws:tame

Also, built on it: OK Web Server - http://www.okws.org/
http://www.okws.org/doku.php?id=okwsublications