A.4. Notes

A.4.1. Constraints

In some part, current wire-format -- i.e. all requests and responses preceeded by a length -- has been dictated by current server non-async architecture.

A.4.2. One fat pb request or header+param

We went with pb header followed by pb param making a request and a pb header followed by pb response for now. Doing header+param rather than a single protobuf Message with both header and param content:

  1. Is closer to what we currently have

  2. Having a single fat pb requires extra copying putting the already pb’d param into the body of the fat request pb (and same making result)

  3. We can decide whether to accept the request or not before we read the param; for example, the request might be low priority.  As is, we read header+param in one go as server is currently implemented so this is a TODO.

The advantages are minor.  If later, fat request has clear advantage, can roll out a v2 later.

A.4.3. Compression

Uses hadoops compression codecs.

comments powered by Disqus