multistream-select interoperability issue with JS

[tomaka]

When js-libp2p connects to a listener, it starts by sending out /multistream-select/1.0.0, then waits for the remote to send back /multistream-select/1.0.0, then only sends out the requested protocol.

However, the rust-libp2p listener reads /multistream-select/1.0.0, then sends out /multistream-select/1.0.0, but doesn't immediately flush that to the TCP socket. It only flushes after having sent back an answer to the requested protocol.

cc @raulk @romanb

[tomaka]

The buffering seems to be happening here:

rust-libp2p/misc/multistream-select/src/length_delimited.rs

Lines 248 to 254 in c0b379b

	let mut uvi_buf = uvi::encode::u16_buffer();
	let uvi_len = uvi::encode::u16(len, &mut uvi_buf);
	self.write_buffer.reserve(len as usize + uvi_len.len());
	self.write_buffer.put(uvi_len);
	self.write_buffer.put(msg);
	Ok(AsyncSink::Ready)

Calling start_send only pushes data to a buffer without sending it out immediately.

[romanb]

This was done intentionally in #1212 - However, if js-libp2p behaves this way and generally it is unfortunately not a requirement of the multistream-select 1.0 spec to send the multistream header together with the first multistream-select request (typically a protocol proposal), there is probably no other option than to immediately flush the multistream-select response header on the listener's side in rust-libp2p. 🤷‍♂️

[romanb]

@tomaka If you would want to change that, it is only a matter of changing this line to

self.state = State::Flush { io };

Flush then transitions to RecvMessage.

[raulk]

cc @AgeManning

[romanb]

Closed by #1245.