[
https://issues.apache.org/jira/browse/MESOS-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14177608#comment-14177608
]
Niklas Quarfot Nielsen commented on MESOS-1330:
-----------------------------------------------
The general idea is to propose a stream api (and revised clock api) instead of
a full event manager abstraction.
We did a proof of concept event manager api which abstracted both libev and
libevent implementations in libprocess and noticed that the resulting api
captured three things:
- Asynchronous clock ticks
- Network/Connection establishment, Async I/O
- File Async I/O
(Marked with red in the figure below).
!http://cl.ly/image/1y3o0G1T3S3p/libprocess.png!
Instead of having a 20+ method abstraction, introducing them as individual
concepts seemed more elegant and robust.
The networking abstraction fit well in terms of extending the capabilities of
the already existing Socket abstraction.
Here is a suggestion on how that could look like:
{code}
class Socket {
// // The connect/send sequence is implemented by
// Socket s = SocketManager::connect(Node("example.com", 5050))
//
// // The write operation will be enqueued on the connect future and writable.
// s.write(msg);
//
// // Or generalized:
// s.connected().then([=]{
// // s.read()
// // s.write()
// // ...
// });
Future<Nothing> connected();
Future<Nothing> accepted();
// Is backed by io::poll(), but doesn't rely on being implemented that way.
// Buffered IO (as with SSL) won't behave as you expect with poll().
Future<Nothing> readable();
// Same here.
Future<Nothing> writable();
// Along with persist(), this supports remote 'exited' notifications.
Future<Nothing> closed();
// Stream will keep it self alive (by increasing the ref-count).
Future<Nothing> persist();
// Reads will automatically hang of the readable() future.
Future<std::string> read();
// ... all the read variants.
Future<size_t> write(std::string);
// ... all the write variants.
}
{code}
We wanted to introduce the notion of streams, as networking and file I/O almost
ended up being copies of one another. Besides the connection life-cycle, we
should be able to share implementations of those.
> Introduce stream abstraction to libprocess
> ------------------------------------------
>
> Key: MESOS-1330
> URL: https://issues.apache.org/jira/browse/MESOS-1330
> Project: Mesos
> Issue Type: Task
> 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)
