> > Yeah, found it. Pretty strange way to encode (why not use custom HTTP > headers e.g. X-Libprocess-From). Are you suggesting that this protocol > should not be documented and made external, instead some other protocol > should be used for communication? >
No. I'm in favor of documenting the protocol and sticking with HTTP wrapped protobufs. I'm not familiar with custom HTTP headers but is 'X-Libprocess-From' a way to optionally specify the libprocess id? If yes, that seems like a good option. Note that we can not completely get rid of the libprocess id in the protocol messages because most of our tests bring up an in-process mesos cluster, where different components (master, slave, etc) have same 'ip:port' but only differ in the 'id'. > And another quick question about communication - how does executor driver > knows the address (PID, host:port) of the slave? Slave sets an environment variable "MESOS_SLAVE_PID" before exec()ing an executor. See MesosExecutorDriver::start(). Cheers, Vinod > On Mon, Jan 13, 2014 at 10:59 AM, Vinod Kone <[email protected]> wrote: > > > On Sun, Jan 12, 2014 at 10:35 PM, Vetoshkin Nikita < > > [email protected]> wrote: > > > > > but to me it seems that > > > protocol is protobuf messages inside HTTP POST body. I just couldn't > find > > > yet where to does executor driver send them (UNIX socket? TCP?). > Wouldn't > > > simply documenting it be enough for a start? > > > > > > > Look for 'send()' calls inside exec.cpp. It is a libprocess method that > > sends messages to an end point. Similarly 'install<>()' is a libprocess > > method to receive messages. libprocess does use HTTP for > sending/receiving > > protobuf messages but it expects them to be in a certain format. > > Specifically it expects 'from' and 'to' fields in addition to the > protobuf > > message. 'from/to' correspond to libprocess endpoint (internally called > > PID) : <id>@ip:port. > > >
