Resolved ClientId to TransportId in NetworkManager

Hi teamclouday!

There is a way to do this with NGO today, but it is a bit more code than you would expect.
Here are some areas of interest you might want to reference (although if you are writing your own transport I am assuming you already have combed over these areas):

• ParseClientId -> UnityTransport
• ProcessEvent -> UnityTransport
• InvokeOnTransportEvent -> NetworkTransport
  
• HandleRawTransportPoll -> NetworkManager
  • Specifically where it handles the mapping
• NetworkEvent

Path To Creating Your Own Transport ID to NGO Client ID Mapping Table
Since you are writing your own transport, you can add your own callbacks that are registered on the server side. For this example, let's assume you have a server specific script called "TransportConnectionMapping" that registers for these callbacks.

Starting in your custom transport where you are invoking InvokeOnTransportEvent and the event is of type NetworkEvent.Connect:

• Add a special case here that invokes custom events that you add to your Transport:
  • Invoke "OnTransportPendingConnection" (your transport's custom callback) that includes the Nakama' s transport ID and is invoked prior to invoking InvokeOnTransportEvent.
    • When this is invoked you will want to create a copy of NetworkManager.PendingClients in your server-side "TransportConnectionMapping" script (or whatever you name the class that handles this)
  • Invoke your InvokeOnTransportEvent next as that will add a new entry to the NetworkManager.PendingClients dictionary.
  • Invoke "OnTransportMapPendingClient" (your transport's custom callback), this will look at your current pending clients copy in your TransportConnectionMapping script and determine which entry was added to the NetworkManager.PendingClients dictionary.
    • The new keypair entry's key (ulong) is the NGO client id waiting for approval
    • You now should have both the Nakama transport ID and the NGO assigned client ID that you can create your two dictionaries to be able to map between NGO client ID and Nakama transport ID.
• At this point you just need to wait for the connecting client to finish the approval process.
  • If the pending client fails to be approved or is approved and disconnects later, you obviously will want to remove it from your own mapping tables (i.e. need to handle cleaning it up yourself)

The Logical Flow Will Look Like :

• When your transport is handling NetworkEvent.Connect:
  • CustomTransport.OnTransportPendingConnection (with NakamaId)
    • Replicate/Track NetworkManager.PendingClients
  • CustomTransport.InvokeOnTransportEvent
    • NetworkManager creates new pending client entry
  • CustomTransport.OnTransportMapPendingClient
    
    • Compare your replicated pending clients with the NetworkManager.PendingClients
      • The key of the KeyValuePair is the assigned NGO ClientID
    • Create the two new entries in your own NGO ClientID to Nakama Transport Connection ID mapping (to and from) tables

While it is a bit of "hoop" jumping to get your own mapping, using an approach like this will get you moving forward.
Let me know if the above solution, for now, works out for you or if you run into any further issues or have further questions.

Cheers,
Noel

If you find this tedious/too complicated, then I would definitely recommend filing a feature request to have us (NGO Team) add the following methods to NetworkManager:

• ulong NetworkManager.GetTransportIdentifier(ulong clientId)
• ulong NetworkManafer.GetClientId(ulong transportId)

 

@teamclouday Yes! You can do it from here

 

Glad I could help and that it unblocked you so you can continue to make something awesome!
Thank you for using NGO!