[bind10-dev] Crazy idea to eliminate asynchronousness

Michal 'vorner' Vaner michal.vaner at nic.cz
Fri Dec 16 19:48:05 UTC 2011


Hello

I noticed we have quite a lot of of asynchronous code, even in places where we
wouldn't really need to. I guess we won't be able to do the resolver without a
lot of asynchronous code, and whatever part will be talking over many sockets
over the network will need that too. But most of our processing and daemons are
sequential by nature.

And the asynchronous code is needlessly more complicated, and if examined for a
while, we always find a bug or two.

So, I was thinking how to get rid of it and came up with a crazy idea.

Imagine we have a receptionist that does all the communication. It handles
reads, it handles partial writes when the buffers are full, etc. So nothing else
really needs to worry about it. It would just connect to it somehow, and have a
loop:
 • Read a request from the receptionist, blocking mode (if nothing comes,
   nothing was sent and we have nothing better to do anyway, as the receptionist
   is our only source of work).
 • Think how to answer it
 • Send the response to the receptionist, blocking mode (it'll read right away
   anyway and do the buffered sending).

Also notice this communication does not send any sockets around. It doesn't
bother the one who does the answering with details like UDP vs TCP, V4 vs V6,
etc.

But I noticed a problem. Nobody would be reading the command channel. However,
if the requests for data were coming over the command channel itself, it would
work. We would just read the commands and one of the possible command would be
„Answer this packet“. This would be too slow over the current msgq, but it maybe
could be fast over dbus.

In such case, auth and ddns could be completely synchronous. Xfr-in is different
as it initializes the connection itself. The use of threads there seems quite
natural there as well, because we limit the number of transfers. The Xfr-out has
a small problem. It could need to send a Very Large Response (TM), which
wouldn't fit into the memory (we could send multiple prepared messages over the
buss, but it would need to be kept in a buffer in the receptionist, which is bad
in case of AXFR of multi-gigabyte zone). So, Xfr-out could signal an „incomplete
response“ (in case it would create more than, let's say, 10 messages, which is a
lot in case of IXFR, it would add a flag „there's more“). The receptionist
wouldn't use this instance of Xfr-out to answer more data now, as this one would
be concentrating on this, and once it would have place for more messages in the
buffer, it would ask for more, until it got to the end.

The resolver would need to work in asynchronous way anyway.


However, I'm not sure about this idea. It may be too daring. It brings several
advantages, like being able to transfer the packets already parsed over the dbus
and separating the communication from the logic, having multiple auths for free,
etc. It would also allow for some nice clustering options (like having some
„listening“ machines with receptionists and some answering machines with
databases). But it doesn't sound like completely trivial change. I'm not sure
about the performance either, how fast it is to transfer the packets over the
message bus.

Do you think it would be interesting to talk this over some time?

Thank you

With regard

-- 
Anyone who goes to a psychiatrist ought to have his head examined.
		-- Samuel Goldwyn

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20111216/4b8573c0/attachment.bin>


More information about the bind10-dev mailing list