REF TEK Protocol Daemon (RTPD)
The RTPD error correction protocol has been developed to provide the communication and real-time data acquisition from network stations. RTPD provides an ordered, error-free, packet-oriented transport on top of User Datagram Protocol (UDP). It is self contained at the client and provides a simple and robust server discovery mechanism. It is a streaming transport, that is, it may transmit packets without waiting for acknowledgement from the peer thus making efficient use of available bandwidth. RTPD provides a robust, yet relatively small and simple, transport to meet customer’s needs.
RTPD is typically used in server-client fashion although this is by no means required. Typically the server application is running on an IP host somewhere on the network. RTP clients will attach themselves to the server to send and receive data. RTPD and its associated software run on Windows, Linux, and MacOS.
RTPD provides the following important features:
- Entirely platform independent. All data values are stored in network byte order. RTPD can be implemented on any hardware platform or OS that provides an IP protocol stack.
- Encapsulate the application data completely and not have any dependency on the contents of any particular application data packet. That protocol is completely unaware of what it is transporting to the peer. The only requirement placed on the application is that the data packet be 1024 bytes or less in size.
- Self-contained and self-configuring at the client. That is, the protocol stack discovers and assigns all necessary parameters to operate from the network. There is no configuration information stored by embedded implementations, nor any higher level application configures or controls it. The higher level application simply submits data packets to be sent as they are ready and is always willing to receive data. However, the higher level application response to flow control from RTPD to avoid loss of data.
- Both the server and client initiate the connection on-demand. This means that when the application has data to send, the connection is established if needed simply by submitting the data packet to be sent. If the connection is down, both respond to link establishment by the peer at all times. There is no need to an administratively opened or closed state, it is always administratively open.
- Recover from loss of connection without data loss. This means that if a RTP client is sending data to the RTPD server and the connection is lost, it will reestablish the link and resume sending data. No data may be lost or passed on out of order by the server.
- Deal with long, thin, pipes effectively. RTPD is capable of high utilization (>90%) of slow (9.6k), high latency (>1 second), connections. RTPD uses deep queues (16 slots) and adaptive retransmission time-out to achieve this goal.
- Small and relatively simple implementation. RTPD is suitable for embedding in dedicated communications hardware for REF TEK recording systems.
- Function at the application layer using the standard UDP Sockets API on the server system. All network traffic is UDP datagram to/from the REF TEK port number, port 2543. This port is the well-known REF TEK port and is registered with the Internet Assigned Numbers Authority (IANA) for use with both UDP and TCP.
Once the 130 Recorder is powered up, the RTP client reside at the 130 Recorder generates the discovery packet, which includes the 130 Recorder ID number, Host RTPD IP address, port number and send it to the interface programmed by the operator for real-time data transmission. If the 130 Recorder is connected to the IP network, the discovery packets are sent to the IP network. The host RTPD resided at the acquisition PC at the central station is “listening” the port 2543, and as soon as it receives the discovery packet from the 130 Recorder with the unique ID number, performs the hand shaking with the RTP client and establishes the connection with the 130 Recorder.
If the 130 Recorder is programmed for a continuous data recording to a designated communication interface (Ethernet or Serial port), host RTPD begins receiving the data from the remote 130 Recorder. The error-correction is performed by the extensive error checking and positive acknowledgment from the host RTPD. In the event of the communication link failure, the data is acquired on the RAM while RTP client periodically sends the discovery packets. After the communication link comes back up, the host RTPD will again receive the discovery packet from the remote 130 Recorder, re-establish the communication and resume the data acquisition automatically.
The host RTPD receives data from 130 recorders (PASSCAL data packets) and stores them in a REF TEK data archive. RTPD has no built in limit to the number of stations or channels from which it can acquire data.
The real-time data can be exchanged between different data centers or users by running different instances of RTPD in the “daisy-chain” fashion. Moreover, the real-time data exchange can be established not only between remote RTPD – to- Host RTPD connections, but between remote -to- remote RTPD (clients RTPD) connection as well.
Unlimited number of clients can be attached to the Host RTPD to perform different functions, including REF TEK’s client programs such as RTPMonitor, RTCC, RT_Display, and other clients such as SeedLink (in and out), RT2EW, RT2SNDP, RT2SEGY, etc.
Please contact REF TEK for more information regarding RTPD specifications, features and architecture.