Chapter 7. Forwarding data over a network

Previous chapters have described how to use Scream! to access data directly from a digitiser or via another copy of Scream! These data can come from serial ports, modem lines or anywhere on a local or wide-area network. This functionality is controlled from the My Client tab of the Network Control window and from the Com Ports tab of the Setup dialogue and is described in Chapter 4.

Once data sources have been configured, Scream! can then act as a server to forward data to other computers running Scream!, any equipment running Platinum, such as Güralp NAMs, archival programs and/or processing software such as Antelope and Earthworm. Data are transmitted in GCF format using the Scream transport protocol. This functionality is controlled from the My Server tab of the Network Control window:

To access this window from Scream's Main Window, select Windows→Network Control from the menu or use the keyboard shortcut +.

You can choose whether or not to re-transmit data received over local serial links by ticking or clearing the Transmit data from local Com Ports check-box. See section 4.1 for information about acquiring data from local serial ports.

You can choose whether or not to re-transmit data received over the network by ticking or clearing the Transmit data from Network check-box. See section 4.3 for information about acquiring data from network sources.

Caution: Because Scream! can simultaneously receive data over the network and retransmit it in broadcast packets, it is possible to create loops where a single packet is received and re-transmitted multiple times. Platinum systems can also re-transmit data received over the network so always consider this possibility when designing networks.

If you are forwarding data across a high-cost or low-bandwidth link, you can choose to transmit only packets with low sample rates and not re-transmit packets with higher sample rates. To do this, set the sps transmitted block limit value to your chosen threshold. Setting it to zero causes Scream to transmit only status streams.

Some digitisers allow terminal sessions and configuration/control actions to be performed across a network link. Scream's server will, by default, block access to such functions from its clients. If you wish to allow such actions, tick the Allow remote control access check-box. For this to work, all upstream devices must also allow remote control.

Scream! can serve data in two ways. In the first, clients may request data from the Scream! server. This method is known as “client pull”. Alternatively, Scream! can keep a list of clients which need to be provided with data. This method is known as “server push”.

Note: In the illustrations in the following sections, we will show the Scream system that is transmitting data as a desktop PC and the system that is receiving data as a laptop. This is just a convenient shorthand: any system that can run Scream can act as a server.

7.1 Client pull

In a client pull configuration, Scream listens for incoming UDP requests from clients and serves data to them automatically.

To start a server and listen for pull requests from clients, tick the Transmit data from local Com Ports check-box and/or the Transmit data from Network check-box on the My Server pane. Scream will start listening on the UDP port specified in the Network Control window as the Port used for all network communications.

Caution: If your server is behind a firewall, you will need to unblock the UDP port at the server side to receive these requests.

7.2 Server push

In a server-push configuration, the server must be configured with a list of clients. GCF data will be pushed to the client using the scream transport protocol over UDP.

Note: If you are using Scream as a client, you can simply tick the Receive Data check-box on the My Client tab to begin receiving data. If your client is behind a firewall, you will need to unblock the UDP port at the client side.

To configure Scream to push data to a particular client:

Switch to the My Server pane of the Network Control window;

Tick one or both of the Transmit data from local Com Ports check-box and the Transmit data from Network check-box, as required;

Right-click anywhere in the Clients list box and select Add… from the context menu. Enter the IP address (or DNS name) and port number on which the server is waiting for requests, separated by a colon (':') (e.g.192.168.42.98:1567)

You can add any number of clients, including broadcast addresses and multicast groups. If you want to broadcast or multicast UDP packets, you should obtain suitable addresses from your network administrator.

To broadcast to all connected computers, use the IP address 255.255.255.255.

To restrict broadcasts to a particular subnet, use the broadcast address for that subnet: for example 192.168.60.255:1567 will broadcast data on port 1567 to all clients on a 192.168.60.0/24 subnet – i.e. those with IP addresses beginning 192.168.60.

To send data to all instances of Scream! in a multicast group, use a multicast IP address. The address range from 239.255.0.0 to 239.255.255.255 is available for local networks, and that from 239.192.0.0 to 239.195.255.255 for organisation-level networks. Most other multicast addresses on the Internet must be specially registered.

The server will automatically start transmitting.

To send data to another Scream! running on the same computer, use the IP address 127.0.0.1, but ensure that any other instances of Scream are using a different port number in order to avoid a loop.

To send data to more than one Scream! running on the same computer, use the local broadcast address 127.0.0.255, or set up a multicast group. You must use a different port (e.g. 127.0.0.255:1568) in this case in order to avoid creating a network loop.

The list of clients to which Scream! is currently sending data is shown in the Clients table at the top of the My Server pane. Block-by-block details of the data being transmitted are shown in the Block Tx pane. Other server operations are reported in the Control pane to its right.

Both “server push” and “client pull” clients are listed in this pane. You can see which clients are using which method by looking in the Time-out column. When a pull client requests data, its time-out is reset and then starts counting down toward zero (as is the case for 10.10.0.33 in the screen-shot above). If a pull client's time-out value reaches zero, Scream! assumes it has stopped listening and removes it from the list. On the other hand, push clients do not have a time-out, because Scream! will always try and transmit to them. Thus, clients using pull have a time-out figure listed in this column, whilst push clients are shown with the entry None, as is the case for 10.10.0.37 in the screen-shot above.

To alter the IP address or destination port of a client, right-click on it and select Edit…. Enter the new IP address and port as for Add…, and click

To remove a client from the list, right-click on it and select Delete.

7.3 Server Buffer

The Scream server must store a history of the data transmitted in case the client does not receive all data and requests "back-filling". Scream! stores this history on disk so that it can be very large, if desired. The Server Buffer tab of the Network Control window allows the configuration of the size and location of this disk-based buffering.

If disk-based buffering is not enabled, Scream! will use a small memory-based buffer.

It is recommended that the user ensures there is sufficient disk space available on the drive selected to hold the buffer. The buffer size can be specified in either time (Days, Weeks or Years), or in terms of disk usage (MiB, GiB or TiB).

7.4 Gap recovery

In addition to the normal UDP data protocol, Scream! has facilities for attempting to recover missing data. When Scream! receives a block of data that indicates a gap (because the sequence number is not contiguous), it opens a new TCP connection to the server (from the same port). Once this connection is made, Scream! requests the missing data and, if they are available, the server transmits them over the same TCP connection. The UDP data stream continues unaffected.

If you are using a firewall on either side of the connection and want Scream! to be able to recover missing data in this way, you will need to unblock the relevant port for both UDP and TCP traffic.