Can you build this off of the latest master code? The reviews have been committed!
You should now use "Libprocess-From" instead of "User-Agent". E.g. Libprocess-From: scheduler@127.0.0.1:8080 Also, what is your "string" representation of the protobuf? You're serializing it using a protobuf library, right? It should be binary data. On Sun, May 4, 2014 at 7:57 AM, Vladimir Vivien <vladimir.viv...@gmail.com>wrote: > Slow progress from Go front: > I am at a point where I am testing this approach using Go. > > HTTP Sent: > POST /master/mesos.internal.RegisterFrameworkMessage HTTP/1.1 > Host: 127.0.0.1:5050 > User-Agent: libprocess/scheduler(1)@127.0.0.1:8080 > Content-Length: 34 > Connection: Keep-Alive > Content-Type: application/x-protobuf > Accept-Encoding: gzip > > String representation of protobuf sent: > user:"test" name:"gomes" id:<value:"gomes-framework-1" > > > Master console response > W0504 10:53:48.263000 3960 protobuf.hpp:399] Initialization errors: > framework.user, framework.name > > Before I delve in to CPP to see what's going on, hope someone can let me > know what I am doing wrong. > > PS. I havent applied the two patches mentioned here. > > vladimir.vivien > > > > On Wed, Apr 30, 2014 at 1:59 AM, Benjamin Mahler < > benjamin.mah...@gmail.com> wrote: > >> Brian, I'm curious whether most python HTTP libraries support using >> custom HTTP request headers. >> >> We'll land benh's patches to send 202 responses in 0.19.0: >> >> https://reviews.apache.org/r/20276/ >> https://reviews.apache.org/r/20277/ >> >> Once these get committed, you should be able to get something working >> nicely. This will allow libraries like "pesos" to use a custom header >> "Libprocess-From" to receive 202 responses for messages. >> >> We'd also like to get some more foundation laid for the lower-level API, >> I'll let benh comment on what else is needed here: >> >> https://reviews.apache.org/r/20309/ >> >> >> On Sun, Apr 27, 2014 at 9:23 PM, Vetoshkin Nikita < >> nikita.vetosh...@gmail.com> wrote: >> >>> That's great news indeed! >>> Maybe there should be a place on mesos site mentioning such efforts? >>> >>> >>> On Mon, Apr 28, 2014 at 5:24 AM, Brian Wickman <wick...@gmail.com> >>> wrote: >>> >>> > To my knowledge there is no Zookeeper Group implementation for Go yet. >>> > There do however appear to be Go zookeeper >>> > bindings<https://github.com/samuel/go-zookeeper>. >>> > From my day of spelunking through code, it seems that probably the >>> most >>> > challenging thing will be getting a ZookeeperMasterDetector >>> implementation >>> > working correctly to enable Scheduler "high availability" mode for >>> these >>> > other languages. >>> > >>> > Java/Python/C++ have the benefit of preexisting Group implementations >>> > (java< >>> > >>> https://github.com/twitter/commons/blob/master/src/java/com/twitter/common/zookeeper/Group.java >>> > > >>> > , python< >>> > >>> https://github.com/twitter/commons/blob/master/src/python/twitter/common/zookeeper/group/kazoo_group.py >>> > > >>> > , c++< >>> > >>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob;f=src/zookeeper/group.cpp;h=70972980dd25618c76eb36e0a31d060c096e36dc;hb=HEAD >>> > >) >>> > which are the foundation for ZK master detection. An intermediate >>> option >>> > could be to pull the ZookeeperMasterDetectorProcess out into a >>> standalone >>> > binary and have the native implementation talk to it as a sort of >>> proxy to >>> > figure out who the leading master is. But that's not nearly as >>> satisfying >>> > as a pure language implementation. >>> > >>> > ~brian >>> > >>> > >>> > On Sun, Apr 27, 2014 at 3:22 PM, Vladimir Vivien >>> > <vladimir.viv...@gmail.com>wrote: >>> > >>> > > It must be the right time for this. I started the same effort for >>> Go. >>> > > I am following Kevin's example and Ben's well-documented email (in >>> this >>> > > thread). >>> > > Very early but should have some proof-of-concept working soon. >>> > > >>> > > https://github.com/vladimirvivien/ionos >>> > > >>> > > >>> > > On Sun, Apr 27, 2014 at 6:07 PM, Tom Arnfeld <t...@duedil.com> wrote: >>> > > >>> > >> (Sorry to jump into this thread) >>> > >> >>> > >> I have to say, this is very exciting! It only became apparent to me >>> how >>> > >> painful it is having to compile the mesos egg into a Python >>> framework >>> > the >>> > >> past week >>> > >> while writing one, especially when running the framework on a >>> different >>> > >> architecture to the one running the executor! >>> > >> >>> > >> Looking forward to being able to use this. :-) >>> > >> >>> > >> It’d be awesome if the API was near identical, so one could switch >>> > >> between `mesos` and `pesos` easily… >>> > >> >>> > >> Tom. >>> > >> >>> > >> On 27 Apr 2014, at 22:42, Brian Wickman <wick...@gmail.com> wrote: >>> > >> >>> > >> > And I've started a skeleton implementation of the Mesos framework >>> API >>> > at >>> > >> > https://github.com/wickman/pesos >>> > >> > >>> > >> > While I vendored the translated protobuf, it would be great to >>> tackle >>> > >> > https://issues.apache.org/jira/browse/MESOS-857 at some point. >>> > >> > >>> > >> > >>> > >> > On Sun, Apr 27, 2014 at 12:50 PM, Brian Wickman < >>> wick...@gmail.com> >>> > >> wrote: >>> > >> > >>> > >> >> I've implemented a pure python version of the basic >>> > >> >> Process/ProtobufProcess mechanics and wire protocol. I haven't >>> gone >>> > >> so far >>> > >> >> as Kevin and tried to register a framework or maybe talk to a >>> > >> replicated >>> > >> >> log, but it shouldn't be much more work: >>> > >> >> >>> > >> >> https://github.com/wickman/compactor >>> > >> >> >>> > >> >> Zero documentation but you can read the tests for a general idea >>> of >>> > >> what's >>> > >> >> going on. >>> > >> >> >>> > >> >> cheers, >>> > >> >> brian >>> > >> >> >>> > >> >> >>> > >> >> >>> > >> >> On Sun, Apr 13, 2014 at 10:28 PM, Kevin Sweeney < >>> > >> kevin.t.swee...@gmail.com >>> > >> >>> wrote: >>> > >> >> >>> > >> >>> I've got the start of a JVM verson on github - it can currently >>> > >> register >>> > >> >>> a framework and parse the response. Client-side I still need to >>> > >> figure out >>> > >> >>> how to properly configure Keep-Alive. Servlet can dispatch >>> messages >>> > to >>> > >> >>> message handlers in a type-safe way and returns a 202 for >>> messages >>> > >> it's >>> > >> >>> going to handle. Code's a mess currently. >>> > >> >>> >>> > >> >>> https://github.com/kevints/mesos-framework-api >>> > >> >>> >>> > >> >>> >>> > >> >>> On Fri, Apr 11, 2014 at 7:12 PM, Benjamin Hindman < >>> > >> b...@eecs.berkeley.edu >>> > >> >>>> wrote: >>> > >> >>> >>> > >> >>>> First, my apologies for getting to this party so late. It's >>> great >>> > to >>> > >> see >>> > >> >>>> people interested in helping create native-language Mesos >>> > libraries. >>> > >> >>>> >>> > >> >>>> Vladimir: my presentation was definitely referring to the the >>> > >> low-level >>> > >> >>>> protocol between master, framework (scheduler), slave, and >>> > >> executors. I'll >>> > >> >>>> do my best here to clarify how the current protocol works and >>> what >>> > >> we need >>> > >> >>>> to do to get it to the point where we can write native-language >>> > >> libraries. >>> > >> >>>> (Eventually it would be great to move some of this into >>> > >> documentation as >>> > >> >>>> necessary.) >>> > >> >>>> >>> > >> >>>> As Nikita pointed out, the protocol is currently "HTTP-like". >>> As my >>> > >> >>>> presentation describes, think actors and one-way message >>> passing >>> > when >>> > >> >>>> considering how the protocol works. >>> > >> >>>> >>> > >> >>>> To send a message an actor POSTs an HTTP request where the >>> actor >>> > >> that is >>> > >> >>>> supposed to receive the message is the first component of the >>> > >> request path >>> > >> >>>> and the name of the message is the remaining part of the path. >>> To >>> > >> >>>> distinguish one of these "messages" from a normal HTTP request >>> we >>> > >> look to >>> > >> >>>> see if the 'User-Agent' is 'libprocess/...'. For example: >>> > >> >>>> >>> > >> >>>> POST /master/mesos.internal.RegisterFrameworkMessage HTTP/1.1 >>> > >> >>>> User-Agent: libprocess/scheduler(1)@10.0.1.7:53523 >>> > >> >>>> >>> > >> >>>> ... represents a message with the name >>> > >> >>>> 'mesos.internal.RegisterFrameworkMessage' destined for the >>> actor >>> > >> 'master' >>> > >> >>>> coming from the actor 'scheduler(1)' at 10.0.1.7:53523. If the >>> > >> 'master' >>> > >> >>>> actor were to send a message back it would look something like >>> > this: >>> > >> >>>> >>> > >> >>>> POST /scheduler(1)/mesos.internal.FrameworkRegisteredMessage >>> > HTTP/1.1 >>> > >> >>>> User-Agent: libprocess/master@10.0.1.7:5050 >>> > >> >>>> >>> > >> >>>> So, one-way message passing via HTTP POST. >>> > >> >>>> >>> > >> >>>> The message data is captured as the body of the HTTP request >>> (which >>> > >> can >>> > >> >>>> be specified using _either_ Content-Length or a >>> Transfer-Encoding, >>> > >> and as >>> > >> >>>> Nikita points out we use chunked transfer encoding >>> internally). The >>> > >> data is >>> > >> >>>> arbitrary and the actor ultimately decides how it wants to >>> "parse" >>> > >> it. In >>> > >> >>>> Mesos, 99% of our messages use serialized protobufs, but we >>> also >>> > >> send a few >>> > >> >>>> messages with just arbitrary data. All this really means is >>> that >>> > >> knowing >>> > >> >>>> the actor and message name is not enough, you also need to know >>> > what >>> > >> the >>> > >> >>>> body type is supposed to be for that message. In the future >>> we'll >>> > >> probably >>> > >> >>>> enable messages with either JSON or serialized protobuf[1] ... >>> for >>> > >> now, >>> > >> >>>> just serialized protobuf. >>> > >> >>>> >>> > >> >>>> Okay, so where does this break down when trying to do this >>> > >> >>>> language-natively? I've had some of this in the works and this >>> > >> conversation >>> > >> >>>> has motivated me to publish some reviews addressing the issues: >>> > >> >>>> >>> > >> >>>> (1) We'll need to return a response if one plans to use a >>> native >>> > HTTP >>> > >> >>>> library since it'll expect request/response. >>> > >> >>>> https://reviews.apache.org/r/20276 introduces responding with >>> a >>> > '202 >>> > >> >>>> Accepted' for these messages (from the HTTP specification, a >>> '202 >>> > >> >>>> Accepted': "The request has been accepted for processing, but >>> the >>> > >> >>>> processing has not been completed. The request might or might >>> not >>> > >> >>>> eventually be acted upon, as it might be disallowed when >>> processing >>> > >> >>>> actually takes place. There is no facility for re-sending a >>> status >>> > >> code >>> > >> >>>> from an asynchronous operation such as this."). >>> > >> >>>> >>> > >> >>>> (2) Most HTTP libraries will set their 'User-Agent' >>> themselves, so >>> > >> >>>> https://reviews.apache.org/r/20277 introduces a >>> 'libprocess-from' >>> > >> >>>> header that works similar to User-Agent. There is still some >>> > cleanup >>> > >> I'd >>> > >> >>>> love to do around stringification of PIDs (the underlying type >>> > Mesos >>> > >> uses >>> > >> >>>> for remote actors, inspired by Erlang). Until then, the >>> > >> 'libprocess-from' >>> > >> >>>> string is unfortunately esoteric (see the test). >>> > >> >>>> >>> > >> >>>> The combination of these two patches should make sending and >>> > >> receiving >>> > >> >>>> messages straightforward. However, we still plan to expose the >>> > >> low-level >>> > >> >>>> Event and Call protobuf messages and that will be the preferred >>> > >> approach >>> > >> >>>> for building a native-language library. Follow along at >>> > >> >>>> https://issues.apache.org/jira/browse/MESOS-1127 for more >>> details. >>> > >> (To >>> > >> >>>> be clear, you'd still be able to implement native-language >>> > libraries >>> > >> with >>> > >> >>>> the patches above but we'll be deprecating the protobufs you'd >>> be >>> > >> using in >>> > >> >>>> favor of Event and Call protobufs instead. If you're eager to >>> get >>> > >> that >>> > >> >>>> going before Event and Call are committed I'm happy to discuss >>> the >>> > >> existing >>> > >> >>>> protobufs in more detail.) >>> > >> >>>> >>> > >> >>>> I hope this helps. >>> > >> >>>> >>> > >> >>>> Ben. >>> > >> >>>> >>> > >> >>>> >>> > >> >>>> On Fri, Apr 11, 2014 at 4:54 AM, Vladimir Vivien < >>> > >> >>>> vladimir.viv...@gmail.com> wrote: >>> > >> >>>> >>> > >> >>>>> Nikita >>> > >> >>>>> Thanks for the JIRA. >>> > >> >>>>> >>> > >> >>>>> >>> > >> >>>>> On Wed, Apr 9, 2014 at 2:16 PM, Vetoshkin Nikita < >>> > >> >>>>> nikita.vetosh...@gmail.com >>> > >> >>>>>> wrote: >>> > >> >>>>> >>> > >> >>>>>> BTW, there is also somehow related ticket >>> > >> >>>>>> https://issues.apache.org/jira/browse/MESOS-930 >>> > >> >>>>>> >>> > >> >>>>>> >>> > >> >>>>>> On Wed, Apr 9, 2014 at 9:54 PM, Benjamin Mahler >>> > >> >>>>>> <benjamin.mah...@gmail.com>wrote: >>> > >> >>>>>> >>> > >> >>>>>>>> >>> > >> >>>>>>>> I thought the low-level api being referred in the >>> > >> >>>>>>>> video had to do with communication between master and >>> > >> >>>>>> framework|executor >>> > >> >>>>>>>> for scheduling. But, it's really administrative. I >>> thought >>> > that >>> > >> >>>>> would >>> > >> >>>>>>>> have been an opportunity for a Go binding that did not >>> require >>> > >> >>>>> the C++ >>> > >> >>>>>>>> libraries. >>> > >> >>>>>>>> >>> > >> >>>>>>> >>> > >> >>>>>>> Vladimir, the low-level API referred to in the talk is >>> exactly >>> > >> what >>> > >> >>>>>> you're >>> > >> >>>>>>> interpreting, it is for communication between master and >>> > >> scheduler, >>> > >> >>>>> and >>> > >> >>>>>>> slave and executor. You could definitely build pure go >>> bindings >>> > as >>> > >> >>>>> you >>> > >> >>>>>>> described, just not with JSON. >>> > >> >>>>>>> >>> > >> >>>>>>> Forget I mentioned anything about the administrative >>> endpoints >>> > and >>> > >> >>>>> JSON, >>> > >> >>>>>> as >>> > >> >>>>>>> I see that's leading to confusion. ;) >>> > >> >>>>>>> >>> > >> >>>>>>> On Wed, Apr 9, 2014 at 3:39 AM, Vladimir Vivien >>> > >> >>>>>>> <vladimir.viv...@gmail.com>wrote: >>> > >> >>>>>>> >>> > >> >>>>>>>> Ben, >>> > >> >>>>>>>> Thank you for clarifying. I thought the low-level api being >>> > >> >>>>> referred in >>> > >> >>>>>>> the >>> > >> >>>>>>>> video had to do with communication between master and >>> > >> >>>>>> framework|executor >>> > >> >>>>>>>> for scheduling. But, it's really administrative. I >>> thought >>> > that >>> > >> >>>>> would >>> > >> >>>>>>>> have been an opportunity for a Go binding that did not >>> require >>> > >> >>>>> the C++ >>> > >> >>>>>>>> libraries. >>> > >> >>>>>>>> >>> > >> >>>>>>>> Thanks anyway. >>> > >> >>>>>>>> >>> > >> >>>>>>>> >>> > >> >>>>>>>> >>> > >> >>>>>>>> >>> > >> >>>>>>>> >>> > >> >>>>>>>> >>> > >> >>>>>>>> On Tue, Apr 8, 2014 at 4:52 PM, Benjamin Mahler >>> > >> >>>>>>>> <benjamin.mah...@gmail.com>wrote: >>> > >> >>>>>>>> >>> > >> >>>>>>>>> Sorry, I was not referring to implementing a scheduler via >>> > JSON >>> > >> >>>>>> instead >>> > >> >>>>>>>> of >>> > >> >>>>>>>>> protobuf, in theory that would be possible but there has >>> been >>> > no >>> > >> >>>>>>> planning >>> > >> >>>>>>>>> in this area. Sorry for the confusion. >>> > >> >>>>>>>>> >>> > >> >>>>>>>>> I was referring to administrative endpoints. For example, >>> > >> >>>>> kicking a >>> > >> >>>>>>>>> framework out or telling the master a slave is needs to be >>> > >> >>>>> repaired. >>> > >> >>>>>>>> These >>> > >> >>>>>>>>> endpoints may rely on the ability to convert JSON to >>> internal >>> > >> >>>>>>> protobufs. >>> > >> >>>>>>>>> >>> > >> >>>>>>>>> Can you clarify what you're looking to do? Are you >>> looking to >>> > >> >>>>>> implement >>> > >> >>>>>>>> an >>> > >> >>>>>>>>> API in Go that communicates with JSON instead of >>> serialized >>> > >> >>>>> protobuf? >>> > >> >>>>>>>>> >>> > >> >>>>>>>>> On Tue, Apr 8, 2014 at 1:19 PM, Vladimir Vivien >>> > >> >>>>>>>>> <vladimir.viv...@gmail.com>wrote: >>> > >> >>>>>>>>> >>> > >> >>>>>>>>>> Ben, >>> > >> >>>>>>>>>> That is exactly what I am asking. >>> > >> >>>>>>>>>> Is that something coming up soon, is there a JIRA I can >>> look >>> > >> >>>>> at? >>> > >> >>>>>>>>>> I wanna get early start on a native json Go api or even >>> help >>> > >> >>>>> out if >>> > >> >>>>>>>>>> possible. >>> > >> >>>>>>>>>> >>> > >> >>>>>>>>>> >>> > >> >>>>>>>>>> On Tue, Apr 8, 2014 at 3:25 PM, Benjamin Mahler >>> > >> >>>>>>>>>> <benjamin.mah...@gmail.com>wrote: >>> > >> >>>>>>>>>> >>> > >> >>>>>>>>>>> +vinod, benh >>> > >> >>>>>>>>>>> >>> > >> >>>>>>>>>>> Hey Vladimir, there will be some authenticated REST >>> > >> >>>>> endpoints at >>> > >> >>>>>>> some >>> > >> >>>>>>>>>>> point, there is some work in this area underway. >>> > >> >>>>>>>>>>> >>> > >> >>>>>>>>>>> We have the ability to encode protobuf messages as >>> JSON, so >>> > >> >>>>> the >>> > >> >>>>>>> plan >>> > >> >>>>>>>>> was >>> > >> >>>>>>>>>> to >>> > >> >>>>>>>>>>> have any REST endpoints directly use JSON to send us >>> > >> >>>>> protobuf >>> > >> >>>>>>>> messages. >>> > >> >>>>>>>>>> I'm >>> > >> >>>>>>>>>>> not sure if this is what you're asking though? >>> > >> >>>>>>>>>>> >>> > >> >>>>>>>>>>> >>> > >> >>>>>>>>>>> On Tue, Apr 8, 2014 at 11:13 AM, Vetoshkin Nikita < >>> > >> >>>>>>>>>>> nikita.vetosh...@gmail.com> wrote: >>> > >> >>>>>>>>>>> >>> > >> >>>>>>>>>>>> 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=n5GT7OFSh58fromBen >>> > >> >>>>>>> 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 >>> > >> >>>>>>>>>>>>> >>> > >> >>>>>>>>>>>> >>> > >> >>>>>>>>>>> >>> > >> >>>>>>>>>> >>> > >> >>>>>>>>>> >>> > >> >>>>>>>>>> >>> > >> >>>>>>>>>> -- >>> > >> >>>>>>>>>> Vladimir Vivien >>> > >> >>>>>>>>>> >>> > >> >>>>>>>>> >>> > >> >>>>>>>> >>> > >> >>>>>>>> >>> > >> >>>>>>>> >>> > >> >>>>>>>> -- >>> > >> >>>>>>>> Vladimir Vivien >>> > >> >>>>>>>> >>> > >> >>>>>>> >>> > >> >>>>>> >>> > >> >>>>> >>> > >> >>>>> >>> > >> >>>>> >>> > >> >>>>> -- >>> > >> >>>>> Vladimir Vivien >>> > >> >>>>> >>> > >> >>>> >>> > >> >>>> >>> > >> >>> >>> > >> >> >>> > >> >>> > >> >>> > > >>> > > >>> > > -- >>> > > Vladimir Vivien >>> > > >>> > >>> >> >> > > > -- > Vladimir Vivien >