views:

731

answers:

10

I am going to develop real time application which will receive stock market data and doing some processing then disseminates to client application. I decided to divide the calculations between the server and client the server will make the basic calculations then will send the basic data to the client which calculates the final variables.

I decided to develop the client application (GUI only) using C# and the component which will calculate the final variables (called:variables calculator) using C++. the aim of developing "variables calculator" in c++ is for modularity. for example if I found the variables calculations will take more time on the client side I can use the same module on server side.

Also I will develop the server side using standard C++.

Notes: The server should process set of messages and send it to client in less than one second The maximum number of messages come at the begining of the market 100,000 messages

Any suggestions?

+2  A: 

These days, language choice imo does not have as much importance as what it use to when it comes to client/server applications which do not require large amounts of processing power. Java, C#, C/C++ will perform similarly (Obviously native languages will have some advantage), as long as you know how to build good architectures. I would take into consideration ease of use and amount of useful libraries available for each language to make my decision. I dont know what your calculations exactly require or what stock information you are processing, but look into libraries and GUI development tools and go from there...

+3  A: 

The definition of what's a "real-time" application is pretty blurred these days. Your real-time constraints may be microseconds of months, depending on the application, and your choice on language, OS, and tools will all depend on those things.

In this case I can't see why you shouldn't use C# on the server side as well. Maybe there are constraints you haven't mentioned, but from what you said I see no reason to introduce a second language into your problem.

Roddy
+4  A: 

I disagree about "real-time" being a blurred definition. More likely, people just don't understand what is meant. Real-Time refers to a system's response time being the same as the real-world system. You can actually have a system be faster than real-time, causing problems similar to having a system slower than real-time.

As such, I do not believe you are asking for language use in reference to a "real-time" application, as much as for a really fast application.

Check out the language shootout and see what does the best on the kinds of tests that best approximate your design space; however, my gut answer is to use C.

Dan
...real-time computing (RTC) is the study of hardware and software systems that are subject to a "real-time constraint"—i.e., operational deadlines from event to system response... (wikipedia) how is this greatly different from what I said?
Dan
I think Dan is right, krosenvold. Real-time means that a system's response should be in less than a certain time in order to be useful or avoid a disaster. And I don't see any real-time requirement in the original question.
Marc
OK, sorry about that.
krosenvold
You talked about "respone time the same as the real system". What do you mean by the "real system"?And yes, financial systems are critical real-time systems. Not 50hz video real-time, but there are significant time constraints that MUST be met for the system to be effective.
Roddy
@Roddy I fell into the same trap and downvoted this one initially. Since it was not only me I edited Dan's post.
krosenvold
@Roddy I was thinking about simulations because most of my experience is in that realm.
Dan
+5  A: 

Having worked for investment banks for nearly 30 years. I've written many applications like this. The underlying issue that you need to solve probably isn't real-time performance, but rather latency and throughput.

Latency in this context is about reducing network delays, and the language choice isn't very relevant.

Throughput is about large processing capacity sustained over long periods of time, whereas performance is about very large processing capacity for short periods of time. Although language choice in this context is more important than with latency, it's usually not as critical as you might think.

Of the two, it's normally better to design for the lowest possible latency first. Throughput problems can be solved later in development by various tricks, but getting rid of high latency baked into an existing design is much harder.

So I would go with C# on both the client and the server, at least for the proof-of-concept. It's not necessary to introduce additional complexity (another language) to solve a problem that isn't likely to be important.

EDIT: I noticed that you edited your question to say that the server needs to process up to 100K messages in no more than 1 second. I doubt that you can achieve this with software, but you might be able to by using a combination of software and hardware.

If you really do need this level of low latency (and I've never needed it in 30 years in the business), then again the language choice isn't nearly as important as having very high bandwith together with a super-optimised and parallelised algorithm. But I would first question the requirement to see what they really mean - I bet it's not what they said.

RoadWarrior
+6  A: 

What exactly is the real-time constraint that you have to work with? Micro-seconds, milli-seconds, seconds?

Does it actually need to be real-time, or simply high-performance?

Assuming it really needs to be real-time, the language is unlikely to be the most important thing in the system, and you are mostly likely to be constrained by the rest of the run-time environment. E.g: libraries you use, network stacks, network protocols, operating system, CPU architecture, memory, cache etc.

All that said, C is probably going to give you the best combination of ease-of-use and knowing what the underlying system is doing. If you know C++ very well, then it would also be suitable if used with a strict coding standard. If it is extremely high-performance, or has extremely high predictability requirements then you may need to drop to assembler code, but this would be unlikely, and chances are the compiler has a much better understanding of the CPU pipeline than you do, and it would be impractical for anything over a few thousand lines-of-code.

f course, if you just need some relatively fast, then I don’t the real-time-ness should be your prime consideration in language choice, and rather availability of suitable libraries and tools, developer team experience, suitability to the application, etc would be more important considerations.

benno
A: 

You could look at Adaptive Communications Environment, which is a portable server framework for writing high-performance servers in C++. This Stackoverflow posting has a series of links that describe it and fan out to various resources.

ConcernedOfTunbridgeWells
A: 

The gut answer of Dan is wrong, looking at the site he posted is clear how nowaday C++ (gnu/intel implementation) outperform C implementation

Gaetano Mendola
A: 

I'd take a look into Erlang ! Their architecture seems like a perfect fit for applications like this.

A: 

If you really want low latency and high throughput I suggest you remove any data processing within the server (calculations). If you really want/need to do calculations not on the client I would set up another server that provides a complementary data stream of derived data. That is, your calculated values based on the original/raw feed.

What kinds of calculations are you talking about?

How are you planning to handle the throughput in the network and on the network stack? Do you have latency measurement tools/sniffers/endace card?

Tim
A: 

I have also implemented such a system, and I think RoadWarrior actually sums it up very well.

This is a terrific application area for message queues, and if you leverage a good underlying MQ technology I believe you could meet your throughput requirement in almost any programming language, even higher level interpreted languages .

krosenvold