You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The gRPC protocol is defined as sending over the bytes of arrays directly, but does not take into account endianness. This means the protocol will fail spectacularly (type 3 error, bad data with no error) if the client and server machines have different native endianness.
Yes, I've had to deal with this kind of problems in the past... machine endianness is a good point to take into account. We wanted to test serialization/deserialization of data in this example. But I guess we didn't take that into account. We could probably send the machine's endianness as part of the metadata.
The use of bytes was purposefully intended, since what we usually transmit is chunks of bytes from one machine to another. Using arrays would have been the best solution indeed for this case-scenario, but we wanted to show an example of serialization/deserialization.
@akaszynski do you think we should look into changing the nature of the data from bytes to an array? If so, I'll take care of the implementation.
Your feedback is much appreciated @phxnsharp! The machine endianness was a very good point.
The gRPC protocol is defined as sending over the bytes of arrays directly, but does not take into account endianness. This means the protocol will fail spectacularly (type 3 error, bad data with no error) if the client and server machines have different native endianness.
api-eigen-example/src/ansys/eigen/cpp/grpc/client/src/GRPCClient.cpp
Line 499 in 108085f
api-eigen-example/src/ansys/eigen/python/grpc/client.py
Line 280 in 108085f
Unless there is another reason, I recommend using gRPC arrays instead of bytes. gRPC can handle this for us.
The text was updated successfully, but these errors were encountered: