Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sometimes sendClassical changes a msg from one thing into another thing #59

Open
brunorijsman opened this issue Dec 6, 2019 · 2 comments
Assignees

Comments

@brunorijsman
Copy link

brunorijsman commented Dec 6, 2019

Say Alice calls sendClassical with msg = b'01' (= two bytes, first character 0 = ASCII 48, second character 1 = ASCII 49).

When Bob calls recvClassical it receives a different msg = b'\x01' (= one byte, value 1).

This is because of the following piece of code:

try:
    to_send = bytes([int(msg)])
except (TypeError, ValueError):
    to_send = bytes(msg)

You can see that:

>>> msg = b'01'
>>> bytes([int(msg)])
b'\x01'

The better approach would be something along the lines of:

if isinstance(msg, bytes):
    # Already provided as bytes, nothing to do
else:
    # Provided as something else than bytes, convert to bytes

And even that is not ideal, because there are still corner cases where the receiver gets something different than the sender sent.

A better option could be to use pickle to serialize messages on-the-wire.

I know it is "not safe" to unpickle messages received on-the-wire from an untrusted source, but it's probably good enough for simulations.

The pickling and unpickling could be done inside sendClassical and recvClassical, or the burden could be put on the application and sendClassical and recvClassical could insist on only getting messages of type bytes.

The former is more convenient for the application, the latter gives the application their own choice of serialization method (including the option of using something more safe than pickle).

@AckslD Feel free to assign to me. I can fix the issue and generate a pull request.

@AckslD
Copy link
Member

AckslD commented Dec 11, 2019

Hi @brunorijsman! If you have the time to fix the issue and open a PR that would be great :)

@brunorijsman
Copy link
Author

Same here (as in #58): I will take a shot at fixing the issues, cleaning up the code, and getting to better performance in the process. Expect pull request to review, hopefully within the next week or two.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants