I'm not a mesos guy, just very curious. But in my opinion - I doubt it, HTTP is synchronous request-response protocol. Mesos needs something more robust for message passing. Websockets anyone? :)
On Tue, Apr 8, 2014 at 10:08 PM, Vladimir Vivien <vladimir.viv...@gmail.com>wrote: > Ben / Nikita > Thanks for the pointers. > So, (without digging yet) is it a fair summary to say that libprocess wraps > protobufs-encoded calls and push them over HTTP to master/slaves ? Will > protobuf (eventually) be supplanted by direct HTTP via REST or similar ? > > > On Mon, Apr 7, 2014 at 2:54 PM, Vetoshkin Nikita < > nikita.vetosh...@gmail.com > > wrote: > > > Or, just to get to know - you can take tcpdump and take a look :) > > > > I personally wouldn't call that HTTP. Something "HTTP-like" would > describe > > it better. Because it's not request-response. It's just message passing, > no > > need to wait for the answer - send new message one after another. Every > > message is POST with address and message type encoded in URI: POST > > /executor(1)/mesos.internal.RunTaskMessage. Sender is encoded in > User-Agent > > header, e.g: libprocess/slave(1)@127.0.0.1:5051. Body contains protobuf > > message, Transfer-Encoding is always "chunked". > > > > > > On Mon, Apr 7, 2014 at 10:42 PM, Benjamin Mahler > > <benjamin.mah...@gmail.com>wrote: > > > > > Unfortunately you will need to learn this by looking at the code in > > > libprocess, as the message passing format is not explicitly documented > at > > > the current time. > > > > > > Start with calls like ProtobufProcess::send() and dig your way down. > > > > > > > > > On Sat, Apr 5, 2014 at 7:52 AM, Vladimir Vivien > > > <vladimir.viv...@gmail.com>wrote: > > > > > > > I was watching this video from > > > > https://www.youtube.com/watch?v=n5GT7OFSh58from Ben where he talked > > > > about the wire protocol for Mesos being done in > > > > HTTP. > > > > > > > > Where can I learn about the low-level wire protocol either in > > > documentation > > > > or browsing through the code. > > > > > > > > Thanks. > > > > > > > > -- > > > > Vladimir Vivien > > > > > > > > > > > > > -- > Vladimir Vivien >
