There are a few items in my mind that could be fixed. 1) There is a massive complex build knot of depends in this code. Changing it would clean this up 2) The current code is still hard to follow. the YAML change would make it easier to understand, follow and maintain 3) independent of the "protocol" used. Not using Domain sockets (that have a limit on path length) would improve the testability of the code and make it simpler to run
Number 1) I think is the most important issue to correct. The YAML idea would only make it easier to do this. It is not required. But easier is better than harder Jason On Fri, Aug 17, 2018 at 11:10 AM Leif Hedstrom <zw...@apache.org> wrote: > Then what is the motivation to change anything? Let’s just keep the > serialization the same as what we have, Peach cleaned that up noticeably. > > The issue with bidirectional communication gets solved as part of the > elimination of traffic_manager. > > — Leif > > > On Aug 16, 2018, at 17:40, Alan Carroll <solidwallofc...@oath.com.INVALID> > wrote: > > > > Yeah, it's not like we have any expertise in asynchronous I/O on IPC > > sockets, that would let us leverage someone else's YAML based > serialization > > / deserialization library. We should definitely go with something that > has > > its own I/O mechanisms (which are sure to be compatible!) and quite > > possibly its own threading model too. That'll be *easy*! And I can't wait > > to play with all the super cool features and adjustable knobs such a > thing > > will have. > > > >> On Thu, Aug 16, 2018 at 6:17 PM Leif Hedstrom <zw...@apache.org> wrote: > >> > >> I think rolling our own defeats the purpose of replacing what we have. > We > >> should pick something where there is a large sets of client libraries > >> already. As you say, performance is not critical, so pick one that is > >> popular. I think gRPC would be fine too. > >> > >> — Leif > >> > >>> On Aug 16, 2018, at 11:59, Derek Dagit <der...@oath.com.INVALID> > wrote: > >>> > >>> I was not at Cork, so I am probably missing a lot of the details. > >>> > >>> It seems having true RPC here would greatly expand the possibilities > for > >>> management and monitoring. > >>> > >>> > >>> - What are the current and planned use cases for this RPC? > >>> > >>> - What if we want to add authentication/authorization for multi-tenant > >>> management and isolation? > >>> > >>> - What about security issues and the ongoing cost of maintaining a > unique > >>> RPC solution, versus using something already battle-tested? > >>> > >>> - Didn't we try this once already? [0] > >>> > >>> > >>> (I figure there are good answers to all of these questions, and so I am > >>> mostly asking for the benefit of those of us not familiar with the past > >>> discussions.) > >>> > >>> [0] > >> > https://github.com/apache/trafficserver/pull/3504#issuecomment-389927441 > >>> > >>> > >>> > >>> What are the current and planned use cases for this RPC? > >>> > >>> On Thu, Aug 16, 2018 at 2:39 PM, Alan M. Carroll < > >>> a...@network-geographics.com> wrote: > >>> > >>>> I've been looking at how to do the RPC replacement that was agreed on > at > >>>> Cork. After looking at grpc, Avro, and Thrift, I don't like any of > them > >> for > >>>> our use case. I've moved to the camp that says we should build our own > >> thin > >>>> wrapper around YAML messages, very similar to a REST style API. We do > >> not > >>>> need high performance for this case, the message rate is generally > less > >>>> than one per second and the messages are not large. Previously going > >> YAML > >>>> would have been a major effort but since we've already paid that price > >> in > >>>> the ongoing configuration conversion, building an RPC on top of > YAMLCPP > >>>> seems quite easy. In this scheme the data is sent via YAML map > >> instances. > >>>> In each map, the top level keys are the messages, each key being a tag > >> that > >>>> identifies the message handler. The handler is given the map entry, > key > >> and > >>>> value, and processes it. If parallelism is needed, the handlers can > >> attach > >>>> an "sequence" field inside the map value to match requests to > responses. > >>>> > >>>> The RPC driver is simple. It has a hash of tags to > >> handlers/continuations. > >>>> It accumulates data from the socket until it gets a successful YAML > >> parse. > >>>> Then it walks the top level keys, dispatching an event for each one to > >> the > >>>> handler associated with the tag. Sending is done handing a YAML map > >> object > >>>> to the RPC, which puts it in a queue to be written by a blocking write > >>>> thread. My view is this would be less work than integrating a full > >> featured > >>>> RPC with many features we don't need. > >>>> > >>>> > >>> > >>> > >>> -- > >>> Derek > >> > >> > > > > -- > > *Beware the fisherman who's casting out his line in to a dried up > riverbed.* > > *Oh don't try to tell him 'cause he won't believe. Throw some bread to > the > > ducks instead.* > > *It's easier that way. *- Genesis : Duke : VI 25-28 > >
