Re: [boost] [asio] RFC on new reliable UDP library

Subject: Re: [boost] [asio] RFC on new reliable UDP library
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-09-10 11:20:58

On 9 Sep 2014 at 15:03, Rodrigo Madera wrote:

> Looks very interesting and I would love to see that lib happen.
> 
> I believe in building up on knowledge recursively. So the first thing I
> would do is read on the enormous effort ZeroMQ [1] has put into analysing
> this problem domain. They have a (very) large set of material debating and
> explaining design decisions made on the library. After that, there is
> nanomsg [2], which is a derivative work from the lessons learned from
> ZeroMQ itself. Have you read through those in search of insights? It would
> be a very good source of debate material for this brand new library. There
> are problems they have encountered already, though you may decide to solve
> them differently.

Yes, we did. And therein lies the debate: ASIO's design was a product 
of its time, and while its design was close to optimal for its time, 
it now makes life harder than it should be in a world with 40Gbit 
ethernet, mobile devices where power consumption is important, and 
where non-Linux operating system kernels can DMA straight to and from 
user space if and only if you are very careful with how you use ASIO.

The debate lies in to what extent does one break with ASIO's 
established norms and practices to achieve the features I listed. 
Even deciding on how much C++ 14 to use, or how much to embrace C++ 
17 resumable functions is controversial.

> Of course, that is if you haven't read that already. It just reminded me of
> how many insights these guys had in all the years they spent using and
> creating network middleware code. And basing a new network library off of
> this knowledge could be good.

I would strongly emphasise that no one is proposing we try doing 
ZeroMQ or anything like it "better". In our reliable messaging 
library we would provide the absolute minimum abstraction with which 
one could build *any* reliable messaging solution of their choice. 
The contract does involve the replication of at least one reliable 
UDP implementation (actually one of Chris' early implementations) as 
the original has heavily bitrotted, but apart from that we were 
thinking of UDT as a second backend, and leaving it at that. We chose 
UDT mainly because we believe we can reuse some of it for duplicating 
Chris' RUDP implementation.

> About the language, I would totally look forward into C++11 and up design.

Be aware that C++ 11, and especially C++ 17 as it currently is 
thought to become, consider future-promise as the sole way for i/o 
completion handlers to be invoked via the new 
future<T>.then(callable) function. In particular, 17's resumable 
function support *requires* that the function must return a future, 
so if you want language based coroutine support, you must use 
future<T>.

As much as Chris and many ASIO users are opposed to that design 
choice, we must play with the hand we have been dealt by WG21. I will 
say that future-promise can be made constexpr and no-alloc, and that 
makes an awful lot of the inefficiency go away, though an implicit 
synchronisation is unavoidable as .then() must check if the operation 
has already completed.

On 9 Sep 2014 at 21:31, Andrew Marlow wrote:

> Is it going to include reliable multicast? If so then a good place to
> start is the RFCs and various attempts at reliable multicast in the past.
> The two that spring to mind are NORM (
> http://downloads.pf.itd.nrl.navy.mil/docs/norm/NormDeveloperGuide.html)
> for which there is a reference implementation, and PGM (Pragmatic General
> Multicast, http://tools.ietf.org/html/rfc3208). Don't forget Scalable
> Reliable Multicast, SRM,
> http://en.wikipedia.org/wiki/Scalable_Reliable_Multicast. There are
> whole frameworks based just on reliable multicast, e.g. spread,
> http://www.spread.org. Personally, I think this is far too big an area
> for boost. $0.02. 

We are very much thinking of an abstraction framework with which one 
could implement things like the above. The hope would be that our new 
library would take care of platform-specific hassle like making whole 
system zero-copy networking right to and from the NIC disappear, 
stuff like that.

We are also considering a monadic continuations framework allowing 
code just above ASIO to use ASIO generically. In other words, the 
standard C++ i/o monad equals ASIO. This ought to very significantly 
ease the writing of highly generic code avoiding much of the 
boilerplate you often need to join up ASIO async handlers, and 
therefore should make much easier implementing ZeroMQ or reliable 
multicast or any other messaging protocol.

Another debate is indeed where the bottom level wire protocol should 
end and the monadic high level part should begin. For example some 
feel this approach would make impossible the reuse of third party 
implementation libraries.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/