CODEWITHSUNDEEP
gonetwork-programminggob
Cshark
Cshark

Reputation: 111

Gob over the wire

I'm considering using gob ("encoding/gob") for serializing data in a network protocol, I have been searching around and can't seem to find any solution to these problems:

Message framing - The gob documentation gives the impression that you can simply wrap your TCP connection in a gob decoder and read away. But what happens if you only received half a message? Can gob somehow deal with this or am I forced to add a message frame and copy over the message data into a buffer for gob to unserialize?

Different types of messages - The protocol has different types of messages, how is this best handled with gob? By having an identifier before every gob blob indicating the type of the data? By putting all messages into a "Master" message which contains fields for all the different messages (reducing it to only one type of message)? I tried the latter (simpler) and it seems to have a HUGE overhead (>650 bytes).

Upvotes: 2

Views: 864

Answers (1)

Thundercat
Thundercat

Reputation: 121119

The gob documentation gives the impression that you can simply wrap your TCP connection in a gob decoder and read away.

Correct. The package is designed to stream multiple values between an encoder and a decoder.

But what happens if you only received half a message?

The decoder calls the underlying io.Reader to get data. If reader cannot return data, then the reader will return an error. The decoder returns this error to the application.

There's no way to recover the decoding stream if the io.Reader returns an error.

Different types of messages

You can encode pairs of messages where the first tells the application the type to expect in the second.

You can also create a "master" type as you describe. The overhead that you see is incurred once per stream, not once per value.

Upvotes: 4

Related Questions