What's a bridge?

EEA index

Bridges
What it does
Detection
Acorn bridge
SJ bridge

Intro
FileStore
MDFS
Others
Clocks
Interfaces
Misc h/w
Testing
Misc info

The purpose of a bridge...

The purpose of a bridge is to join two separate networks.

Pretty much every Econet protocol expects a network number in addition to the station number. Usually the network number can be omitted (in which case it is assumed to be zero). However if the network number is provided, a bridge will intercept and forward packets for networks it knows about.

As I've already said, the purpose of a bridge is to join seperate networks. It can do so in the following styles:

Network 1 -------- BRIDGE -------- Network 2

This is a simple two-network join. There are two reasons common for this type of network:

Speed increases
If you have a long network, you can increase the speed of communications by splitting the network into two - the halves of which can be clocked faster than one big network.
A caveat of this is that communications through the bridge will take longer than a slower clocked network, so this will only work if you have a server machine on each side of the bridge, and try to minimise cross-network communication, so the network can run at its fastest.
Speed matching
The most horrible thing you can do to a network of RISC OS machines is to install BBC micros on it. Instant speed nosedive. There is a way around this. You can have a fast-speed network for the fast-speed machines, and a slower speed network for those older machines. The bridge will act as a speed-matching device, and it doesn't matter how much is lost talking through the bridge as those 8 bit machines are suitably slow...

The second style is:

BACKBONE ------------------------------------ BACKBONE
                 |                  |
Network 1 --- BRIDGE              BRIDGE --- Network 2

This allows multiple networks (say, one net per classroom or block) to share resources. Typically, in a structure such as this, you would place the servers on the backbone. Therefore each station only needs to go through one bridge to get to a server, or two to communicate with a station on another net.

This topology is useful for RISC OS stations. It provides a backbone for centralised resources, though each network should have a local server. The reason for this is that RISC OS applications tend to be fairly large, so a local server will alleviate the problem of transferring large files through a bridge.

The third style is:

Network 1 -- BRIDGE -- Network 2 -- BRIDGE -- Network 3

This is the result of either an improperly planned network, or a peculiar arrangement not possible using a straight wire (such as 'T' or star arrangements). This may also be necessary for covering extraordinary lengths at something approaching a reasonable clock speed.
This type of network is not recommended unless absolutely no alternative exists, as a station on network three accessing a server on network one will need to pass data through two bridges.

Installing the bridge

If you are installing a bridge, its positioning in the network does not matter unless you are using an SJ bridge as a clock for the second network. In this case, the bridge should ideally be located in the middle of the second network (as is usual for a clock box). Its location in the first network does not matter.

Each network can be allocated a network number from 1 to 127. And each network can accept stations numbered from 1 to 254.
This means, in theory, that you can have 254×127 or 32,258 stations all talking to each other on one enormous network.

Network 0 is a special case. It means "The Current Network". If you are on network 2, and you want to access the server, you can ask your machine to talk to station 254. As you have not supplied a network number, zero will be assumed.
However, if you are on network 1 and wish to access that same server, talking to station 254 or even 0.254 will connect you to an entirely different machine. In this case, you must specify station 2.254.

Networks without a bridge will identify themselves as being network zero, as will RISC OS machines booted before the bridge is powered up. The bridge will accept and transfer data for networks it knows about, but it is good practice to switch on the bridge before the stations so there can be no confusion; and so the topology of the network is established prior to the stations getting in on the act.

Networks and computers

BBCs Bs and B+s

The NFS and DNFS ROMs default to file server 0.254 and printer server 0.235 when they are reset.
To get around this, you need to specify when logging on *I AM 2.254 SYST

Masters, ETs, and Compacts

The ANFS ROM stores configured network details in battery-protected memory. Thus, you can set up one of these machines to use a chosen server on a chosen network. Upon being reset, the ANFS broadcasts a message looking for bridges; and tries to behave in a sensible manner based upon the information that is returned. Ensure the bridge is active before the computer is reset for everything to work reliably.

RISC OS

RISC OS allows you to store network details on CMOS RAM. You can specify a unique service by number, or you can go one better and specify it by name.
Upon using a name, RISC OS will attempt to interrogate all the networks it can to try to locate the service you asked for. This makes it unnecessary for either you or the computer to have prior knowledge of the network topology.
And besides, a server called "Willow" is easier to remember than a pair of numbers...

How a bridge works - techie version

(from the SJ bridge user manual)

When the bridge is not transferring data, it looks at all of the scout packets being sent on both of the networks that it is bridging across, called networks adjacent to the bridge. If the scout packet contains a network number that is within reach through the bridge, then the bridge will perform a four-way handshake between the networks to transfer the data.

To do a four way handshake the bridge receives data from one adjacent network and puts it in its own RAM. While this is done, the bridge sends flags on the other adjacent line to prevent any network activity. Once the transfer of data has been completed, the bridge moves to flagging the first network instead, while it transfers the data from its internal RAM onto the second network.
Because the bridge has to wait until it has received all the data before re-transmitting it, the transfer rate halves when data is transferred across a bridge.

When a bridge is switched on, or RunMode selected, it only knows about the two networks to which it is directly connected. To learn what other networks are around, so it knows which messages it should be responsible for transferring, it has a general "natter" with other bridges already running. This process also means that other bridges know that a new bridge has appeared on the system.

The caveat of using a bridge

The physical network data protocol requires that, following the handshaking, the data transfer takes place; and the Econet protocol requires communications started to either be aborted or completed. Suspending a communication in course is not possible.

Therefore, we shall look to see what happens when station 1.252 wishes to communicate with server 2.254:

Step One - client calls to the server
   Network 1 - Client "Yo! Server! You there?"
   Network 2 - 

Step Two - bridge knows of the server, so it talks to the client
   Network 1 - Bridge "Hey, I'm forwarding this for you"
   Network 2 - Bridge "Yo! Server! You there?"

Step Three - the server responds
   Network 1 - Bridge "Lalalalalalalalala..."
   Network 2 - Server "Hey, wassup? I'm here, what'd you want?"

Step Four - the bridge passes back this info
   Network 2 - Bridge "Sending back the message, lalalalalala..."
   Network 1 - Bridge "Hey, wassup? I'm here, what'd you want?"

Step Five - a connection established, client asks for something
   Network 1 - Client "Can you make me a nice hot chocolate?"
   Network 2 - Bridge "Lalalalalalalalala..."

Step Six - the bridge shrugs, then passes this message on
   Network 1 - Bridge "Passing it on, lalalalala..."
   Network 2 - Bridge "Can you make me a nice hot chocolate?"

Step Seven - the server responds
   Network 1 - Bridge "Lalalalalalalalala..."
   Network 2 - Server "I'm a server dumbass, not a drinks machine!"

Step Eight - the bridge giggles and passes the message back
   Network 2 - Bridge "Passing this back, lalalalala..."
   Network 1 - Bridge "I'm a server dumbass, not a drinks machine!"

Step Nine - the client turns bright red, gives up
   Network 1 - Client "Oh, my bad. Goodbye then!" [terminated]
   Network 2 - Bridge "Lalalalalalalalalala..."

Step Ten - the bridge finishes the connection with the server
   Network 1 - [free]
   Network 2 - Bridge "Oh, my bad, Goodbye then!" [terminated]

If you read through this transcript carefully, you will see that it is basically like talking to somebody through somebody else, rather like a proxy of sorts. This is quite understandable as the bridge is the only device physically linking the two networks.
What might be confusing are all those "Lalalala" bits. When in a communication, when the bridge is talking on one network, it has to 'flag fill' the other network - because an active network communication can only be aborted or completed, you cannot stick it on hold to let other things happen.
This means the bridge basically spits out null data to say "the network is busy" to prevent other stations using the network. Shame, it'd have been nice if it was possible to drop in sequence numbers so communications were more TCP/IP like and could come in chunks, but never mind, these things were probably not that big a problem when Econet was designed...

Anyway, in essence, what happens on network 1 is that the bridge accepts data and passes it on to network 2. While it is passing the data on, the "Lalalala..." takes place on network 1. If the server on network 2 requires data, then this will happen in reverse (the bridge will talk to network 1 and "Lalalala..." network 2). And so on during the entire communication.

During any cross-network data transfer, both networks are tied up, and the data transfer will be slower yet due to the requirement of the bridge accepting data and then repeating it on the other network.

Therefore it makes sense to minimise the number of cross-network data transfers necessary. If possible, each network should have its own local server/printer which it uses most of the time. This will afford you the speed of a network running at normal speed (which can be quite zippy with RISC OS machines, one of them acting as a server) with the flexibility that joined networks afford.

An example in an educational setting (lest we not forget that in some places the 6502 is taught as a simple and good introduction to processor design and programming, and how better than the powerful BBC micro?). The BBC machines can be networked and provided with a server of some form in order to hold class examples and let the students save their code. In another room, students may use Ovation on A5000s to write their term papers. The cross-over is small, but the ability to take the code that was written and assembled and tested on the BBCs and then drop it into your document is very nice indeed. Drop in the actual code, without retyping it. No silly little syntax errors or typos, the real thing.

An example for the home user. I will actually cheat as I've already mentioned this. Most Acorn enthusiasts will have a range of machines. BBC micros are kinda slow. RISC OS machines are kinda not. The simplest solution to this problem is to run the 6502 technology on one network (with a clock rate in the order of 1µS:4µS) and the ARM technology on another network (use the bridge's clock and might be able to get away with something like .5µS:2.5µS). Now, obviously having two separate networks is rather idiotic and not very flexible. The solution? Dead easy - whack a bridge in there. They can both run at the speed most appropriate for their era, but also be able to communicate completely with each other.