I've noticed a message in DHT log about “discarding unmatched response from...”, and wondered what it might be.
After a minute of full logging, I got a catch:
[11:26:00] I2P-Only: OUTS > 5g<...snip.address...>.b32.i2p:<port> {a={id=5E<...snip.our.id...>,info_hash=E9<...snip.hash...>,},q=get_peers,t=8DA9611EF8E03860,v=TX1c,y=q,}
<...snip.log...>
[11:26:05] I2P-Only: OUTS > 5g<...snip.address...>.b32.i2p:<port> {a={id=5E<...snip.our.id...>,info_hash=E9<...snip.hash...>,},q=get_peers,t=8DA9611EF8E03860,v=TX1c,y=q,}
<...snip.log...>
[11:26:05] I2P-Only: IN > {r={_v=AZ4,id=E9<...snip.peer.id...>,nodes=E9<...snip.many.nodes...>,token=F2F085D1E1291231,},t=8DA9611EF8E03860,y=r,}
[11:26:06] I2P-Only: IN > {r={_v=AZ4,id=E9<...snip.peer.id...>,nodes=E9<...snip.many.nodes...>,token=F2F085D1E1291231,},t=8DA9611EF8E03860,y=r,}
[11:26:06] I2P-Only: discarding unmatched response from I2P E9<...snip.peer.id...> using AZ4bigly
It seems that Tixati sends a request for peers, does not get any reply for 5 seconds, sends it once again, then gets replies for both of previous messages, and complains about it. Both requests and both replies are exact copies of each other.
I would say that 5 seconds might be too short for I2P. Tunnels regularly get clogged, and connections between nodes drop and re-initiate transparently to the passing traffic, introducing sudden delays. Some users might add extra hops and extra lag.
What's more important, BEP-5 states that there are no retries. That suggests that second request is completely independent, and should have a different transaction ID. DHT is supposed to be stateless, so no grouping by transaction IDs is implied, and they are only checked when one of the sides might need to differentiate between multiple messages from the same node.
