[ 
https://issues.apache.org/jira/browse/MESOS-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14162016#comment-14162016
 ] 

Niklas Quarfot Nielsen commented on MESOS-1330:
-----------------------------------------------

We have been designing the abstraction with both libev and libevent as event 
manager implementations proof-of-concepts, so more or less along the lines of 
what you are saying.

The reason we want to aim for an abstraction, is primarily and to start out 
with, to enable both encrypted and non-encrypted channels. Without an 
abstraction, this requires localized dispatches between - say ::recv() and 
SSL_read(), alongside adhering to the SSL API. We have tried that too and gets 
more complicated than it needs to be.

Joris have been designing a benchmark test and we will make sure that there are 
no performance regressions.

> Introduce connection/transport abstraction to libprocess
> --------------------------------------------------------
>
>                 Key: MESOS-1330
>                 URL: https://issues.apache.org/jira/browse/MESOS-1330
>             Project: Mesos
>          Issue Type: Improvement
>          Components: general, libprocess
>            Reporter: Niklas Quarfot Nielsen
>            Assignee: Joris Van Remoortere
>              Labels: libprocess, network
>
> I think it makes sense to think in terms of different low or middle layer 
> transports (which can accommodate channels like SSL). We could capture 
> connection life-cycles and network send/receive primitives in a much explicit 
> manner than currently in libprocess.
> I have a proof of concept transport / connection abstraction ready and which 
> we can use to iterate a design.
> Notably, there are opportunities to change the current SocketManager/Socket 
> abstractions to explicit ConnectionManager/Connection, which allow several 
> and composeable communication layers.
> I am proposing to own this ticket and am looking for a shepherd to 
> (thoroughly) go over design considerations before jumping into an actual 
> implementation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to