search

RedpointArchive / netcode.io-browser

Browser extensions which enable the use of netcode.io (secure UDP) prior to adoption in web browsers
293 stars 22 forks source link

Ability to set protocol ID? #4

Closed GlaireDaggers closed 6 years ago

GlaireDaggers commented 6 years ago

It'd be nice if I could pass a protocol ID as part of the create client method. While Javascript doesn't support 64-bit numbers properly, it could be passed as a string and then parsed in the standalone helper via ulong.TryParse. This way, apps built on this extension don't all end up using the same protocol ID. It'd also help increase feature parity in my Unity wrapper, which currently allows assigning a custom protocol ID to UnityNetcode.ProtocolID, which is passed to created clients and servers but only when running in standalone mode (assigning a custom protocol ID and then starting a server breaks compatibility with WebGL builds, which do not have a custom protocol ID)

gafferongames commented 6 years ago

Yes. Apps definitely need to set their own protocol id!

hach-que commented 6 years ago

Isn't the protocol ID entirely set by the server and connection token generator?

None of the client functions the C implementation of netcode.io accept a protocol ID.

hach-que commented 6 years ago

(None of the browser code generates tokens or acts as a server, which is why the protocol ID doesn't appear in any of the APIs)

gafferongames commented 6 years ago

Good point. My idea of usage was that the client would pass up protocol ID to the rest call to the server (to enable multiple versions of the game being served in parallel from the same backend), and then this protocol ID would be incorporated into the token and passed down to the client.

hach-que commented 6 years ago

Yeah, how the client obtains the connect token is totally up to the application and not something the browser API covers.

GlaireDaggers commented 6 years ago

Ah, I get it now. Another pass over the C code reveals that, in fact, it does just retrieve protocol ID from the connect token (whereas in my .NET implementation it takes a protocol ID in the constructor and rejects connect tokens with mismatching protocol IDs in the Connect function). I might just go ahead and remove the protocol ID from my .NET version as well, and just grab it out of the connect token. Sorry to raise the apparent non-issue then - I suppose a bit more digging on my part should have shown me what I needed to know >.>

hach-que commented 6 years ago

No worries ^_^