[Unbound-users] Hack unbound to support concurrent processing for TCP

[Zi Hu]

Hi,

I am trying to hack unbound to support concurrent processing for queries
from the same TCP connection.

My understanding of the current Unbound code:
Current Unbound code uses a data struct "comm_point" for each TCP
connection.
Each "comm_point" corresponds to one TCP connection (to handle all queries
from that connection).  But each "comm_point" has only one buffer, which is
used to store query and response at different time.

Current Unbound code restricts the concurrent processing for TCP.  It reads
only one query from the TCP connection each time, after that, it stops
receiving queries until it sends back the response for the previously
received query.  In this way, all queries/responses are sequentialized, so
there won't be any conflict of using one buffer.

However, if we remove the restriction (let unbound keep reading queries
without blocking from the same TCP connection, so that it can process
queries concurrently), using only one buffer might cause problems.  For
example,  buffer in the "comm_point" might get overwritten if queries and
responses arrive at the same time.

I will really appreciate if someone can give me some hints about how to
hack this : to support concurrent processing for queries from the same TCP
connection.
Any ideas are welcomed.



----------------------------

I made a naive attempt, but failed.  Maybe someone can also comment on my
attempt:
a) comment out "if(c->type == comm_tcp) comm_point_stop_listening(c);"
and let "c->tcp_is_reading" always equal to 1 in the "tcp_callback_reader"
function, to make unbound keep receiving queries without blocking.
b) add "(repinfo->c)->tcp_is_reading = 0;" in the "comm_point_send_reply"
function, to schedule write event when response is coming back from
authoritative.

In this way, unbound does keep reading queries without blocking, and
queries get handled concurrently.  However, some of the queries never get
responses.  e.g. I only get 6~8 responses when I send 10 queries back to
back on the same connection.

I debugged the problem for a while, and confirmed that:
1) unbound receives all the queries from client on the same TCP connection.
2) unbound gets answers for all the queries (performed recursive process
for all queries).
3) unbound sets the write event for each response (with libevent).
problem: some of the write events are not executed which causes that some
responses are not returned to the client.
But I am not sure why some of the write events are not executed.

I understand that this attempt seems quite naive, and probably it is not
the right way. But I hope it could bring in discussions/suggestions about
how to do the hack.

Thanks in advance for your help.

Best Regards,
-Zi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20140224/7d8a3998/attachment.htm>