Protocol - trevex/golem GitHub Wiki

The communication of golem is based on event emission similar to socket.io. This means either the client or server emits an event and the other side reacts, e.g.:

Client:

golem.emit("hello", { from: "client", to: "server" });
golem.on("answer", function(data) {
    console.log("hello from "+data.from+" to "+data.to);
});

Server:

type Hello struct {
    From string `json:"from"` 
    To string `json:"to"`
}

myrouter.On("hello", func(conn *golem.Connection, data *Hello) {
    fmt.Println("hello from", data.From, "to", data.To)
    conn.Emit("answer", Hello{"server", "client"})
})

Why JSON?

The main reason to use JSON by default over different other standards (e.g. BSON, MessagePack) is the native evaluation on the browser-side. Although marshalling of JSON can take longer than other formats on the server-side, the benefit is the increased performance on the client-side. This is not a big issue for websites with minor communication, but especially games that use WebSocket extensively would suffer a major performance penalty (this leads back to a university project running natively in the browser without plugins, where JSON was used instead of BSON, because unpacking of BSON messages resulted in lagg spikes). Another reason that supports JSON is the human readability, which eases up debugging.

The "protocol"

The protocol is so simple, that it can barely be called "protocol". First of the data is packed using JSON. To illustrate this the data being send in the previous example is used:

{ "from": "client", "to": "server" }

The emitted event is not part of the data! The emitted event or routing information is prepend to the JSON-object, i.e.:

hello { "from": "client", "to": "server" }

The space between the event name and JSON-object is necessary, because it is the default separator of golem.

As previously mentioned it is very simple, but this simplicity allows very fast parsing of incoming data on the server-side by splitting the incoming data into the event name string and data byte-array using the separator.

Future

There are future plans to make the protocol itself exchangeable by custom protocols (e.g. completely MessagePack-based approach et cetera).