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
