Motion to make Multipass the default Implementation of the Transport Manager

[Katerlad]

A little bit of refactoring would need to take place, but it seems as if Multipass was an after addition thought, so its API is different when you want to start servers and clients.

Design the API around making multipass the default implementation of fishnet!

TransportManager - would incorporate just have an array for the transports instead of a single slot.

ServerManager.StartConnection() - would be default, starting all transports connections, with many overloads.
ServerManager.StartConnection< T >() - using generic to select specific transport to start. use overloads for many options

ClientManager.StartConnection() - would start the connection on the index 0 - tugboat by default.
ClientManager.StartConnection< T >() - would start the connection on the specific transport. - use overloads for many options.

Why?

Multipass seems out of place with how fishnet operates. It seems like it was a tacked on addition, that didn't fit well with fishnets current API options, but really its functionality should be default.

For example to start a client connection on multipass you have to get multipass reference, SetClientTransport, and SetClientAddress, and then start the Client using multipass.

This should all just be handled with ClientManager.StartConnection < FishyFacepunch > (hostsAddress);

[WelfareCheckVS]

I like that. Introducing users to the idea of multiple transports will help plan deployment before realizing a year later they forgot to plan for deployment.

[FirstGearGames]

It seems like you want extensions of the API rather than get rid of multipass?

[Katerlad]

Idk if you'll love the idea, but it's more merging the transport manager and multipass into just being the transport manager, then designing the transport manager to handle multiple transports with a more seamless API. Like the examples above.

Sorry for some reason I didn't see any of your reply's from 4 months ago until now.

[FirstGearGames]

This does make a lot of sense. The only real concern is the performance hit when sending/recv checks with multiple transports. If that's something we can avoid then there's no reason Multipass cannot be built-in.

…

On Wed, Feb 12, 2025 at 4:08 AM Katerlad ***@***.***> wrote: Idk if you'll love the idea, but it's more merging the transport manager and multipass into just being the transport manager, then designing the transport manager to handle multiple transports with a more seamless API. Like the examples above. Sorry for some reason I didn't see any of your reply's from 4 months ago until now. — Reply to this email directly, view it on GitHub <#515 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGPJC3UD6EYO4XMGH2ZMBQT2PMFQHAVCNFSM6AAAAABQHWL3FOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMJWGY2DKMY> . You are receiving this because you commented.Message ID: ***@***.***>