If you are using the network card, you need to use the hub161 program to provide a simulated network for the card to plug into.
When you run hub161, you can optionally give it, on its command line, the name of a Unix-domain socket to listen to. The default is .sockets/hub. This pathname may then be specified in the sys161.conf file(s) of the system(s) that wish to connect to that hub.
Each socket can only have one hub running on it at a time; however, you can have as many hubs as you like at once by giving them different socket names.
If you give the cards plugged into the same hub duplicate hardware addresses, bizarre things will happen.
No facility is provided for gatewaying hub161 packets onto the real network via the host system. Such a facility could be written, albeit with some difficulty, but will be fairly useless unless the operating system running within System/161 contains its own complete TCP/IP implementation.
The simulated network is a very simple link layer. All packets are sent to the hub process, which rebroadcasts them to all network cards. There is very little attempt at realism in general.
There is no effort made to synchronize the time among multiple instances of System/161 connected to the same hub; thus, packets may appear to travel in time. Furthermore, because of the way System/161 handles time, any attempt to synchronize the time in software is likely doomed to failure.
Because hub161 communicates over Unix-domain sockets, it and all the instances of sys161 or trace161 that wish to connect to it must be run on the same host.
It should not be necessary to restart hub161 if any of the sys161 processes attached to it die, or vice-versa either, although a delay of up to a few seconds on a busy host system may occur.
If you are not using the network, it is recommended that you comment the network devices out of sys161.conf to reduce overhead on the host system.