CASTrader II Communications Infrastructure

It's past time to get some more programming done on CASTrader.  CASTrader II will be a distributed computing system running lots of little programs that do one thing well and communicate continuously with each other.  One program might run a dark market, one might be an arbitrageur, and one might be a community of genetic traders.  One of my first tasks is to set an infrastructure so these programs can communicate.  Basically, I want to set up a Distributed Command Pattern in .NET.  There's what looks like a good, if dated book on P2P with .NET, with downloadable source code.  Since I'm using .NET as a programming platform, I have a few options, but none of them are particularly appealing:

• .NET Remoting.  This is great in concept, but apparently poor in real-world application.  It's a great idea:  the ability for one program to be able to utilize an object from another program.  There are some good guidelines for using it.  You can even use it for cycle sharing applications.  Unfortunately, some of the most useful (Client Activated Objects and events) features for CASTrader aren't scalable even across a LAN.  I could use these features on each local computer, then devise some protocol for each computer to talk to each other, but I'd rather just use one method.  Remoting in a LAN environment essentially is limited to message passing.  Worse, it can't be used for two-way without additional code, since events aren't recommended, but I could make it work, I think.
• Windows Communication Foundation (WCF).  This is the latest and greatest from Microsoft and looks like it fixes the above, unfortunately, it's still in Beta as far as I can tell.  It's free now, but Microsoft will require me to spend more money to use it once it's officially released.  Sorry, Bill, I'm really getting tired of that, and I'm not going to do it on principle just because the previous technology does not work all that great.
• Old School Solution.  I could just use the old trusty internet technologies of TCP and the connectionless UDP to do what I need to do, basically reinventing the above technologies.  UDP is the lesser known and used technology, and certainly has some issues, and .NET needlessly complicates that in some cases.  It does, however, have a multicast feature that would be useful for transmitting things like prices.
• Old, Old School Solution.  As I mentioned before, I love Unix simplicity, and the simplest solution is inspired by Unix: have programs communicate via simple text files, where each file is a sequential channel of information any of the programs can read or write to concurrently.  I can certainly do this since I anticipate CASTrader to extend no further than a LAN for the foreseeable future.  It seems at least as scalable as the other solutions to me, but I don't know what problems are lurking under the surface when I get a bunch of programs reading and writing the same files concurrently (like corrupt files or performance issues).  My intuition says that there are few with this old technology, even on Windows - they've been ironed out and optimized.  Unfortunately, each program must poll each "channel" repeatedly for new information.  However, with disk-caching, the solution basically runs in memory and can easily be more secure and potentially fast as the other methods.  Better yet, it's serverless (except for the file server), and I need not code any higher level communications protocol or message passer.  It's fairly trivial code and has numerous other advantages I haven't listed.  The only question is - will it work in the real world?

I choose to gamble on the last option for now, since it's so trivial to write and even load test.  The whole thing will be wrapped in an abstract class library that will mask the internals should I need to change it to one of the other methods without changing code in every single program.

Comments

[Danny Liu]

Take a look at this OpenCybele to see whether or not it suits your problem.

http://cybelepro.com/doc%5Cbrochures%5Ccybelebrochure_fin.pdf

Best Regards,
Danny Liu

[Alan J]

Thanks, Danny. Cybele looks quite interesting. I'll investigate it further

[haig]

Microsoft recently released concurrency and distributed services runtimes called ccr and dss. I think they might fit very well with your problem. They were created in their robotics division but are released independently now.

check out the ms robotics pages and/or msdn for ccr and dss

[haig]

BTW, there are also some cool open source avenues using middleware such as ICE (www.zeroc.com) and agent-based systems such as cougaar (cougaar.org).

sorry for the multiple posts, but your blog has got me excited about what you're doing =)

[Alan J]

Haig,

Wow, thanks for the links. Ice looks nice, and so does Cougaar.

This person raves about the Microsoft technologies you mention:

http://marcja.wordpress.com/2007/04/12/the-most-revolutionary-microsoft-technology-youve-never-heard-of/

In any event, I was unaware of any of this, so big thanks to you and Danny for pointing this stuff out!

[Marc Jacobs]

WCF is no longer in beta. It was released back in Nov '06. It offers a number of interesting features, but one of the more relevant for you might be PeerChannel. PeerChannel is a P2P framework that can get multicast-like functionality without multicast. It's a higher-level interface over UDP. The team also has a blog.

You may also want to check out the Digipede Network. It's grid computing platform that is relatively inexpensive, very developer-centric, and simple to use.

If you're distributed computing problems become less embarassingly parallel and more mesh-like, you may want to consider Microsoft Compute Cluster Server. They have created a secure MPI implementation.

Would love to hear more as it develops.

[Alan J]

Thanks, Marc, for the informative comment.

I guess I went to an out of date MSDN website regarding WCF, although it was a download page.

I'll have you know I ate up a few hours watching the Digipede videos. Interesting stuff.

My problem is both mesh-like and parallel at the same time, if I understand the definitions of those terms. Basically, I'll have communities of traders running continuously (parallel) "forever," communicating in a mesh-like network with a market, an accounting system (bank), and consuming a ticker / price / information stream from various providers. My problem leans more towards managing the continuous communications streams than the computation and distribution of code(ala Digipede), since I can generally distribute loads / computation / executables in a "set and forget" fashion (I hope). The P2P type solutions like PeerChannel thus look like a better fit for me.

What would serve best, I think, is reconfigurable (on-the-fly) Unix-like pipes routing continuous streams from process to process.

I'll definately post on what I end up with.