Feature Request: Support multiple listeners per host

[angusmf]

First!

Awesome project! Looking forward to integrating, as you know. So, on to the feature...

API to support referencing connections by both their connection id AND listener/host id so that multiple hosts can be started for a single server instance. My suggestion is to change signatures to:

• take the connection object instead of connectionId
• take both connectionId and hostId

Thanks! More to come.

[TwoTenPvP]

How does the transport handle connectionId's with multiple hosts?
If it has different connectionId counters for each host that will be a problem. Currently, the connectionId is known as ClientId in the library and is the main way of identifying clients.

[angusmf]

The transport will still only deal with one connect id, but when the API implementation touches the transport, it will need to know which to access. So when a new event comes in on one transport, you first look at it's host id, then it's connect id before processing. When sending a message, you need the client's connect id and host id. If sending to all, you must loop through each connection on each host. That's why every place you currently pass just one int for connect Id, I suggest passing both values.

Sorry if I misunderstood your question.

[TwoTenPvP]

I will look into this. I am unsure if things need to be rebuilt for this or if it's just a matter of adding hostId to the signatures etc. Host Message Handlers are identified by ClientId's. This makes things a bit tricky. Low prio for now. If you need it urgently. Let me know.

[angusmf]

It's not an urgent need currently, but ultimately a hard requirement for my use case. It's also a somewhat common gripe with the HLAPI. I answer this question frequently for Master Server Framework. That framework is abstracted to work over UDP using LLAPI AND websockets using a vanilla C# implementation. When people try to connect to the master server from a webgl client, it works, but if they are using the HLAPI for their game networking, they are surprised that they can't connect unless the server received a "webgl" switch when started, which prevents UDP clients from working! Unfortunately, the LLAPI does not let clients choose which protocol to use, so you can't fall back to websockets on standalone clients

[TwoTenPvP]

Creating a connectionObject would be a possible solution. It will require some major changes but should be doable.

[angusmf]

If it helps at all, here is the comparer I came up with to do this with HLAPI and still use dictionaries in my "user" code.

public class ConnComparer : IEqualityComparer<NetworkConnection>
   {
       public bool Equals (NetworkConnection x, NetworkConnection y)
       {
           if (x == null || y == null) return false;
           if (ReferenceEquals(x, y)) return true;
           return x.connectionId == y.connectionId && x.hostId == y.hostId;
       }

    public int GetHashCode(NetworkConnection conn)
    {
        unchecked
        {
            int hash = 17;
            hash = hash * 23 + conn.connectionId.GetHashCode();
            hash = hash * 23 + conn.hostId.GetHashCode();
            return hash;
        }
    }

[angusmf]

I also think it's pretty reasonable to just ask users to pass a 0 for host most of the time.

[TwoTenPvP]

First I need to make a connection object. It all has to be designed and accounted for. No simple drop-in solution in this case as I see it.

[angusmf]

Yeah, if you expect the connect ID to be a sequential index, there's no way to leave the signatures as is. I previously thought about creating a new ID from the two values (that GetHashCode above would work I guess), but then you're basically forced into using dictionaries. I welcome the extra complexity, whether it's hidden or not. That the HLAPI simply makes this impossible without changing the API is a big reason to consider using something else. If someone's use case is simple enough that they never run into this, they may be happy enough with the HLAPI anyway.

[TwoTenPvP]

Ooooh. I think you hit a sweet spot. A lookup table that takes a hostId and connectionId and reverses it to a clientId. That's probably the best solution.

[angusmf]

My reasoning for not going that route was that you could never do something like have your entity id and your connect id be equal or related by a simple offset. I don't have a reason to care now, but expect it would help with jobification. If the lookup function is fast and accessible, it could be used in place I suppose.

[TwoTenPvP]

Right, an associative array will offer O(1) and we won't get much quicker than that. In the end, the performance is a result of the slowest operations often times. Micro optimizations make you more hassle than any good.

[angusmf]

Agreed, the main difference is a function call vs integer math, and until I know it's worth worrying about, I won't.