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
>

Reply via email to