Gob encoding, how do you use it in production environement ?

<p>Hello people from <a href="/r/golang" rel="nofollow">r/golang</a> </p> <p>I found a problem that is really surprising while using Gob. First, I want to say that I love how easy it is to play around. But I want to know more about how you would use it in production. </p> <p>Let&#39;s say that you have three program communicating. They use gobs for encoding and decoding. Since gob want to be efficience and self explanatory, the first time it encodes the data, it will give full information about it and then it will make the next encoded data way more smaller for the give type. </p> <p>The problem is that the decoder, if he receives the full information of the same data twice, will panic and send &#34;gob : extra data in the buffer&#34;. It&#39;s normal but at the same time very confusing. This means that you cannot let the decoder and encoder open ... unless you communicate with only one program, not two using the same type of data. </p> <p>You can have the same error, of course, while using a file. More here : <a href="https://stackoverflow.com/questions/36385955/retrieving-gobs-written-to-file-by-appending-several-times" rel="nofollow">https://stackoverflow.com/questions/36385955/retrieving-gobs-written-to-file-by-appending-several-times</a> </p> <p>How do you handle Gob in your code ? Do you close and open the encoder and decoder every time you want to send/receive data ? Did you switch to something else completly like JSON or ProtoBuffer ? </p> <p>Thank you very much !</p> <hr/>**评论：**<br/><br/>dbud: <pre><p>Gob is really only useful as a streaming codec. And, in that context, you would create an encoder/decoder for each stream.</p> <p>So in your example, the 3 programs would each maintain a socket connection and a encoder/decoder pair per connection.</p> <p>Using it as an encoding for HTTP style stuff, and reusing the encoder/decoder is super-dangerous when it comes to stuff like live upgrades where it&#39;s possible that 2 different apps have different definitions of the same type.</p> <p>for example: v1 of your code has struct { A int } v2 has struct { A int, B string }</p> <p>if you used the same decoder for talking to those two programs, you wouldn&#39;t know how to parse that struct.</p> <p>but, if you apps connect via a persistent socket, you can easily just create a codec per connection, then there&#39;s zero chance that the type changes mid-stream since the corresponding process would have to be restarted, causing the socket to drop and you to re-establish the connect (thereby re-creating the codec)</p></pre>PaluMacil: <pre><p>If my memory serve me correctly, I think someone opened an issue about this and Rob Pike mentioned that the new decoder per decode is not expensive. I&#39;d have to dig to find the issue though. Additionally, the Stack Overflow description seems to make sense in indicating that the header info might factor in to how it is intended to work.</p></pre>Rudd-X: <pre><p>Use protobufs.</p></pre>