Slashdot Mirror

And, of course, my post is incomplete with reference to my little rant on why CORBA and other forms of RPC are bad. Both Thrift and D-BUS are pretty close to the ideal solution I describe later. They focus on message content over semantics and are extremely easy to parse. SOAP and XML-RPC fail on both of those counts. They are about semantics (you are making a remote function call that does some specific thing, not sending a hunk of data that has some particular content) over content and they are a huge pain to parse.

Why I think CORBA and other forms of RPC are a bad idea.

Here is the paper in brief...

The speed of light is a constant. Latency will never improve beyond a certain point. For all but the simplest things, RPC is the wrong model for dealing with the problem of communicating with other systems.

Also, the abstraction layer of function calls is the wrong place to put the communication of disparate, unrelated systems. It encourages too many assumptions about the implementation of either side. There is too much hidden state in the caller and reciever of the messages.

Te language of constitutional amendments passed in the past 100 years or so has changed in a fundamental way. Most of them now include language that implies that the government is the custodian of the rights of the people. I consider this very bad, and have written up a small paper on it and put it up on the web.

I triple dog dare you to read that book and remain an atheist.

Excellent idea. :-) I've done my part. :-)

I don't think it matters which you use. Allowing people to make functional requests to programs inside your firewall is just as much of a security risk either way. I actually think the function call model is an evil, misleading, broken way of thinking about messages over networks, but like several other practices, people seem bound and determined that this is the way to do things. If you must do this evil thing, it probably doesn't matter (from a security standpoint) how you do it.

The only thing you really gain by not going through port 80 is that the attacker theoretically won't be able to break into your web server software by breaking into your RPC software, but I wouldn't count on that being the case. Besides, either way, they've gotten onto your box, does it really matter how?

Holes in firewalls aren't intrinsically bad things. It's what they lead to that's the problem.

I live in Minneapolis, MN and have a friend who GMs a Matrix style game he designed that's pretty well done. He concentrates on the action aspects of it mostly, and his game design is purposely streamlined to make it fast. It's pretty good.

If you're interested, send mail to me at eric-slash@omnifarious.org and I'll tell you more.

The architecture they say performs the fastest, One-thread-many-tasks (asynchronous), is exactly the one encouraged and supported by my StreaModule system. I knew that things worked out this way, but I'm quite surprised to find such clear agreement by a third party. This idea doesn't really seem to crop up in many places.

There is actually a sort of overall clock in the mind. I remember reading that brainwaves seem to be a kind of general clock signal that seems to be used for coordinating certain activities of conciousness. Sorry to be so vague. The article was awhile ago, and in print. I think in Scientific American.

That being said, I think you're right, the brain is largely asynchronous.

BTW, as a shameless plug, my StreamModule System is also largely asynchronous. It's for IPC though, not for gate-logic.

I would like to start building a P2P system based on the ideas here and The StreamModule System. I expect that it can be built fully decentralized and completely scalable. I also want a lot of careful protocol documentation along the way so people can easily see how to works so holes can be poked before it gets too big.

I really want to build this with my StreamModule system, but nobody is helping me with it, and I don't have the time to hack it out, especially since I'm so ridiculously methodical when it comes to code.

You build something that uses a distributed algorithm to build a spanning tree. The nodes near the top of the spanning tree become the servers. You build the algorithm so that parents in your spanning tree will naturally have more bandwidth than you do.

I've been thinking about this for a long while.

Building the spanning tree isn't hard. Every node just selects one and only one parent node. They tell the parent that they're a child of that parent. You prevent cycles having a parent refuse to be a parent unless it also has a parent. If it loses its connection to its parent, it tells all the children that it no longer is a parent. One node 'seeds' the network as a root by saying it can be a parent without being a parent and not looking for a parent. Eventually it can delegate roothood to a child that has proven high bandwidth. It cannot cease being a root without doing this delegation.

You can have connections to nodes that are neither parents nor children, but search requests should not be propogated to those nodes unless you have no parent. Eventually a search request will make it onto the spanning tree and be efficiently distributed.

You can eventually elect servers who are near the top of the spanning tree. Nodes should, in general, elect parents that have more bandwidth than they do. This means that nodes near the top of the spanning tree should have the most bandwidth.

I carefully read over the post you pointed at, and all the reply threads. You are being premature, and are most likely wrong.

As far as I know, RedHat made a profit before they went IPO. SuSe makes a lot of money doing support and special customizations. Cygnus made money that same way.

Open Source has also been the host to many interesting innovations. DNS, for example, is a widely distributed database designed to handle a certain kind of hierarchical searching. Quite innovative for its time. D. J. Bernstein's software is Open Source, and is quite innovative in its approach to security issues.

I think Open Source represents a viable business model. If I can find a job doing Open Source, I'll take it. I currently do write stuff that's not yet very popular.

Some Linux companies have overextended themselves during the past few years of IPO madness. Some haven't bothered to figure out how to make money yet because of the aforementioned IPO madness. It doesn't mean they won't. No Linux company I know of has gone bankrupt yet.

As I said, I think your assessment is premature, and partially already disproven. You're letting your biases overly affect your perception.

As an addendum, almost any code written for The StreamModule System is immune to buffer overflows because of the way buffers are handled. It's really not hard. The tools are available.

Finally, single-threaded, event-driven programming should not be counted out. It turns out to be the most appropriate, for a surprisingly large number of problems. In some cases, you're better off running several copies of a single-threaded server (say, one per CPU), than a multi-threaded one.

Hear here! If you want a system that encourages writing servers that operate like this, see my StreamModule system.

I believe this very strongly. Multi-threaded programming is just plain hard, no matter how you slice it. Locking only becomes about as second nature as remembering to free all your mallocs, with even more disastrous and insidious consequences for forgetting. Worse yet, under Windows NT, every locking operation becomes a system call with a potential CPU context switch that is expensive in terms of cache misses.

As far as CPU time slice is concerned...

I think 50 milliseconds is fine. The general Unix model is to have most processes spend most of their time waiting for something to happen. Usually when a process has something to do (like if it has to respond to input) no other process has anything to do, and it gets the CPU right away.

If you want to see a stupid design descision, look at NT's virtual memory manager. It's a FIFO memory manager because the system architects decided that attempting to implement any approximation of LRU was 'too expensive'. Therefore, implementing a paging scheme that's guaranteed to eventually kick out high hit pages is a much better idea. NOT!

Of course FIFO is fine if your working set fits in RAM, which is maybe why people throw so much memory at NT boxes.