Is there a reason to have separate client and server endpoints?

[MOZGIII]

I feel like I am missing something, but I don't see a reason why there is a need to have incompatible types for the endpoints.

With QUIC in general and quinn in particular it is totally fine to issue a connect from an endpoint that is also accepting connections. Why isn't it allowed in wtransport?

[BiagioFesta]

Merely design choice: to have a more user-friendly API interface.

Users might find confusing to have same endpoint working both server and client, in particular considering two different incompatible type for configuration are anyway required.

quinn panics/returns error when Endpoint is used without providing the proper configuration type before, introducing a mutable state (which might leads inconsistent program states).

Considering (from my point of view) having overlapping Endpoint does not bring enough benefits comparing to the possible bad design, I preferred to have this stateless, less error-prone design.

[MOZGIII]

Well, this design is denying a use case that could be very much useful. Any chance you'll enable it somehow?

[BiagioFesta]

As said, from my experience, I don't see any useful use case, compared to the disadvantages.

You say "very useful use case", please describe it, in order to make me understand if the trade-off is worth it

[MOZGIII]

NAT hole-punching basically, for client-to-client connections