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