The following text is copyright 1998 by Network World, permission is hearby given for reproduction, as long as attribution is given and this notice is included.

Architectural differences

By Scott Bradner

The architecture of the Internet is different than the architecture of some other networks such as the telephone network, in the same way that the architecture of Internet-based applications can be quite different from the architecture of the same applications run over telephony networks. Two examples come to mind; PBXs and EDI.

A traditional PBX consists of a small number of interconnected core systems, often only one, to which local telephones are connected. Placing a call on this type of system means making a connection from one phone to the PBX, sending a command (a series of digits to select the target of the call) to the PBX which then connects to the target phone.

In a traditional EDI environment, one customer connects to a server at an EDI company, normally over a dial-up or dedicated line and deposits an EDI formatted message on the server addressed to another customer of the same EDI company. The message transfer is completed when the other company calls in, or initiates a contact over a dedicated line

Both of these examples depend on a user connecting to a core server which then controls the transaction with a 2nd user. This is considerably different than the model used by most Internet-based applications which tend to be peer-to-peer.

When sending email using the traditional Internet model an email client on my local computer connects to an email server on the target machine to transfer the email message. This model has been augmented somewhat by the addition of local POP servers at many locations but even with these servers there are not servers in the network which act as exchange points - the communication is end-to-end rather than end-to-middle then middle-to-end.

Both PBX and EDI services are now moving to the Internet and there are two very different strategies that vendors are proposing to use to implement the services. One strategy is to just replace the dialup and dedicated lines with Internet connections. In this model all of the communication still goes through a core server. In the case of a PBX this means that Internet-enabled phones would connect to a PBX server in the local network and request a connection through the server to a target Internet-enabled phone.

But there is no requirement to do this in the Internet. An Internet-enabled phone could connect directly to another Internet-enabled phone over the network. The only infrastructure needed besides the network itself are some simple name resolution services. In some cases, like EDI, the central server can perform auditing functions but even here, if the correspondents trusted each other, no core server would be needed.

I expect to see both central-server-based and peer-to-peer architectures offered in Internet-based PBXs and EDI systems. But I expect that the peer-to-peer model will, like the distributed architecture of the Internet itself, be the successful long-term model. Those who think they are going to make money running or building core servers for these functions will have a hard time because they do not understand the underlying architecture of the 'Net.

disclaimer: As an aggressively decentralized institution Harvard rarely encounters the problems of centralized services but in any case the above observation is my own.