Refactoring `Communicant`

[novakboskov]

Communicant has a function for each type/class it can transfer. Instead, each class should have a toBytes and fromBytes methods and Communicant should only be calling those methods.

My current idea is to support this by creating an abstract class Serializable that exposes toBytes and fromBytes. Each class that can be sent over Communicant would inherit from Serializable.

[trachten]

Makes sense … similar to Java. For security, there should be some sort of checks on what is being deserialized, if possible.

On Jul 21, 2020, at 9:43 PM, Novak Boškov notifications@github.com wrote:

Communicant has a function for each type/class it can transfer. Instead, each class should have a toBytes and fromBytes methods and Communicant should only be calling those methods.

My current idea is to support this by creating an abstract class Serializable that exposes toBytes and fromBytes. Each class that can be sent over Communicant would inherit from Serializable.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/trachten/cpisync/issues/68, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACM5LU6UNPYRFMFUVPHJUYLR4Y73RANCNFSM4PEG5YCA.

---

Prof. Ari Trachtenberg ECE, Boston University trachten@bu.edu http://people.bu.edu/trachten

[arorashu]

Summarizing my approach here:

Serialization requirements:

1. serialize class → send over socket | receive over socket → deserialize to
2. all commSend() methods eventually call void commSend(const char *toSend, size_t numBytes);

Serialization, deserialization is a standard problem, and while it is very much possible to write your own serialization and deseralization routines, there are a few gotchas, a standard recommended solution is the Boost serialization library.

Action steps

I'll do a prototype using the boost library, and post the results here. I'll also compare the communication time of existing technique with any new serialized implementation, at least just for documentation purposes.

P.S. other solutions I surveyed were:

1. https://developers.google.com/protocol-buffers
2. https://github.com/google/libnop
3. https://github.com/nlohmann/json#serialization--deserialization

[trachten]

I'd prefer not to be tied to the boost library unless it's necessary, as it adds yet one more dependency to the library.

On Aug 5, 2020, at 2:38 PM, 8/5/20, Shubham Arora notifications@github.com wrote:

Summarizing my approach here:

Serialization requirements:

serialize class → send over socket | receive over socket → deserialize to all commSend() methods eventually call void commSend(const char *toSend, size_t numBytes); Serialization, deserialization is a standard problem, and while it is very much possible to write your own serialization and deseralization routines, there are a few gotchas, a standard recommended solution is the Boost serialization library https://www.boost.org/doc/libs/1_37_0/libs/serialization/doc/index.html.

Action steps

I'll do a prototype using the boost library, and post the results here. I'll also compare the communication time of existing technique with any new serialized implementation, at least just for documentation purposes.

P.S. other solutions I surveyed were:

https://developers.google.com/protocol-buffers https://developers.google.com/protocol-buffers https://github.com/google/libnop https://github.com/google/libnop — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/trachten/cpisync/issues/68#issuecomment-669387530, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACM5LU3K34JX2J4BDNLDYYTR7GRIXANCNFSM4PEG5YCA.

---

Ari Trachtenberg, Boston University http://people.bu.edu/trachten mailto:trachten@bu.edu

Random quote of the day: 
A conclusion is the place where you got tired of thinking. 

[arorashu]

That is my first instinct too, hence it might be worthwhile to have a bare bones custom implementation, the robustness would then evolve as we need it to.

[trachten]

agreed

On Aug 5, 2020, at 3:14 PM, 8/5/20, Shubham Arora notifications@github.com wrote:

That is my first instinct too, hence it might be worthwhile to have a bare bones custom implementation, the robustness would then evolve as we need it to.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/trachten/cpisync/issues/68#issuecomment-669420495, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACM5LUZZ5A33ZT6GIL2C67LR7GVTHANCNFSM4PEG5YCA.

---

Ari Trachtenberg, Boston University http://people.bu.edu/trachten mailto:trachten@bu.edu

Random quote of the day: 
A conclusion is the place where you got tired of thinking.