From: Konstantin Osipov <kostja@tarantool.org> To: tarantool-patches@freelists.org Cc: vdavydov.dev@gmail.com Subject: Re: [tarantool-patches] [PATCH v3 1/6] [RAW] swim: introduce SWIM's anti-entropy component Date: Wed, 9 Jan 2019 12:12:11 +0300 [thread overview] Message-ID: <20190109091211.GC20509@chai> (raw) In-Reply-To: <68930a7f6647aaa3f161223470e33a52012a3569.1546077015.git.v.shpilevoy@tarantool.org> * Vladislav Shpilevoy <v.shpilevoy@tarantool.org> [18/12/29 15:07]: > +enum { > + /** How often to send membership messages and pings. */ .. in seconds (please add these two words to the comment). > + HEARTBEAT_RATE_DEFAULT = 1, > +}; > + \ is / modulO > + * Take a random number not blindly calculating a module, but It took me some time to wrap my head around this sentence before I cracked what's a module. boundaries to preserve the original > + * scaling random number down the given borders to save > + * distribution. A result belongs the range [start, end]. The result belongs to the range > + */ > +static inline int > +swim_scaled_rand(int start, int end) > +{ > + assert(end > start); > + return rand() / (RAND_MAX / (end - start + 1) + 1); > +} > + > + * Global hash of all known members of the cluster. Hash > + * key is bitwise combination of ip and port What's a bitwise combination? I see later that you shift the IP address and concatenate it with the port value. It would be a concatenation then. Why not simply run the entire sockarddr_in through murmur, this would be portable across transports and reliably random? The good old days of the trick you used in sockaddr_in_hash are bygone IMHO. You can easily remember the hash value in swim_member struct, so that all hash table lookups are easy. > + * struct member, describing a remote instance. The only > + * purpose of such strange hash function is to be able to > + * reuse mh_i64ptr_t instead of introducing one more > + * implementation of mhash. > + * > + * Discovered members live here until they are > + * unavailable - in such a case they are removed from the > + * hash. But a subset of members are pinned - the ones > + * added explicitly via API. When a member is pinned, it > + * can not be removed from the hash, and the module will > + * ping him constantly. Great comments btw, makes the whole thing easy to understand. I will stop by your desk to fix a couple of grammar issues I found. > +static inline uint64_t > +sockaddr_in_hash(const struct sockaddr_in *a) > +{ > + return ((uint64_t) a->sin_addr.s_addr << 16) | a->sin_port; > +} See my comment re hash function. > +struct PACKED swim_member_bin { > + /** mp_encode_map(3) */ > + uint8_t m_header; > + > + /** mp_encode_uint(SWIM_MEMBER_STATUS) */ > + uint8_t k_status; > + /** mp_encode_uint(enum member_status) */ > + uint8_t v_status; > + > + /** mp_encode_uint(SWIM_MEMBER_ADDRESS) */ > + uint8_t k_addr; > + /** mp_encode_uint(addr.sin_addr.s_addr) */ > + uint8_t m_addr; > + uint32_t v_addr; > + > + /** mp_encode_uint(SWIM_MEMBER_PORT) */ > + uint8_t k_port; > + /** mp_encode_uint(addr.sin_port) */ > + uint8_t m_port; > + uint16_t v_port; > +}; Please create a patch for the docs extending the binary protocol with these new messages. I would also ponder a bit more about extending iproto_constants.h with swim command codes in case we ever want to transport them over iproto. > + * SWIM_ANTI_ENTROPY: [ > + * { > + * SWIM_MEMBER_STATUS: uint, enum member_status, > + * SWIM_MEMBER_ADDRESS: uint, ip, > + * SWIM_MEMBER_PORT: uint, port > + * }, Is this going to work only over ip network? Why not use server uuids as member identifiers? > + for (mh_int_t node = mh_first(members), end = mh_end(members); > + node != end; node = mh_next(members, node), ++i) { > + shuffled[i] = (struct swim_member *) > + mh_i64ptr_node(members, node)->val; > + int j = swim_scaled_rand(0, i); > + SWAP(shuffled[i], shuffled[j]); > + } Please add a comment that this method preserves even distribution of a random sequence, ideally explaining why, or at least mentioning that we tested it. > +/** > + * Encode anti-entropy header and members data as many as > + * possible to the end of a last packet. > + * @retval -1 Error. > + * @retval 0 Not error, but nothing is encoded. > + * @retval 1 Something is encoded. > + */ I would appreciate a bit more lengthy comment about your chunking strategy when pushing this data over UDP. Do you prepare all chunks and then send them? Do you fill a chunk and flush it along the way? What is chunk size (it's a pity it's not part of any function signature, it's the defining constraint of every function below. Do you have static asserts for the case when msgpack packet doesn't fit the udp packet? > + > +static int > +swim_process_member_key(enum swim_member_key key, const char **pos, > + const char *end, const char *msg_pref, > + struct swim_member_def *def) No comment. What's going on here? > +{ > + switch(key) { Missing space. > + case SWIM_MEMBER_STATUS: > + if (mp_typeof(**pos) != MP_UINT || > + mp_check_uint(*pos, end) > 0) { > + say_error("%s member status should be uint", msg_pref); > + return -1; > + } > + key = mp_decode_uint(pos); > + if (key >= swim_member_status_MAX) { > + say_error("%s unknown member status", msg_pref); > + return -1; > + } > + def->status = (enum swim_member_status) key; > + break; > + case SWIM_MEMBER_ADDRESS: > + if (mp_typeof(**pos) != MP_UINT || > + mp_check_uint(*pos, end) > 0) { > + say_error("%s member address should be uint", msg_pref); > + return -1; > + } > + def->addr.sin_addr.s_addr = mp_decode_uint(pos); > + break; > + case SWIM_MEMBER_PORT: > + if (mp_typeof(**pos) != MP_UINT || > + mp_check_uint(*pos, end) > 0) { > + say_error("%s member port should be uint", msg_pref); > + return -1; > + } > + uint64_t port = mp_decode_uint(pos); > + if (port > UINT16_MAX) { > + say_error("%s member port is invalid", msg_pref); > + return -1; > + } > + def->addr.sin_port = port; > + break; > + default: > + unreachable(); > + } > + return 0; > +} OK, I understand now it's merely updating a member configuration. But then what's the event flow of such update? What happens after the update? I know from the public API that we suspend all activities while update is in progress, but this is not so obvious when you reading the code. > +/** Decode an anti-entropy message, update members table. */ > +static int > +swim_process_anti_entropy(struct swim *swim, const char **pos, const char *end) Why not swim_decode_whatever? process is a very general world, it could mean any action. > +{ > + const char *msg_pref = "Invalid SWIM anti-entropy message:"; > + if (mp_typeof(**pos) != MP_ARRAY || mp_check_array(*pos, end) > 0) { > + say_error("%s message should be an array", msg_pref); > + return -1; > + } > + uint64_t size = mp_decode_array(pos); > + for (uint64_t i = 0; i < size; ++i) { > + if (mp_typeof(**pos) != MP_MAP || > + mp_check_map(*pos, end) > 0) { > + say_error("%s member should be map", msg_pref); > + return -1; > + } > + uint64_t map_size = mp_decode_map(pos); > + struct swim_member_def def; > + swim_member_def_create(&def); > + for (uint64_t j = 0; j < map_size; ++j) { > + if (mp_typeof(**pos) != MP_UINT || > + mp_check_uint(*pos, end) > 0) { > + say_error("%s member key should be uint", > + msg_pref); > + return -1; > + } > + uint64_t key = mp_decode_uint(pos); > + if (key >= swim_member_key_MAX) { > + say_error("%s unknown member key", msg_pref); > + return -1; > + } > + if (swim_process_member_key(key, pos, end, msg_pref, > + &def) != 0) > + return -1; > + } > + if (def.addr.sin_port == 0 || def.addr.sin_addr.s_addr == 0) { > + say_error("%s member address should be specified", > + msg_pref); > + return -1; > + } > + swim_process_member_update(swim, &def); Why not swim_udpate_member? Someone needs to check that there is no buffer overflow in this code (I will check in the next review round). > +/** > + * Convert a string URI like "ip:port" to sockaddr_in structure. > + */ > +static int > +uri_to_addr(const char *str, struct sockaddr_in *addr) > +{ > + struct uri uri; > + if (uri_parse(&uri, str) != 0 || uri.service == NULL) > + goto invalid_uri; > + in_addr_t iaddr; > + if (uri.host_len == strlen(URI_HOST_UNIX) && > + memcmp(uri.host, URI_HOST_UNIX, uri.host_len) == 0) { > + diag_set(IllegalParams, "Unix sockets are not supported"); > + return -1; > + } > + if (uri.host_len == 0) { > + iaddr = htonl(INADDR_ANY); > + } else if (uri.host_len == 9 && memcmp("localhost", uri.host, 9) == 0) { > + iaddr = htonl(INADDR_LOOPBACK); > + } else { > + iaddr = inet_addr(tt_cstr(uri.host, uri.host_len)); > + if (iaddr == (in_addr_t) -1) > + goto invalid_uri; > + } > + int port = htons(atoi(uri.service)); > + memset(addr, 0, sizeof(*addr)); > + addr->sin_family = AF_INET; > + addr->sin_addr.s_addr = iaddr; > + addr->sin_port = port; > + return 0; > + > +invalid_uri: > + diag_set(SocketError, sio_socketname(-1), "invalid uri \"%s\"", str); > + return -1; > +} Shouldn't this be part of sio (it's a utility function). > + } > + if (swim_scheduler_bind(&swim->scheduler, &addr) != 0) { > + swim_member_delete(swim, new_self); > + return -1; Why is this a scheduler function, not member function? -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov
next prev parent reply other threads:[~2019-01-09 9:12 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-12-29 10:14 [PATCH v3 0/6] SWIM draft Vladislav Shpilevoy 2018-12-29 10:14 ` [PATCH v3 1/6] [RAW] swim: introduce SWIM's anti-entropy component Vladislav Shpilevoy 2019-01-09 9:12 ` Konstantin Osipov [this message] 2019-01-15 14:42 ` [tarantool-patches] " Vladislav Shpilevoy 2019-01-09 11:45 ` [tarantool-patches] " Konstantin Osipov 2019-01-15 14:42 ` [tarantool-patches] " Vladislav Shpilevoy 2018-12-29 10:14 ` [PATCH v3 2/6] [RAW] swim: introduce failure detection component Vladislav Shpilevoy 2019-01-09 13:48 ` [tarantool-patches] " Konstantin Osipov 2019-01-15 14:42 ` [tarantool-patches] " Vladislav Shpilevoy 2018-12-29 10:14 ` [PATCH v3 3/6] [RAW] swim: introduce a dissemination component Vladislav Shpilevoy 2018-12-29 10:14 ` [PATCH v3 4/6] [RAW] swim: keep encoded round message cached Vladislav Shpilevoy 2018-12-29 10:14 ` [PATCH v3 5/6] [RAW] swim: send one UDP packet per EV_WRITE event Vladislav Shpilevoy 2019-01-09 13:53 ` [tarantool-patches] " Konstantin Osipov 2019-01-15 14:42 ` [tarantool-patches] " Vladislav Shpilevoy 2018-12-29 10:14 ` [PATCH v3 6/6] [RAW] swim: introduce payload Vladislav Shpilevoy 2019-01-09 13:58 ` [tarantool-patches] " Konstantin Osipov 2019-01-15 14:42 ` [tarantool-patches] " Vladislav Shpilevoy
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190109091211.GC20509@chai \ --to=kostja@tarantool.org \ --cc=tarantool-patches@freelists.org \ --cc=vdavydov.dev@gmail.com \ --subject='Re: [tarantool-patches] [PATCH v3 1/6] [RAW] swim: introduce SWIM'\''s anti-entropy component' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox