NetworkTransport.Init();
GlobalConfig gConfig = new GlobalConfig();
gConfig.MaxPacketSize = 500;
NetworkTransport.Init(gConfig);
ConnectionConfig config = new ConnectionConfig();
int myReiliableChannelId = config.AddChannel(QosType.Reliable);
int myUnreliableChannelId = config.AddChannel(QosType.Unreliable);
int port = 8888;
for (int i = 0; i < 64; i++)
{
HostTopology topology = new HostTopology(config, 10);
int hostId = NetworkTransport.AddHost(topology, port); // maximum hosts cannot exceed {16}
port++;
Debug.Log("hostId: " + hostId);
}
The hostId stopped at 15, then it return -1 and the for loop broken.
This will cause an error: “maximum hosts cannot exceed {16}”.
Does it mean that UNET cannot open over 16 sockets?
When the Unity game start as a host and got a client connected.
It will create a Unity NetworkServerSimple object and listen an UDP port for that client.
Then the host reconnect to Facilitator and request a new GUID and UDP port for next client.
It works fine if there are 15 clients connected to host.
However, The NetworkServerSimple.Listen() contains the NetworkTransport.AddHost() function call.
Due to the 16 sockets limit, I can’t create a 32 vs 32 players game via that NAT-Punchthrough method with Unity Network LLAPI and HLAPI.
In my case, I want to let user to host a 32 vs 32 multiplayer game with NAT-Punchthrough, even more players would be better.
However, what’s the reason for limiting the number of open sockets?
If there is no strict limits, maybe developers could make some interesting things.
Is it possiable let developer or user to decide the number of open sockets?
eg. NetworkTransport.Init(HOST_COUNT) and default still 16.
Maybe it is more flexible?
So, Increase the limit and not called listen() or addhost() would also increase the memory usage?
Well, About the suggestion above, That’s just an option for adjust the max ability of open sockets, and there is still a bound of course.
Open more sockets cost more resources for sure, but that might depend on developer or project.
Maybe this is difficult to implement or not useful, never mind.