Tag: servers

Asset Risk

, , , , , ,

Julian Lombardi makes some terrific points about asset risk for virtual worlds on his blog. I think the issue is a pretty fertile area for exploration as we all continue to invent new ways of working together, but Blogspot simply doesn’t allow that much content in discussion, so I’ll have to fork it here.

I see the asset risk issue-space as breaking out into at least two dimensions:
* Bit storage vs bit usage
* Point assets vs context

Continue reading

A Great Miracle Happened There

, , , , , , ,

One of the really great things about the WWW, as opposed to the Internet in general, is that the Web separates the concept of naming from everything else. A URL is bit of text that names a resource. You can type it. Except for some long URLs used by banks and in ecommerce, you can often even remember it. But most importantly, you can include the text in some other technology such as an email, an instant message, a calendar invite, a Web page, or even in a book or piece of paper. It can be sent and stored. The URL can be transmitted through this separate non-WWW media, and it still works on the other end.

When you name something, you have power over it. Like the dreidel mnemonic of the title, names help you to remember stuff. You can speak clearly about places and objects instead of just using misunderstood pronouns and long descriptions. And best of all, if you know something’s name, you can use it in casting a spell. (We call them programs.)

So a big part being able to work with virtual worlds, talk about them with other people, and use them in programs is to have a name – a URL that corresponds to each interesting thing about a virtual world.

Continue reading

Scaling to the Enterprise (Part 4 of 4)

, , , , ,

4. HOW RELIABLE IS THE COMMUNITY?

(See part 1.)

None of the previous matters if the software isn’t useful, or if we are not allowed to use the software. The former is what we’re working on, but the latter is a very complex issue. Croquet is certainly not at critical mass. It could certainly go away. However, we feel it is immune at least from licensing plays such as those that have plagued the use of proprietary systems in higher ed, or those that have fractured the Java community. As the number of users in such systems grows, attempts for controlling proprietary lock-in have been very expensive. Croquet fights this in several ways: with an open source license in which all work on Croquet itself is available to anyone; with a P2P architecture that eliminates any advantage to “controlling the servers”; and with a dynamic language that eliminates any advantage to “controlling the release.” We feel that this last will be further strengthened by upcoming work in architecture and security, to be carried out here at UW. For the general health of the community, I look forward to upcoming announcements.

Scaling to the Enterprise (Part 2 of 4)

, , , , ,

2. HOW MUCH USE CAN THE APPLICATION SUPPORT?
(See part 1.)

The architecture of Croquet is very different from that of, for example, J2EE applications. In a client-server application, one server or server “farm” must process each and every interaction initiated by the thousands or millions of users. The only thing processed on the end-user’s computer may be as little as the HTML formatting of the text and image results. Every single other computation must be handled on the big-iron servers. To double the number of users, the capacity of the servers must be doubled. It should be no surprise, then, that so much effort goes into trying to squeeze out each available computing cycle in such architectures.

When an application has state — that is, when results depend on previous results rather than simply generating static files — client-server does MUCH worse. The amount of storage required can go up much faster. In some cases the application state depends on the number of possible connections between users or between applications. The storage (and certain kinds of search-like operations) increases as the square of the number of users or applications (N^2, c.f. Metcalfe’s law). But we are particularly interested in allowing students and faculty to form their own ad-hoc groups among which to communicate and solve problems. A client-server architecture hosting such “group forming” applications would grow exponentially to the number of users (2^N, c.f. Reed’s 3rd law). With only a few users, this architecture would not work at all, no matter how (finitely) fast the servers, or what language the application is written in. (See Reed’s discussion for a surprisingly accessible treatment of value, saturation, and other issues.)

Continue reading