Whether you want to write an entire Web browser or just want to add a small networking feature to your application, this article is for you. For purposes of this article, I classify network applications into three areas:

• Applications that follow a standard protocol such as FTP.

• Applications that use their own protocol ("original applications"), but are designed to work across several operating systems.

• Original applications that only work under a single type of operating system.

For standard protocols, there is undoubtedly some freely available Unix code that will do the trick for you. A little searching around on the Internet will find the code you want. It will be socket-based, and will already be designed and debugged—all you have to do is port it to the BeBox. And since the API on the BeBox approximates sockets, porting socket-based code shouldn't be much trouble.

For original applications which you hope to port to other operating systems, you might need some help. If you aren't already familiar with sockets, a good place to start is "Unix Network Programming", by W. Richard Stevens. The most important point to keep in mind when you're designing your protocol is that different processors represent the C data types differently. The most common causes of problems are assumptions about the sizes of the basic types, field alignment within structures, and the endian-ness of multiple-byte data. There are a number of ways to deal with these issues:

• The simplest method is to convert everything into text before sending it to the network. Text is, of course, extremely portable, and has the added advantage of being easy to debug since you can easily see from a captured data packet exactly what was sent. Text conversion may seem inefficient, but many fine protocols—including HTTP—use this technique. Furthermore, if your application is intended to run across the Internet, the inefficiency won't be noticed since the Internet runs at a pretty slow speed.

• Beyond that, there are several commercial and free packages that can make your life easier. One free package, which has already been ported to several platforms, is the Sun RPC/XDR source code distribution. It is widely available on CD-ROM and through various FTP sites on the Internet.

Okay, perhaps you are saying, "Standards? We don't need no stinkin' standards!". You just want to write something that is BeBox specific, and you really don't want to use text or learn about some stinkin' RPC package. I have just the thing for you...

I've written a couple of C++ classes (NetServer and NetClient) that send and receive BMessages over a network. If you're familiar with BMessages, you should have no problem with these classes.

A NetServer object listens for in-coming requests (BMessages) that are sent by NetClient objects. When it receives a message, NetServer does whatever it is that you need it to do, and then sends a response to the NetClient.

A typical NetServer setup looks like this:

BMessage *request;
BMessage *reply;
NetServer *server;

server = new NetServer(UDP_port);
for (;;) {
   server->ReceiveMessage(&request);
   reply = new BMessage();

   /* Here's where your application-specific
    * code goes, including the formulation of
    * the reply message.
    */

    server->SendReply(reply);
    delete request;
    delete reply;
}

As shown above, the NetServer is created in reference to a UDP port number (the argument to the constructor). You can use any port in the range 1 through 65535, but stick to ports above number 1024—lower ports are reserved for standard protocols like FTP. Also, you should make the port number configurable if you intend to ship your application. This way, if it conflicts with another application, the user can select another port to resolve the conflict.

On the client side, the NetClient configuration looks like this:

BMessage request;
BMessage *reply;
NetClient *client;

client = new NetClient(serverHostName, UDP_port);

/* format your BMessage here */
client->SendMessage(&request, &reply);
/* examine the reply */

The NetClient is served by a NetServer that's running on the machine "serverHostName" and that has the given UDP port number. The communication between the client and the server is straightforward: The NetClient sends its message, the NetServer receives it and sends a reply, the NetClient receives the reply, and then (possibly) sends another message, and so on.

Implicit in all this is that these object use the UDP protocol. You may be aware that UDP has a reputation for losing packets. The NetServer/NetClient model protects against lost packets (or, in the model world, lost messages) through a feature of the NetClient object: Every NetClient has its own timeout threshold and retransmission count. If the NetClient doesn't hear from its NetServer by the time its timeout has expired, it retransmits its message. The object continues to retransmit at regular intervals until a reply shows up, or until the retransmit count is exhausted.

Given this scheme, the NetServer must be prepared to receive duplicate messages. Each message is tagged with a unique transaction ID; the NetServer can check IDs as they arrive through its CurrentTransactionID() function, and can compare the current ID with a list of the most recently-received IDs (which you have to maintain yourself). If it's already seen a particular ID, it should regard the current message as a duplicate.

I've left out some details here such as error checking for the sake of a simple discussion. However, the sample code on the FTP server does deal with errors, as well as some other features of the classes not mentioned here. You can download it from ftp://ftp.be.com/pub/contrib/code/netmessage.

It's a bit like those television ads where adults are embarrassed to admit they love corn flakes. Home computers users say they buy their computers to do work, when the truth is, a lot of them are booting up to play games.

For proof, just consider the recently-released Software Publishers Association (SPA) data: 1995 entertainment software sales revenues were up almost 43 percent in North America. And last year, the SPA reported that a third of the households that used computer games had more than 10 games.

Randy Thompson, a director at Dynamix,Inc., an Oregon-based entertainment software developer, isn't surprised. Dynamix (a division of Sierra On-Line) has been producing games for more than 10 years. Their titles include: Red Baron, The Incredible Machine, Aces Over Europe, EarthSiege, and Front Page Sports Football. The 130-person company develops for Windows, Macintosh, PlayStation, and Sega—and now they're considering adding the BeBox to the list.

“The computer industry has become stagnant,” Thompson says. “If you want to develop a mass-market product, DOS/Wintel and Macintosh are pretty much the choices. But neither of these giants can raise the technology bar. The Amiga injected some life back into the industry, but it was an ill-fated system.” Thompson sees potential for the BeBox to wake up a slumbering industry, and to do so with a brighter fate.

“The BeBox is an exciting new computer platform, and we want to get in on the ground floor,” he says. “Technologically, the BeBox is superior to all the systems we currently develop for. It's got a clean OS with an incredibly rich set of standard features: audio, video, and I/O ports.”

Their first BeBox project will be a real-time 3D game using motion-captured, polygon-based characters. They hope to release the game internally by the end of the year—at that point, they'll decide whether to release it publicly. After that, they're planning multi-player games that can be played over a local area network, or remotely over the Internet.

Since they're owned by one of the largest publishers in the world, Dynamix doesn't face the retail shelf-space challenges a small developer might. Thompson does, however, encourage the “shelf-space challenged” to consider the advantages of Be's software distribution model. Games customers are hungry for the latest software, and electronic distribution could make a real difference to a small developer's bottom line.

Based on the initial grass-roots interest in the BeBox, Thompson sees great potential for a “loyal, if not large, user base.” If their programmers are any indication, he'll be right. “Our programmers have been pushing harder than anyone to get a BeBox in-house. They can't wait to get their hands on one.”

For more information on Dynamix or their products, visit their Web site: http://www.sierra.com.

Last Friday we closed a $14 million financing round with major Silicon Valley venture firms and earlier supporters of our company. And so we open a new chapter of Be's life.

The investors:

• The round is led by David Marquardt of August Capital. David was an early (and then only) venture investor in Microsoft, and sits on their board. He invested in and sat on Sun Microsystems' board in the early days as well. August Capital is a new fund, started by David last August (hence the name).

• New Entreprise Associates (NEA) is represented by Mark Perry. NEA is one of the largest Silicon Valley venture firms with about $700 million under management.

• Alta Technologies, represented by Garrett Gruener, is based in San Francisco. This is a newly formed fund led by Jean Deleage, formerly of Burr Egan and Deleage. Jean and his team's reputation was such that he raised his $100 million fund in a single presentation to Calpers, the California state employees retirement fund.

• AVI Management Partners is represented by Barry Weinman. As some of you know, AVI is a local fund led by Peter Wolken.

• Christian Marchandise represents a group of French investors from a previous round.

• We also enjoyed renewed support from some of our earliest investors, such as Newtek Ventures, Innolion, Convergences and Star Ventures, as well as personal friends of mine.

• I'm also re-investing in this round—it's a great deal.

For more details see our press release on www.be.com.

As I wrote above, this is a new chapter. The previous ones have been challenging, character building, learning experiences—pick your bromide. Assembling a team and developing the technology, our real assets, have been the easiest part, at least when compared to fund raising. I had no experience on that subject when I started the company and it showed.

When we started in October 1990, right after I left Apple, the idea of building yet-another-platform wasn't popular in financial circles, to say the least. NeXT and Momenta were burned in the collective consciousness; Go/EO were not far from doing it again. So, the company started from my back pocket and from the checkbooks of people such as Seymour Cray, and friends from HP and Bull.

In our first round of financing, the venture arm of the largest French bank, Credit Lyonnais, stepped in as the lead investor. That turned out to be helpful in the short term, but it became difficult when this lead investor turned out to a be a large distressed bank, unable to support the company when AT&T gave up on the Hobbit, the microprocessor used for our first design (the PowerPC didn't exist when we started). This happened at the beginning of 1994. We had to scramble to implement a new PPC-based design, port our software to it and raise more money. AT&T helped a bit, and Christian Marchandise led a second round in 1995.

Then came the Agenda demo in October 1995; this was the turning point. Two of our new investors were in the room when our demo got a standing ovation. The press was generous to us, and developers started to support our platform.

One night at dinner after Agenda, John Fry remarked we had been very lucky. As I acquiesced he made two remarks to explain his point. One of which gave me a retrospective chill: The Web did not exist when we started. It's the great equalizer, tremendously helpful to a small company such as ours. It helps our developers market their software and it is an exciting new application area for Be. We were lucky to introduce just as the Web was showing its muscle and gaining respect.

More sobering was his remark that we had been lucky to present our product after Windows 95 shipped. Indeed, had we met our schedule, we would have demoed at Demo 95—right when Microsoft was showing its $200 million picture of the bride (Win95), if I can be forgiven this remark. Had we shown our product in February 1995, we would have gotten a commiserating pat on the back: “Windows 95 will do everything you claim to do, and more.” Instead, the market had met the mother-in-law in August when Windows 95 finally shipped. So, in October we got compared to the real product. A little luck helps.

Now we have the means to raise this promising child and allow the BeBox to reach its natural markets at the intersection of the Web, image processing, digital audio and video. To all the people who supported us, outside and inside, my heartfelt thanks. Let's move forward and develop this business.