Protobufs is what you want. Since you have the schema on server and client the
amount of data dictionary overhead per message is minimal - essentially numeric
tags and the raw data.
> On Dec 24, 2020, at 8:21 AM, Artur Vianna wrote:
>
>
> I will definitely explore your ideas, thanks for the
I will definitely explore your ideas, thanks for the insights. I'll let you
know how it turned out in the end :D
Thanks
On Thu, 24 Dec 2020, 06:59 Axel Wagner,
wrote:
> On Thu, Dec 24, 2020 at 6:35 AM Artur Vianna
> wrote:
>
>> Exposing the bytes would hurt the abstraction.
>>
>
> I strongly d
On Thu, Dec 24, 2020 at 6:35 AM Artur Vianna wrote:
> Exposing the bytes would hurt the abstraction.
>
I strongly disagree with this. Exposing the bytes would improve the
abstraction, by making the transmission- and encoding method orthogonal.
And as I said, you can still provide just as conveni
In games most code is shared between server and client so normally they're
built on the same language, and even in the same framework. Sometimes you
need to share load with the client to increase the amount of players. So
I'm not too worried about inter-language interoperability.
I'm not sure havi
Exposing the bytes would hurt the abstraction. Game servers usually only
process data in certain intervals (say 20 times per second), that means i
would either need to expose the net.Conn for reading, or creating a buffer
for each connection and acumulate the data on memory, so that each time the
s
I looked at your top level README.md to understand what you are doing.
Do these players join at the same time or different times? If different times,
that can explain corruption with MultiWriter.
One suggestion is to use "bufio" to create a writer for the gob encoder out of
a []byte buffer. Then
That’s good to know. I figured after 20+ years of learnings with Java
serialization that a somewhat modern version would have the ability to reset
the stream. This is required for large dynamic object models. Very surprising.
> On Dec 23, 2020, at 6:56 PM, 'Axel Wagner' via golang-nuts
> wrot
On Thu, Dec 24, 2020 at 1:08 AM Artur Vianna wrote:
> Before using gob was using encoding.BinaryMarshaler, but that would mean
> the user of the api would need to implement a MarshalBinary for every type,
> which is kind of cumbersome.
>
> An option might be to let the user choose gob, BinaryMar
On Thu, Dec 24, 2020 at 1:46 AM Robert Engels wrote:
> I was referring to the comments about the encoder keeping state. You can
> reset the encoder. You may need your own framing to do so - I’m not looking
> at the gob streaming encoder docs - but if it is a decent streaming encoder
> it should h
I was referring to the comments about the encoder keeping state. You can reset
the encoder. You may need your own framing to do so - I’m not looking at the
gob streaming encoder docs - but if it is a decent streaming encoder it should
have a reset mechanism.
That being said it is probably easi
I'm confused to which part of the thread you're referring to
On Wed, 23 Dec 2020, 21:30 Robert Engels, wrote:
> That is not true. Java serialization works similarly. You can hook it do
> that you send the metadata once during connect, and then encode the data.so
> no a new connection only needs
That is not true. Java serialization works similarly. You can hook it do that
you send the metadata once during connect, and then encode the data.so no a new
connection only needs the metadata and can decode further stream messages. You
may need framing resets to simplify things and reduce the o
Before using gob was using encoding.BinaryMarshaler, but that would mean
the user of the api would need to implement a MarshalBinary for every type,
which is kind of cumbersome.
An option might be to let the user choose gob, BinaryMarshaler or Json etc
to best fit the use case, but that takes the
No, it wouldn't. Because the encoder keeps state about which
type-information it already sent and wouldn't sent it again - causing the
client to be unable to decode. So you'd also need a new encoder on the
server. And at that point, you're back to the status quo, with one encoder
per client and the
There are ways to control the framing but in my experience a pseudo multicast
scenario is best implemented with a proprietary protocol. You can do this
easily on top of other transports Luke grpc/protobufs.
> On Dec 23, 2020, at 5:20 PM, Matthew Zimmerman wrote:
>
>
> If you would "reset"
If you would "reset" each client with a new decoder each time you make a
new encoder, everything should work fine. Just would take some
coordination.
On Wed, Dec 23, 2020, 6:08 PM Artur Vianna wrote:
> I will look into other protocols, although for now the performance is not
> an issue in serve
I will look into other protocols, although for now the performance is not
an issue in servers with less than 100 players.
The problem with io.MultiWriter is that a player inside the group may
disconnect or a new player may come in. This means a new io.MultiWriter
must be created each time you disp
Dnia 2020-12-23, o godz. 13:45:10
meera napisał(a):
I'd use flatbuffers.
https://google.github.io/flatbuffers/flatbuffers_guide_use_go.html
It is possible to extract gob encoded bytes and copy it over multiple receivers
but it
would be an overkill, likely.
--
Wojciech S. Czarnecki
<< ^oo^
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 woul
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 wrote:
>
>
> My understanding is that gob streams are unique.
>
> From https://gola
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/te
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
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 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
> an
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 her
24 matches
Mail list logo
