Konrad Zemek

Please see https://github.com/kzemek/swarm-deadlock-repro for reliable reproduction of the issue.

These are the logs produced with `debug: true`: https://gist.github.com/kzemek/f5067111dcc5b1c40803b12966cd1a1f#file-gistfile1-txt There are no more debug logs after that point.

I've also tried manipulating the choice of sync node in hopes that it would solve the lock: https://github.com/kzemek/swarm/commit/28516d93413fa41a54281ee0c3bb0f7a92a4058e But instead, the states of the `Swarm.Tracker` processes got stranger: https://gist.github.com/kzemek/f5067111dcc5b1c40803b12966cd1a1f#file-nodes_sync_to_smallest-txt All...

This particular issue is not there when reverting to commit c305633 (pre https://github.com/bitwalker/swarm/commit/412bad990c69748dac300bd69e6a26b988e71b0). The nodes all go into `:tracking` state almost instantly.

I'm having the same problem as @jordan0day and with the same "solution" - switching to latin1, which fixes the binary but is not acceptable in general. With utf8 charset the...

I agree that's probably the best way to solve the issue; however, I currently lack resources to implement it. I've fallen back to using raw SQL queries with inline hex-encoded...

In this scenario, would you want go-mmproxy to run (with a single external proxy port) as a round-robin load-balancer over the backend ports, or do you want to specify 1:1...

I like this but I have to set aside some time to test the changes. External testers welcome. :)

Records 0-2100 (`extended_socket_ipv4` for `flow_data`, `virt_node` for `counter_data`) and 0-2102 (`extended_proxy_socket_ipv4` for `flow_data`) are now supported. 0-2102 & 0-2106 for `counter_data` are both a part of [sFlow HTTP structures](https://sflow.org/sflow_http.txt).

Compiling with OpenSSL 1.1.0 requires a few changes in the Asio code. I'll be looking into it soon(ish).