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

Use binary serialization for communication to improve efficiency #19

Open
likebreath opened this issue Feb 21, 2017 · 3 comments
Open
Assignees

Comments

@likebreath
Copy link
Collaborator

Text serialization is being used in several places of crete-run, vm-node, etc. For the sake of efficiency, they should be replaced by binary serialization.

A driven example is transmitting the guest config file from crete-run to vm-node can take a long time, when the guest config file is non-trivial (such as when we give a concrete file of size 200K as the seed of concolic file, the serialized config file can be over 800K).

By design, "crete/asio" provides a set of read/write communication functions using different serialization format, and they should have the same usage convention. However, it seems "write_serialized_binary() / read_serialized_binary()" can not be directly used as an alternative of "write_serialized_text_xml() / read_serialized_text_xml()".

One concrete example is: when replacing the "_text_xml" pair with "_binary" pair in "RunnerFSM_::transmit_guest_data()" and QemuFSM_::receive_guest_info(), there will be an exception thrown while reading/de-serializing.

Exception info:

std::exception::what: std::exception
[crete::err::tag_msg*] = Dynamic exception type: std::length_error
std::exception::what: basic_string::resize

@likebreath
Copy link
Collaborator Author

@moralismercatus I have reviewed the related code, and found nothing special. "_text_xml" and "_binary" are identical except they are using different boost serialization formt (text_xml and binary). I also checked the version of boost both on guest and host, and they are both 1.59. To this point, I don't have additional suspects about this problem. Please let me know your inputs. Thanks.

@moralismercatus
Copy link
Collaborator

@likebreath Are the guest and host identical platforms? Are they both x64? Just guessing, but it may be an issue with binary compatibility. As a matter of general design, it may not be prudent to make the serialization from guest to host binary.

It may be a better approach to rework how the config is transferred. Essentially, send the binary data as binary and the textual data (the config details) as text.

I'd write a patch for you, but I'm pretty sick right now. It'll probably be a couple days before I can get around to it.

@likebreath
Copy link
Collaborator Author

likebreath commented Feb 21, 2017

@moralismercatus Thanks for the quick replay.

You are right. Binary archive from boost serialization is not portable for cross-platform while other formats of archives are (ref).

No hurry about the patch at all. Do you mean a patch for the rework you mentioned? If yes, let's talk about the detail before start the work. Also, it is not a big issue, if the only motivation is to get the guest config file transferred in a more compact way, because for a whole test, the guest config file only needs to be transferred once.

For now, I will just use non-binary serialization for the communication between guest and host. Also, I will add comments about the portability in the header file.

Take care and hope you get well soon.

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

No branches or pull requests

2 participants