|
Be Newsletter
Issue 7, January 24, 1996
Table of Contents
BE ENGINEERING INSIGHTS:
Everything You Wanted to Know About Be Networking, and More!
By Bradley Taylor
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.
Strategy
By Jean-Louis Gassée
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.
BE DEVELOPER PROFILE:
Adobe Systems Incorporated
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.
|
