The issue with that approach is that gob keeps state about which type-information it still has to send. So if you encode to, say, a bytes.Buffer, it would encode all type-info on every message sent, which is a significant overhead. TBH, I don't understand why `io.MultiWriter` wouldn't work. It would be helpful to see the code that causes the error message OP is seeing.
However, really, gob just doesn't provide a good API for this sorta thing, as mentioned. The format itself is fine, but the stateful connection means that if you don't want to write *exactly* the same data in exactly the same order to all connections (which can perform poorly and lead to operational problems with timeouts and intermittently lost connections and the like), you are going to have a bad time. You honestly would fare better with a full-fledged RPC framework such as gRPC. Or, if you don't want the overhead of its IDL, even json. Because at least the "encode once, send to each client" is trivial to solve with that. But, that's just my 2¢ :) On Wed, Dec 23, 2020 at 11:43 PM Robert Engels <reng...@ix.netcom.com> wrote: > Yes, that is why you need to create your own protocol. Use the gob to > encode to a buffer then send the buffer on each of the connections using > your protocol. > > On Dec 23, 2020, at 4:19 PM, Matthew Zimmerman <mzimmer...@gmail.com> > wrote: > > > My understanding is that gob streams are unique. > > From https://golang.org/pkg/encoding/gob/ > "A stream of gobs is self-describing. Each data item in the stream is > preceded by a specification of its type, expressed in terms of a small set > of predefined types." > > In my own rudimentary understanding/terms, it sends the struct definition > once, then uses shorthand for it afterwards. E.g, how many bytes and what > order. If you mix and match streams that send definitions in different > orders, then chaos ensues. > > I think this is why people use other encoders in the scenario you're > taking about. For a one to one stream gob works great, but in this multi > scenario I don't think it does. > > Matt > > On Wed, Dec 23, 2020, 5:07 PM Artur Vianna <lordhowen...@gmail.com> wrote: > >> If i create a bytes.Buffer and a gob.Encoder, each time i write to a >> group of connections i get "duplicate type received" and if i try and reuse >> the encoder, i get "corrupted data" and "unknown type". >> It seems i can't use both net.Conn.Write and gob.Encoder.Encode in the >> same connection, i will try always encoding to a buffer in both unicast and >> multicast like you said and report if it works. >> >> On Wed, 23 Dec 2020, 18:49 Robert Engels, <reng...@ix.netcom.com> wrote: >> >>> You need to encode once to a byte array then send the byte array on each >>> connection. >>> >>> On Dec 23, 2020, at 3:45 PM, meera <lordhowen...@gmail.com> wrote: >>> >>> >>> I am trying to create a package for game servers using gob. The current >>> approach is an application level multicasting over TCP, having a gob >>> encoder and decoder for each player connection, and set up a goroutine to >>> receive and another to dispatch for each one. The code for the dispatcher >>> is here. But summarized, it simply receives data from a channel and encodes >>> it. >>> >>> The problem is that if i want to transmit a single piece of data to all >>> players, this piece of data is encoded again and again for each connection, >>> doing duplicate work. With less than 100 players this is not a problem, but >>> with 300+ my machine is at almost 100% usage and the profiler shows that >>> most of it is spent on encoding. Here's the issue on github. >>> >>> I tryied using a io.MultiWriter but gob complains of duplicate type >>> received, and if i try to write the raw bytes from the gob.Encoder i get >>> corrupted data. An option is using UDP Broadcasting but since gob expects a >>> stream, i'm affraid i will run into unexpected behavior when packets start >>> to be lost and fragmented. >>> >>> Does gob expect a single encoder and decoder to own the stream? Not >>> allowing two encoders on the server for one decoder on the client? >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to golang-nuts+unsubscr...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/0562184e-bbcc-44c9-adbf-37e8d5411c7cn%40googlegroups.com >>> <https://groups.google.com/d/msgid/golang-nuts/0562184e-bbcc-44c9-adbf-37e8d5411c7cn%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/CAE%3DAWBXN46idvqUbCsGs%2BZbZt%2BCj4MowJ4Ozj3_U9_6-68OWDw%40mail.gmail.com >> <https://groups.google.com/d/msgid/golang-nuts/CAE%3DAWBXN46idvqUbCsGs%2BZbZt%2BCj4MowJ4Ozj3_U9_6-68OWDw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/214752B6-2666-4892-A9B8-E4BC4127FD42%40ix.netcom.com > <https://groups.google.com/d/msgid/golang-nuts/214752B6-2666-4892-A9B8-E4BC4127FD42%40ix.netcom.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGWtULh8Q3Jqu_gq5m5Si4PvJ1oVSZY7DVhu%3D6hGK83bg%40mail.gmail.com.
