regarding reliability: obviously TCP provides a point to point guarantee... however there is no application level (ISO model) guarantee that the message was received or processed. A loss of slave or executor at the wrong time would result in no processing of the message without the senders awareness. There is a guarantee of status messages but not framework messages. It is a an application equivalent of UDP at the protocol level.
ken > On Jan 5, 2016, at 9:34 AM, sujz <[email protected]> wrote: > > Hi, all: > > I am using mesos-0.22.0, I noticed that FrameworkToExecutorMessage is sent > along path: > Scheduler->Master->Slave->Executor, > while ExecutorToFrameworkMessage is sent along path: > Executor->Slave->Scheduler, > > So is there some reason or benefit for bypassing master while transmitting > ExecutorToFrameworkMessage? > > One more question, FrameworkToExecutorMessage and ExecutorToFrameworkMessage > are instantiated in function SendFrameworkMessage, declaration of > SendFrameworkMessage in include/mesos/scheduler.hpp and > include/mesos/executor.hpp: > // Sends a message from the framework to one of its executors. These > // messages are best effort; do not expect a framework message to be > // retransmitted in any reliable fashion. > virtual Status sendFrameworkMessage( > const ExecutorID& executorId, > const SlaveID& slaveId, > const std::string& data) = 0; > > I guess that protobuf message are transmitted with TCP, so does this comment > mean I have to guarantee reliability by myself even with TCP? What's special > for these > two messages compared with other protobuf messages, If no, do we have to > guarantee reliability all by ourselves? > > Thank you very much and best regards ! > > >
