There's a lot of hype about the world-wide web and all the wonderful ways it will make our lives better. Many of the promises will come true, and many will not, but one thing is certain: TCP/IP is now the standard for networking! Virtually every computer in the world has a TCP/IP stack written for it, and all the major players who thought they could dominate the world with their proprietary protocols are now migrating to TCP/IP. As a new computer, the BeBox will not have to suffer through any such migration headaches. We do TCP/IP and only TCP/IP. This keeps things simple for us, and simple for you. Now that you're completely sold on TCP/IP, we can move on to discuss what we implement in terms of TCP/IP, how we implement it, and what some of our future plans are.

TCP/IP has always been the network protocol of choice for UNIX systems, and as such, there are several public-domain TCP/IP UNIX programs available. Almost all are in source code form (I salivate just thinking about it). So we have made our API to networking very similar to the UNIX standard of Berkeley sockets, so that we and others can benefit from these programs right away. Most of these programs are command-line oriented, and therefore completely appropriate for the "geeks" who will be our initial customers. We have already ported ftp, ftpd, and telnet, without many problems, and we may port a few more. Longer term, we obviously want TCP/IP applications that capitalize on the Be interface, to satisfy the mere mortals who think a C shell is something you find on the beach (rightly so I might add). Many of our third parties are indeed developing GUI-based network applications, and I hope to see a commercial-quality web browser and e-mail application soon.

TCP/IP is typically implemented in the kernel, and hence it robs applications of precious memory whether you're using the network or not. Be networking, on the other hand, is implemented almost entirely as a server. If you aren't using it, it won't get in your way, since the kernel will swap it out. If you are using it, there's a slight performance penalty, due to the extra level of indirection. However, since the PowerPC is plenty fast at copying data to and from the network server, the net effect is negligible, at least when compared to standard 10-megabit Ethernet speeds.

The major disadvantage with this architecture is that it's not the way UNIX does things, and so there are a few things to be aware of when porting UNIX code. To UNIX applications, TCP/IP is just another file descriptor that you can call read(), write(), and close() on. On the BeBox, TCP/IP sockets live in a separate name space from file descriptors, and hence you cannot use these calls. However, it's simply a matter of using recv(), send(), and closesocket() instead.

Another problem arises from the fact that sockets are not inherited across POSIX fork() calls, as they are in UNIX. WINSOCK (Windows sockets) has similar problems, and if any of you've ported code to WINSOCK, you've already dealt with these issues.

The network server implements the following alphabet soup of protocols: PPP, IP, TCP, UDP, ARP, and ICMP. Some of you may be familiar with all of these already, but I'll guess that many are not, so I 'll briefly describe each of them. PPP stands for Point-to-Point Protocol and is the Internet standard for doing networking over a serial connection. If you use a modem or ISDN to access the Internet, most likely you're using PPP. SLIP, which we don't implement, is an older, nonstandard protocol that performs a similar function. PPP knows nothing about higher-level protocols, and so it's able to deliver any protocol, such as IP, IPX, or AppleTalk. We only use it for IP.

IP stands for Internet Protocol. It's responsible for delivering packets from one computer to another, regardless of where they are in the world. IP packets may be routed through several computers before reaching their final destination. Applications almost never use IP directly, but instead use either TCP or UDP, which is layered on top of it.

TCP stands for Transmission Control Protocol. It can deliver data between any two applications in the world. TCP is a reliable protocol, meaning that it will either deliver the data you give it to the remote application in sequence without any duplication, or it will notify you that the connection is broken and it can no longer do its job. TCP cannot be broadcast to a local area network. Examples of common TCP applications are HTTP (the world-wide web protocol), telnet and ftp.

UDP stands for User Datagram Protocol, although most people mistakenly believe it stands for Unreliable Datagram Protocol. UDP, like TCP, can deliver data between any two applications in the world. UDP can also broadcast data to a local network, so that several applications can get the data at once. UDP is a lightweight protocol, meaning that it's almost always faster than TCP. The big drawback of UDP is that it makes no attempts to deliver data reliably, and sometimes its packets get lost (hence the misnomer). Still, it's possible to build reliable applications around UDP, but the application must do its own acknowledgments to ensure the packets do indeed arrive at their destination. Examples of common UDP applications are the Domain Name System (DNS) and the Network File System (NFS).

The remaining protocols are ARP and ICMP, neither of which is very useful to applications. When IP is layered on top of Ethernet, ARP (Address Resolution Protocol) is used to automatically find the physical Ethernet destination associated with a given logical IP destination. ICMP (Internet Control Message Protocol) is used for various IP diagnostic functions. It's most famous for its use in the ping program for rudimentary network diagnostics.

The network server does not implement the Ethernet driver or the serial driver. Instead, it opens these drivers in the kernel by name. Hence, the network server can be targeted to run over any Ethernet card or serial device, as long as there is a driver available for it. Our Ethernet driver works with any NE2000 compatible ISA card and the 3COM 3C503 card. Many decent NE2000 ISA cards are available today at low prices, handling BNC, twisted-pair, or AUI media. The drivers are dynamically loaded into the Be kernel, and third-parties (or Be) should be able to deliver drivers for other network media without changing any source in our kernel.

OK, so that's what we implement. We have the basics of TCP/IP, enough to implement many significant applications using TCP or UDP. However, we still have much to do. There's a long list I'll go into, but keep in mind that none of these are commitments, merely wishes, so please don't go and bet your company on any of these! One area of future work is performance. While our performance is pretty good, comparable to a Macintosh and some UNIX systems, we would still like to approach speeds seen in the FreeBSD and Linux UNIX systems. PPP is still in its infancy, and there's much work to do there to make it easy to use and as robust as possible.

Also, we want our network configuration application to make simple things simple, while allowing you to do more complex things, such as configuring Ethernet cards or multiple IP addresses. Further into the future, we would like to support NFS (Network File System) for file sharing, DHCP (Dynamic Host Configuration Protocol) so that you don't have to configure IP addresses, Multilink PPP for utilizing both "B" channels of an ISDN card (perhaps a third-party opportunity), and Internet Multicast to support applications like MBONE. We also would like to develop some Be-specific protocols, so that Be applications can be easily extended to the network. A simple way to do this is to extend the Be Messenger class, so that it could be instantiated targeting either a local or a remote application. Applications on your desktop could easily take advantage of services not otherwise available locally, such as faster CPU speeds, distributed processing, heavyweight database services, or exotic I/O devices.

As you can see, there's a lot to do. We're not a big company with a large army of programmers devoted to TCP/IP. Nope, we're just a little company, with a single programmer (me) at the helm of TCP/IP. The good news is that your feedback is certain to get to the right person, loud and clear. We, of course, welcome any feedback you may have.

Several Be developers and posters on comp.sys.be have asked me to discuss our strategy. I'd like to begin by returning to the dictionary. It defines strategy as "The science and art of military command exercised to meet the enemy in combat under advantageous conditions."

The word strategy is often used to aggrandize and embellish statements of little importance. Why call a move "tactical" when I can charge the client, or the boss, strategic rates for my foils or my press releases? Abused or not, there's a lot to like in the definition of strategy, of creating "advantageous conditions" by which we fight for a place under the sun. This is what I will discuss today. Mark Gonzales, our marketing sage, will review market-by-market specifics in future columns.

Let's start with what we call our architectural advantage. We say we offer an alternative to legacy systems by offering a baggage-free architecture. The pluses and minuses are well understood. On the minus side, we forfeit a legacy of thousands of applications. They run on older platforms and we start with an installed base of zero. On the plus side, a fresh start frees us from the baggage of a decade or more of incremental fixes and extensions, from many accumulated layers of software silt. As a result, we offer features hard or impossible to graft onto legacy platforms: Multiprocessing, multithreading, an integrated database engine, preemptive multitasking, media kits, richer and geekier I/O, a simpler cleaner programming model... The enumeration is a little dry on paper but a demonstration makes it come to life—an experience we enjoyed on a large scale at MacWorld. All right, but what's strategic here? If, in a short period of time, our noble and worthy elders could replicate the advantages we offer, we'd be in a position known as picking up dimes one foot ahead of the steamroller. On the contrary, most observers agree our key features are hard, if not impossible to graft onto a legacy platform in a threateningly short amount of time. After all, our best-managed elder still needed five years to polish its latest major revision, and the one to which we are more sentimentally attached will need six, some say seven years for a similar step. So, we have a lasting technical lead, which in turn creates a set of "advantageous conditions " for us to go to the marketplace. This is the first element of our strategy. Of course, we need to be aware of two dangers. First, once we start to appear on their radar screens, our colleagues will use the age-old rhetoric: This is nothing, and if you still need it, we've been working on it for six years and we'll have it in six months. These are photodegradable statements. The second, bigger danger is complacency, standing still. I think we're all aware enough of our surroundings to recognize the danger—but the proof is ours to produce.

Let's turn to the second part of our strategy. The fights we're willing to pick, and the ones we avoid. Clearly, in the office automation market, the game is over. Microsoft won. IBM might disagree, they have Notes, but, with all due respect to Lou Gerstner, they don't have Bill Gates, his management team, and his control over the Windows platform. In the office market, Microsoft Office has become the real operating system. If you tithe at the Office, Bill will even let you use a Macintosh, a platform he loves to use as a way to dislodge his less bicultural competition, such as Notes or Novell. Whatever we think of the state of classical office productivity applications, this is not a good terrain for us. Fortunately, there are many places where compatibility with reigning spreadsheets, word processors, and presentation packages doesn't matter. The BeBox, with its fast hardware and multithreading services, makes a nice web server and it works well in image processing, digital audio, and digital video applications. None of these areas are yet dominated by a big predator crowding the ecological niche—especially if we enter these segments at the personal level, as opposed to the departmental and professional segments. This is how the Macintosh entered the electronic publishing market. The pros initially dismissed the Macintosh as a toy, but with the help of Adobe, Aldus, and Canon, the Mac created a the personal publishing industry. For attentive readers of earlier issues, I appear to contradict myself. I wrote: "Based on my reading of the history of our industry, I believe the people involved in building the platform, because of their close involvement, develop myopia and can't see the tractor apps in the distance." And I referred to our need for "guide geeks" to show us the way. Since then, we've reviewed the questionnaires e-mailed by developers who expressed interest in writing applications on the BeBox. We've now received over 900 such questionnaires, which is not a claim we enjoy over 900 active developers, yet. We expect to pass the milestone of 250 BeBoxes actually and actively in developers hands some time in February. Returning to these questionnaires, they paint the picture of an enthusiastic, creative, and experienced community. The four domains outlined above are the areas where we see the most stated interest, but not all, by far. This gives us plenty of room to gather strength, to create alliances with like-minded people and companies, and to innovate and flourish in emerging applications, on the value-creating side of the web and digital media. By "value-creating side," I mean those who create, edit, produce, and broadcast these new media, as opposed to the consuming side—a totally different game.

By carefully picking the technical and market terrains, we intend to create the conditions under which this product and this company, still in their infancy, can grow to achieve their full potential.

To be sure, many BeBox developers are small, one- or two-person software houses—but not all of them.

Adobe Systems Incorporated, the desktop publishing behemoth in Mountain View, California, has assigned three engineers to look at porting its industry-leading Photoshop application to the BeBox.

Now, one might think that a company the size of Adobe might not consider a market as small as Be's current installed base. But according to Sean Parent, Adobe's Macintosh technical leader, there are some compelling reasons to do so. The BeBox offers Adobe the opportunity to have a low-cost, high-performance platform for Photoshop. The company understands the potential of multiprocessing architectures, and there is no other platform with the price/performance ratio offered by the BeBox.

Parent notes that the Macintosh by itself doesn't support multiprocessing. People who want these capabilities on the Mac have to buy a Daystar Genesis add-on card for as much as $1,400. The other high-performance, multiprocessing platforms are either Windows NT or UNIX systems, both of which are priced significantly higher than the BeBox.

Additionally, Adobe currently supports all of the major platforms, so it makes sense for the company to support a significant emerging platform for desktop publishing and other graphics-intensive applications.

On the technical side, Parent said Adobe has "sucked all of the performance out of the Mac file system that it is going to offer." Be is offering a high-performance platform with an improved file system, which can better exploit planned enhancements to Photoshop.

It won't be difficult to port Photoshop to the BeBox. The PowerPC version of Photoshop is already written using Metrowerks CodeWarrior, the same development environment that's used to write applications for the BeBox. And the program is written to be easily ported from one platform to another.

So far, Adobe hasn't decided whether it will bring Photoshop for the BeBox to market. But the company is interested enough to devote some of its engineering resources to the platform to see what's possible. Once Parent and his team come up with a workable Photoshop version for the BeBox, Adobe will make a final decision about which way to go.