Feature request: parallel requests

[ninuru]

The current implementation of an EppConnection only allows 1 request at a time.
I was wondering if this was a design choice, or just a limitation of the EPP protocol at all?

We are looking to add functionality for parallel requests but before we invest too many resources, it would be great to know
if there are reasons behind the current interface.

[djc]

It wasn't really an active choice, just easier to build. Definitely open to supporting concurrent requests. Suggest you make a design proposal before starting implementation.

[ninuru]

Thanks for the fast reply. I will come back to this next week when I am in the office again.

[valkum]

The Extensible Provisioning Protocol does not support multiplexing.

An EPP client streams EPP commands to an EPP server on an established
TCP connection. A client MUST NOT distribute commands from a single
EPP session over multiple TCP connections. A client MAY establish
multiple TCP connections to support multiple EPP sessions with each
session mapped to a single connection. A server SHOULD limit a
client to a maximum number of TCP connections based on server
capabilities and operational load.

EPP describes client-server interaction as a command-response
exchange where the client sends one command to the server and the
server returns one response to the client. A client might be able to
realize a slight performance gain by pipelining (sending more than
one command before a response for the first command is received)
commands with TCP transport, but this feature does not change the
basic single command, single response operating mode of the core
protocol.

This crate currently already buffers one additional request. You can place a request buffer in front (for the same session, see tower crates for something easy to apply) or use a bb8 powered pool for concurrent requests (multiple sessions).
The only thing that is a bit ugly with a bb8 pool is figuring out if a connection is healthy. Currently, closed connections (closed TCP TLS streams) are identified by trying to write to the stream. So to check if a connection is healthy, you need to send a hello, which might be a bit costly for a single request that follows. Or ignore and rely on the currently implemented reconnect functionality.
Wondering if we can provide a better estimate here, e.g. by exposing something that uses TcpStream::poll_write_ready, ideally something that covers TLS close_notify as well, which is something that you get more often (if the EPP server closes the connection).

A driver pattern that listens for a TLS close_notify out of band might be an improvement. There is https://github.com/djc/instant-epp/tree/io-task where I worked on this in the past.