7.2 The DataLogger Class
We'll start by exploring the main class of the application: DataLogger. DataLogger implements the network (TCP/IP) server and accepts and manages inbound connections from remote clients. A skeleton of the DataLogger class including its constructor is shown in Listing 7.1. The DataLogger class extends Thread and overrides the run method, making it the server's main loop. The primordial thread is allowed to die after successful initialization of the application.
During construction of DataLogger an instance of HumidityLogger is created specifying the sample count and delay time in seconds between samples. After the logger thread is started, the DataLogger thread is not concerned with the operation of the logger or even what kind of data it is collecting. It maintains a reference to the logger object that is used to satisfy log requests for inbound client connections. We'll cover the data collection classes in detail in the next section.
Listing 7.1 DataLogger
import java.io.*;
import java.net.*;
class DataLogger extends Thread {
...
static final int SERVER_PORT = 5588;
HumidityLogger logger;
DataLogger(int samples, int delay) throws LoggingException {
// Create and start the logging daemon
logger = new HumidityLogger(samples, delay);
logger.start();
}
...
}
DataLogger requires the number of data readings to be maintained and the delay in seconds between each reading to be specified on the command line. DataLogger's main method is shown in Listing 7.2.
Listing 7.2 DataLogger's main method
public static void main(String[] args) {
System.out.println("Starting DataLogger ...");
if (args.length != 2) {
System.out.println("Usage: java DataLogger samples delay");
System.exit(1);
}
int samples = Integer.parseInt(args[0]);
int delay = Integer.parseInt(args[1]);
try {
(new DataLogger(samples, delay)).start();
} catch (Exception e) {
System.out.println("Error creating data logger");
e.printStackTrace();
// In case any non-daemon threads have been started
// System.exit(1);
}
}
After extracting the samples and count values from the command line, the main method creates a new DataLogger object, which also creates a new thread of execution. After constructing the new instance of DataLogger, the start method is invoked to kick off the server.
The server spends eternity in the run method, processing network connections. DataLogger's run method along with the inner class LogWorker is shown in Listing 7.3. It starts by creating a ServerSocket object to listen for inbound connections from remote clients. The SERVER_PORT number used in creating the ServerSocket object is simply chosen as a large magic number. Anything that is comfortably above the range of "well-known port"2 numbers will do. As implemented here, DataLogger uses a port number of 5588. The application could easily be modified to use a port number specified on the command line.
Listing 7.3 DataLogger's run method
public void run() {
ServerSocket ss = null;
try {
ss = new ServerSocket(SERVER_PORT);
} catch (Exception e) {
e.printStackTrace();
// Abort if we can't create ServerSocket instance
return;
}
while (true) {
Socket s = null;
try {
// Wait for client connections over PPP or Ethernet
s = ss.accept();
} catch (IOException ioe) {
// Shut down the logging daemon
logger.stopLogging();
System.out.println("Fatal problem with server socket");
ioe.printStackTrace();
// Fall out of run method
break;
}
// Create a new thread to handle this connection
(new LogWorker(s)).start();
}
}
private class LogWorker extends Thread {
private Socket s;
private LogWorker(Socket s) {
this.s = s;
}
public void run() {
DataOutputStream dout = null;
try {
dout = new DataOutputStream(
new BufferedOutputStream(s.getOutputStream()));
logger.writeLog(dout);
dout.flush();
} catch (IOException ioe) {
System.out.println("I/O error writing log data");
ioe.printStackTrace();
} finally {
try {
s.close();
dout.close();
} catch (IOException e) {}
}
}
}
After the ServerSocket object is created, the run method enters an infinite loop that accepts and processes inbound client connections. After a new instance of Socket is returned from the ServerSocket object's accept method, a new thread (an instance of LogWorker) is created to manage the connection. The socket's getOutputStream method is invoked to obtain the lowest-level output stream (an instance of SocketOutputStream) for writing data to the underlying connection. This stream is used in constructing an instance of BufferedOutputStream, and the resulting buffered output stream is wrapped in a DataOutputStream.
The idea of using a buffered DataOutputStream for writing the log data is that the data-collecting daemon will write all of the samples it has collected to the output stream in an iterative fashion. If the output stream were not buffered, every write method invoked on the output stream would perform a write to the low-level SocketOutputStream. This forces a write to the native socket layer. Writing the log data in such a fashion could be termed "byte-banging." Byte-banging is very inefficient, since each of these writes is fairly expensive. With the BufferedOutputStream, writes to the underlying SocketOutputStream occur only when the BufferedOutputStreams internal buffer is full or the stream's flush method is invoked. The default internal buffer size used in TINI's implementation of all buffered streams is 512 bytes. This allows several log entries to be written to the DataOutputStream before the write method on the SocketOutputStream is invoked to write the contents of the buffer to the native socket layer.
The DataOutputStream object is passed to the writeLog method of the data collecting daemon. The writeLog method is responsible for writing all data points to the output stream. After the writeLog method returns, any data remaining in the output stream's internal buffer is flushed and both the stream and underlying socket are closed.
There are two catch blocks in the run method. The first protects the accept method. If an IOException is thrown from accept, the problem is assumed to be fatal. There isn't any good reason for accept to throw a runtime exception other than that the port selected is already owned by another thread or process and this problem won't be fixed with retries. In this case, the while loop is exited by the break statement, allowing the DataLogger thread to exit. As we'll see in the next few sections, all other threads created in the DataLogger process are daemon threads, so when the server thread exits, all of the other threads stop executing and the application terminates. The other catch block protects the writing of the log data to the remote client. In this case, an error could result from the client terminating the connection unexpectedly. While this certainly does prohibit the successful transfer of the log data, it shouldn't cause the application to exit. In this case, we just close down the socket and output stream and wait for a new connection.
In this section we developed the top-level framework necessary to accept network connections and dispatch output requests to the data collector. Next, we'll focus on the details of collecting and managing the data samples.