implement `--hex` feature for interpreting messages as hex strings

[reactive-firewall]

To retrieve the hex string from the process p in this test function, you can capture the standard output of the receiver process and reconstruct the binary data. Here's how you can modify your test function:

1. Modify the Receiver to Output the Hex String:

Ensure that the receiver process is configured to print the received message in hexadecimal format to stdout. You may need to adjust the receiver function in your multicast module to do this.

# In the multicast receiver script
def receive_message(args):
    # ... existing setup code ...
    data, addr = sock.recvfrom(10240)
    print(data.hex())  # Output the received data as a hex string

2. Update the Test Function to Capture stdout:

When starting the receiver process in your test, set stdout=subprocess.PIPE to capture the output.

p = Process(
    target=multicast.main,
    args=(_fixture_HEAR_args,),
    stdout=subprocess.PIPE,
    stderr=subprocess.PIPE
)
p.start()

3. Send the Message and Capture the Output:

After sending the message from the sender, wait for the receiver process to finish and then read the captured output.

p.join(timeout=15)  # Wait for the receiver process to complete
output, errors = p.communicate()  # Capture stdout and stderr

4. Reconstruct the Binary Data from the Hex String:

Decode the hex string received from the receiver process back into binary data.

received_hex = output.decode('utf-8').strip()
binary_data = bytes.fromhex(received_hex)

5. Verify that the Sent and Received Data Match:

Add an assertion to verify that the original data matches the data received by the receiver process.

self.assertEqual(data, binary_data)

Complete Modified Test Function:

def test_multicast_sender_with_random_data(self, data):
    # ... existing setup code ...

    # Start the receiver process and capture stdout
    p = Process(
        target=multicast.main,
        args=(_fixture_HEAR_args,),
        stdout=subprocess.PIPE,
        stderr=subprocess.PIPE
    )
    p.start()

    # Send the message from the sender
    result = multicast.main(_fixture_SAY_args)

    # Wait for the receiver process to complete
    p.join(timeout=15)
    output, errors = p.communicate()

    # Reconstruct the binary data from the hex string
    received_hex = output.decode('utf-8').strip()
    binary_data = bytes.fromhex(received_hex)

    # Verify that the sent and received data are the same
    self.assertEqual(data, binary_data)
    self.assertTrue(result)

Notes:

• Process Communication: By capturing stdout using subprocess.PIPE, you can read the output directly from the receiver process.
• Error Handling: Make sure to capture any errors from stderr for debugging purposes.
• Adjusting the Receiver Script: Ensure that the receiver script prints the received data in hex format. If modifying the production code is not desirable, consider creating a test-specific receiver function.
• Overhead Considerations: While hex encoding doubles the data size, it simplifies the conversion process. If overhead is a concern, you might opt for Base64 encoding, which is more size-efficient.

Example Using Base64 Encoding (Optional):

Sender Side:

import base64

# Encode data to Base64 string
encoded_data = base64.b64encode(data).decode('utf-8')

_fixture_SAY_args = [
    "--port", str(_fixture_port_num),
    "--mcast-group", "'224.0.0.1'",
    "--message", encoded_data
]

Receiver Side:

# In the multicast receiver script
def receive_message(args):
    # ... existing setup code ...
    data, addr = sock.recvfrom(10240)
    print(data.decode('utf-8'))  # Output the received Base64 string

Test Function Adjustments:

import base64

# ... after capturing output ...
received_base64 = output.decode('utf-8').strip()
binary_data = base64.b64decode(received_base64)
self.assertEqual(data, binary_data)

Benefits of Base64 Encoding:

• Reduced Overhead: Increases data size by approximately 33% compared to 100% with hex encoding.
• Standard Practices: Base64 is commonly used for encoding binary data in text-based protocols.

Let me know if you have any questions or need further assistance!

---

🧠 Learnings used

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#110
File: docs/CI.md:32-32
Timestamp: 2024-09-17T06:40:42.918Z
Learning: Reactive-firewall prefers to keep the word "own" in headings when emphasizing the reader's personal test.

---

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#110
File: docs/USAGE.md:66-66
Timestamp: 2024-09-17T03:38:28.677Z
Learning: Reactive-firewall prefers to use "Caveat" as a heading instead of "Caution".

---

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#118
File: tests/check_pip:92-197
Timestamp: 2024-09-24T01:03:10.574Z
Learning: Reactive-firewall prefers defining functions before they are called in Bash scripts to avoid errors due to Bash's sequential interpretation.

Originally posted by @coderabbitai[bot] in #139 (comment)

[reactive-firewall]

🤔 how can we design this feature or features to be SOLID and account for the ability to use different handlers for the HEAR server to handle each and possibly other custom handlers from client code.

The transcoding should be as simple as described above in the description.

[reactive-firewall]

@coderabbitai, please look at this old issue (eg GHI #140) and the current codebase and help me explore the implementing of a new --hex feature in a more up to date plan, including a suggested implementation with necessary tests and documentation changes too.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

[coderabbitai]

Oops, something went wrong! Please try again later. 🐰 💔