Using multiplex::Client with an unreliable transport?

[vartiait2]

Hi!

I noticed that currently ClientInner in src/multiplex/client.rs assumes always to receive a reply from the underlying transport.
However, when using e.g. tokio_util::udp::UdpFramed as a transport, there won't be any guarantee that a reply will arrive
and Pending requests will be left within ClientInner's responses VecDeque.

Should the multiplexing capable transport used implement a per request timeout feature or what would be a better solution?

[jonhoo]

This is a tough question. I think what I'd do here is to make the transport produce "ghost" time-out responses after a certain amount of time, rather than bake that functionality into the Client itself. Otherwise I suspect there are a lot of special behaviors the Client could adopt that would end up having to be integrated as well.

[vartiait2]

Thanks for the reply. I'm using tokio_tower::multiplex::MultiplexTransport to pair a tag store with a transport, so I could incorporate tokio_util::time::delay_queue::DelayQueue in it to yield timeouts along with replies.

[JRAndreassen]

@vartiait2 : I'd like to hear what you did to resolve this issue.
I'm looking at the same to implement a multiplexing SNMP Client...
(Yes, SNMP is dead... Long live SNMP... )
Thanks
JR