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

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 https://github.com/reactive-firewall/multicast/pull/139#discussion_r1780693414_

reactive-firewall / multicast

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