Protocol Documentation about logdevice

[sh00s]

If it's purely a writer API, that would be more doable indeed.

For a writer API, you'd need to:

1. fetch the config of the cluster and parse the list of nodes that have sequencing enabled
2. figure out which node holds the sequencer for a log (this is done through consistent-hashing the log_id against the list of nodes in the config that are enabled for sequencing, see HashBasedSequencerLocator). If the node turns out to be down, you'll have to remove it from the list and try to rehash (you can later improve on this by fetching a list of live nodes from a random node in the cluster).
3. establish a connection to that node, negotiate a protocol version and send an APPEND message and interpret the APPENDED message that you'd get in response (it may contain redirects and such).

All the message definitions (and serializers/deserializers for the protocol) are here. You can start with the protocol header, then see HELLO and ACK messages that are used to establish a connection. The messages used for communicating writes from clients to servers are APPEND, the response will come as an APPENDED message.

Have fun! :D

[sh00s]

You would have to read way less C++ if you went for the bindings vs. trying to figure out the existing logic and protocol :D

Sorry, I won't have time to help you find all the definitions in the code. Try getting an IDE that would do that for you (e.g. vim with ctags). Writing documentation on the protocol also won't be at the top of our priority list any time soon. It may be a good idea to generally describe how the reader/writer work though.

The only currently supported platform is x86-64. In theory any little-endian 64-bit platform should work (?), but we haven't tried other platforms, so in practice there may be some breakage.

[sh00s]

LogDevice has a very heavy client, especially on the read path (e.g. just ClientReadStream-related code is 10K lines). Developing an alternative client and maintaining it would be a very complex project.

Which language are you interested in developing a client library for? Could it bind to the C++ client instead?

[pascaldekloe]

Yes, this refreshing design would make such development quite interesting. Personally I'd like to give the writer a try with Go. The langue has quite a few useful features (like channels) to support the heavy lifting. A plain binding would probably work and of course there are downsides to that such as slow compile times and limitations on the threading model.

[sh00s]

Just to be clear: this can be a fun thing to play with, but I'd heavily discourage you or anyone else create/use a client that's not just bindings to the C++ client unless it provides very clear benefits. Duplicating complex logic in different languages and then maintaining it isn't something we should be doing unless there's a very clear win.

[pascaldekloe]

Clear. For me the clear win is no C++ which is almost impossible to read. ;-) Where is request_id_t defined or Status? For some reason each message has its own serdes code and it looks like the process is dumping raw structs and primitives here and there which makes it AMD64 only? In other words, people like me need a lot of help or some documentation. 😕

[pascaldekloe]

Thanks for the feedback anyway. :-) Maybe as a finishing touch document the AMD64-only requirement somewhere?