Re: [B.A.T.M.A.N.] [RFC v2] alfred: implement TCP support for server-to-server communication

[Hans-Werner Hilse <hwhilse@gmail.com>]

Hi,

Am 2016-03-27 20:26, schrieb Hans-Werner Hilse:
> [...]
> Changes in v2:
>    - non-blocking sending over TCP sockets

This uses non-blocking IO also for sending via TCP.
TCP is chosen when the message size exceeds MAX_UDP_ANSWER (from 
alfred.h), which is for now conservatively chosen to fit in bad-case MTU 
settings - or if the data request came via TCP (as the same connection 
is then used for the reply).

I've run this for a few hours in a test setup with 3x alfred as master 
and 30 slaves, with some errors, dups and latency thrown in for good 
measure (yay for VDE, virtual distributed ethernet).

The current implementation has a downside: non-blocking TCP sending for 
now assembles the full data that is to be sent in a memory buffer, which 
will then get sent bit by bit (depending on buffers, network and the 
remote side). This is a consequence of the lack of a good way to 
guarantee a consistent state of the data store over the time it takes 
until the full message stream is completely transmitted to the remote 
end (the data store might get modified between beginning and finishing 
transmission).

An alternative approach - and a major redesign of data storage - would 
be some kind of log-based approach. I'm not so sure if that really is 
warranted for, and in any case, that's quite a different undertaking.

The flag "-t" is still present and will toggle whether alfred will try 
to request using TCP at all. This will allow to use a TCP-enabled alfred 
in an environment that is not yet fully TCP enabled (this matters only 
for the master servers AFAICS).

-hwh