06_file_based_inter_process_communication__ipc__.md

Chapter 6: File-based Inter-process Communication (IPC)

In the previous chapters, we've explored how shellnetbuilder's friendly Graphical User Interface (GUI) Frames allow you to interact with the application, and how powerful Network Service Configuration Modules and Service Lifecycle Management Scripts perform the actual work on your system. These scripts are securely handled by the Secure Script Execution Layer.

But there's a missing piece: how do these different parts, especially the Java GUI application and the backend shell scripts, actually talk to each other? Imagine one person speaking English and another speaking Spanish; they need a way to share information.

In shellnetbuilder, this "conversation" happens through File-based Inter-process Communication (IPC). It's like leaving notes for each other on a designated "message board" (specific files), which both sides can read and write.

What Problem Does It Solve?

The core problem File-based IPC solves is enabling communication between different types of programs (Java and Bash scripts) that run independently.

Think of it this way:

• The Java GUI application is running and showing you buttons and text boxes.
• When you click "Save," it needs to tell a separate shell script, "Hey, here's the information the user typed in, go configure the network!"
• After the shell script finishes its complex job (like setting up a DHCP server), it needs to tell the Java GUI, "Okay, I'm done! Here's what happened, so you can show it to the user."

These two programs (Java GUI and shell scripts) don't naturally "talk" directly to each other in a simple way. File-based IPC provides a straightforward and reliable method for them to exchange information.

Let's use a common example: Use Case: Configuring a DHCP server and getting feedback

1. You open the DHCP configuration window (GUI Frame) in shellnetbuilder.
2. You type in the IP addresses, subnet, and other details for your DHCP server.
3. When you click the "Save" button, the Java GUI writes all these details into a special .log file.
4. Then, a shell script (like dhcp.sh) is launched. This script implicitly knows where to find its configuration (either by reading the .log file or receiving it as arguments, but the log file acts as a record of inputs).
5. The dhcp.sh script does its work (configuring DHCP).
6. As it finishes or encounters issues, the script writes status messages (e.g., "DHCP configured successfully!" or "Error: Interface not found") into another special file, a .msg file.
7. Finally, the Java GUI reads the contents of this .msg file and displays them to you in a status area, so you know exactly what happened.

This ensures that the Java GUI and the shell scripts are always "on the same page" about what needs to be done and what the outcome was.

The Message Board: How it Works

The principle is simple: designate specific files in known locations as "message boards."

Communication Direction	File Type	Purpose	Example Locations
GUI to Script	.log files	The Java GUI writes configuration parameters, user inputs, or other data that the backend scripts might need, or simply logs what was sent for auditing.	/etc/Network_Builder_V0.1/logs/DHCP/dhcpk.log
Script to GUI	.msg files	Shell scripts write status updates, error messages, successful operation confirmations, or detailed results after they finish their tasks. The GUI then reads these messages to inform the user.	/etc/Network_Builder_V0.1/logs/DHCP/dhcpk.msg
Script to GUI	.status files	Similar to .msg files, but often specifically used for reporting the running status (e.g., "Service: Running", "Service: Stopped") of a network service, especially by Service Lifecycle Management Scripts.	/etc/Network_Builder_V0.1/logs/DHCP/dhcpk.status

These files are typically stored in organized directories, like /etc/Network_Builder_V0.1/logs/ or /etc/Tools/, ensuring each service has its own dedicated log and message files.

Step-by-Step Communication Flow

Let's trace the DHCP configuration and status feedback as an example:

sequenceDiagram
    participant User as User
    participant DHCPGUI as DHCP GUI (Java)
    participant ConfigLog as Config Log File (.log)
    participant DHCPScript as DHCP Script (dhcp.sh)
    participant StatusMsg as Status/Message File (.msg)

    User->>DHCPGUI: Enters DHCP details & clicks "Save"
    DHCPGUI->>ConfigLog: Writes input parameters to `dhcpk.log`
    DHCPGUI->>DHCPScript: Launches `dhcp.sh` (with arguments)
    Note over DHCPScript: Script processes configuration
    DHCPScript->>StatusMsg: Writes operation results to `dhcpk.msg`
    DHCPGUI->>StatusMsg: Reads `dhcpk.msg`
    StatusMsg-->>DHCPGUI: Returns status messages
    DHCPGUI->>User: Displays status to user

Loading

Explanation of the Flow:

1. User Input: You interact with the DHCP GUI, entering all necessary configuration details.
2. GUI Logs Input: When you click "Save," the DHCP GUI immediately writes all the input data to a file like dhcpk.log. This acts as a record of what was provided.
3. Script Launch: The DHCP GUI then launches the DHCP Script (dhcp.sh), often passing the configuration details as direct arguments (as discussed in Chapter 4).
4. Script Performs Task: The DHCP Script executes the necessary system commands to configure the DHCP server.
5. Script Reports Status: As it completes its work, the DHCP Script writes its output (e.g., success message, errors, configuration details) to a specific message file, dhcpk.msg.
6. GUI Reads Status: The DHCP GUI then opens and reads dhcpk.msg.
7. GUI Displays Feedback: Finally, the DHCP GUI displays the content of dhcpk.msg (or dhcpk.status) in its status window, informing you about the outcome of the configuration.

Code Spotlight: How Java and Scripts Use Files

Let's look at actual code snippets from shellnetbuilder that demonstrate this file-based communication.

1. GUI Writing Configuration to a .log File (GUI to Script)

Here's how a Java GUI frame (like nfsserver.java) saves the user's input into a log file before executing the backend script:

// File: Java Source Code/nfsserver.java (simplified)
// ... (inside jButton1's actionPerformed method) ...
            public void actionPerformed(java.awt.event.ActionEvent evt)
	    {
                // ... (getting user input like c_ip, nmask, accs, shr_dir) ...
		try{
                    // If fields are filled, save data to a log file
                    BufferedWriter fileOut = new BufferedWriter(
                        new FileWriter("/etc/Network_Builder_V0.1/logs/NFS/nfsk.log")); // <--- WRITING TO LOG
                    fileOut.write(jTextField1.getText()); // Client IP
                    fileOut.newLine();
                    fileOut.write(jTextField2.getText()); // Netmask
                    fileOut.newLine();
                    fileOut.write(jComboBox1.getSelectedItem().toString()); // Access type
                    fileOut.newLine();
                    fileOut.write(jTextField3.getText()); // Shared directory
                    fileOut.newLine();
                    fileOut.close(); // Close the file after writing

                    // ... (rest of the logic, including launching nfs-server.sh) ...
		} catch(Exception e) { /* ... */ }
            }
// ...

What this code does: When you click the "Save" button in the NFS Server Setup GUI, this Java code takes the values you typed into the input fields (jTextField1, jTextField2, jComboBox1, jTextField3) and writes each of them, on a new line, into the file /etc/Network_Builder_V0.1/logs/NFS/nfsk.log. This creates a record of the exact configuration parameters that were provided by the user.

2. Script Writing Status to a .msg or .status File (Script to GUI)

Now, let's see how a shell script (like nfs-server.sh or dhcps.sh) writes its output to a message or status file for the GUI to read.

Here's a snippet from the nfs-server.sh script, logging its actions:

#!/bin/bash
# File: configuration codes/nfs-server.sh (simplified)

chk=`whoami`
if [[ $chk == "root" ]]
then
	# <--- WRITING TO MESSAGE FILE
	echo "User is root.">/etc/Network_Builder_V0.1/logs/NFS/nfsk.msg
else
	echo "Administrative privilage required...">/etc/Network_Builder_V0.1/logs/NFS/nfsk.msg
	exit
fi

# ... (script continues to perform configuration tasks) ...

# <--- MORE WRITING TO MESSAGE FILE
service iptables save>>/etc/Network_Builder_V0.1/logs/NFS/nfsk.msg
service nfs restart>>/etc/Network_Builder_V0.1/logs/NFS/nfsk.msg
service nfslock restart>>/etc/Network_Builder_V0.1/logs/NFS/nfsk.msg
# ...

What this code does: This shell script is writing directly into /etc/Network_Builder_V0.1/logs/NFS/nfsk.msg. The > operator overwrites the file, while >> appends to it. This means the script provides step-by-step updates or a final summary to this file, making it available for the Java GUI to display.

Another example from a status script, dhcps.sh, writing to a .status file:

#!/bin/bash
# File: configuration codes/dhcps.sh (simplified)

# ... (logic to determine DHCP status) ...

if [[ -z $a ]] # If DHCP service was stopped or not running
then
	# <--- WRITING TO STATUS FILE
	echo "DHCP Status: Stopped">/etc/Network_Builder_V0.1/logs/DHCP/dhcpk.status
else # If DHCP service was running and stopped
	# <--- WRITING TO STATUS FILE
	echo "DHCP Status: Running">/etc/Network_Builder_V0.1/logs/DHCP/dhcpk.status
	service dhcpd start>>/dev/null # Restart if it was running
fi

What this code does: After checking the DHCP service's state, this script writes a clear line like "DHCP Status: Stopped" or "DHCP Status: Running" directly into /etc/Network_Builder_V0.1/logs/DHCP/dhcpk.status. This .status file then holds the single, up-to-date status for the DHCP service.

3. GUI Reading Status from a .msg or .status File (Script to GUI)

Finally, here's how a Java GUI frame reads these messages from the files and displays them to you:

// File: Java Source Code/nfsstatus.java (simplified)
// ... (inside initComponents method, or a button's actionPerformed) ...
    private void initComponents() {
        // ... (GUI component setup) ...
        jTextArea1.setEditable(false); // Status window is read-only
        // ...
        String str_status;
        try{
            // <--- READING FROM STATUS FILE
            BufferedReader br1=new BufferedReader(
                new FileReader("/etc/Tools/cnfsk.status")); // Open the status file

            while ((str_status = br1.readLine()) != null) // Read line by line
            {
                jTextArea1.append(str_status + "\n"); // Add to the text area
            }
            br1.close(); // Don't forget to close the reader!
        } catch(Exception e) { /* Handle errors if file not found */ }
    }
// ...

What this code does: This Java code opens the cnfsk.status file (which would contain a status message written by an NFS status script). It then reads the file line by line using br1.readLine() and adds each line to the jTextArea1 component, which is visible on the GUI. This is how the script's output becomes visible to you.

You'll see similar patterns in other GUI frames and scripts, like wlp.java, dhcpframe.java, natframe.java, and their corresponding shell scripts. This file-based method ensures clear and robust communication across the entire shellnetbuilder application.

Summary and Conclusion

In this final chapter, we've brought together all the pieces of shellnetbuilder by understanding File-based Inter-process Communication (IPC). We learned that:

• It's the essential "message board" that allows the Java GUI application and the powerful backend shell scripts to talk to each other.
• The Java GUI writes configuration details into .log files to inform the scripts.
• The shell scripts write their operational results, status updates, or error messages into .msg or .status files.
• The Java GUI then reads these output files and displays the information to you, completing the feedback loop.

This mechanism, while simple, is robust and effective for connecting the user-friendly interface with the low-level system configuration tasks, making shellnetbuilder both accessible and functional.

This concludes our tutorial on the core concepts of shellnetbuilder. You now have a foundational understanding of how this project orchestrates, displays, secures, configures, manages, and communicates across its different layers!

---

_{^{References: [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22]}}