Open padeir0 opened 3 years ago
Gob expects a end-to-end stream between encoder and decoder. It does not know if the receiver has received the type information, if the type is sent more than once, it panics. Also, it may write more than once per each encoding, if done concurrently from two different encoders/writers, the stream will crumble up and it will corrupt the data.
To solve this issue, i'm implementing a Protocol interface that can be used to marshal the data directly in the stream. To be able to use this alongside gob, a function NewProtocol(Encoder, Decoder)
is used.
https://github.com/kazhmir/gna/blob/7c6ca39c05dc1666adbea025b151731860cb3d52/group.go#L52
This creates an exponential relationship between number of players in the server and number of encodings. When #players > 100, the gob.Encode function takes most of the execution time, while encoding the same object, limiting the maximum number of players to ~365 in my machine.
If the Group encodes and send the raw bytes to each dispatcher it should cut it. Although i'm not sure how to do it without the gob complaining.
Something on the lines of:
But this is kind of ugly and makes gob spit out "duplicate type received". Reusing the encoder and buffer makes the gob complain: "corrupted data" and "unknown type". I may try a MultiWriter, but i'm not sure how the write errors are going to be handled this way.
I will need to dig through the gob internals and try out some options.