chasester / Rival3dengine

8 stars 2 forks source link

gRPC initial investigation #35

Open api-Hypernova opened 7 years ago

api-Hypernova commented 7 years ago

Preliminary task to evaluate the usability of gRPC and see if it's a substantial improvement enough over the current system that we should further investgate.

chasester commented 7 years ago

unless gRPC is different from tradition RPC I dont see how this could be useful. It could be useful if the calls could be made then the updates updated when they come back instead of sending the program into a block state. But even then It may not be exactly useful in our case, saying we are already regularly checking updates and sending replys, this may just be an unneeded layer on top of the server code which wont be fully utilized,

this is the video I watched on it https://www.youtube.com/watch?v=MNajQHiA2-k

he skips over the limitations so you may need to pause the video to read them, though you can duce the limitations from his half baked explaination.

AndyM84 commented 7 years ago

It's not that hard to have bidirectional setups with gRPC, it is supported and you can use it pretty flexibly.

http://www.grpc.io/docs/guides/concepts.html#bidirectional-streaming-rpc

api-Hypernova commented 7 years ago

(from @chasester on the old ticket)

We can use object level serialization. Since as objects and types will have node ids and these Ids will remain constant between client and server we can simply send the serialized tree of said changed objects, or the changes of the object and location in the object that needs changed. Then we can use a call in as that will automatically track the the changes in a variable and add it to the buffer. So I can declare something like class player { vec o; vec rot; awake() { sendchagestoserver(@o); sendchangestoserver(@rot); } ... };