@hplus0603
When you have 5,000 players, each wanting to send a message to each of the 5,000 other players, each player will receive 5,000 messages, which ends up being 25,000,000 messages. There's no way around that, other than designing your game to not use “broadcast to everyone” very much. Interest management and sharded game design are the two main tools to use to avoid that.
Yes sharding is something i am looking into in the architecture here also as i dont know or cant predict what number is the max number of players on a single instance.
In reality the full broadcast 1 player to 4999 players probably wont be reality, but could be that all the player groups that are associated with other players are doing it so in theory full activity on all players - also i would have a ping functionality that would need to go to or from the client to keep the route alive & able to spot disconnected players so there will be continously traffic.
But if im able to make an engine that works with 1000 and my target is 5000 then i would be OK to split the ‘streamers' out on more instances by using some kind of central mechanism ex like Redis that knows on which server a player is located and then do inter-server communication and then from that server to player ( requires ofcourse the servers are a pool on their own network for speed for interserver comms ).
But am trying to understand this from a heavy-traffic perspective so at least i dont create a bottle neck in my code when i start coding.
One question though :
When im sending data to players - lets say this worst case scenario where i a queue of packets buildt up on all 5000 players - then i can do ( pesudo ):
#1
for (i=0;i<5000;i++)
if ( playerConnection.packetstosend > 0)
send (playerConnection[i],,,,)
which processes sending data to client1,2,3,4 up to 5000 - meaning client #5000 will always be the unlucky one getting data sent as the last in that loop as it will take time to get through that loop from client 1 to client 5000.
Alternative could be :
#2
ThreadClient1()
{
if (GotData( client1 ) & itsTimeToSend )
{
sendto (playerConnection[1],,,,)
}
}
And then have 5000 threads ( one sending thread per client ) / one thread per player that will processes autonomously.
My worry here is the overload of threads and at some point i assume not so scaleable - or maybe this isnt a problem on linux ? ( i grew up learning to dont overuse threads and keep them to a minimum based it on processor if possible ).
Third alternative could be to pass on the sends to a pool of worker threads, abit more dynamic than the example here but to keep pseudo simple we could do 5 workerthreads :
#3:
WorkerThread0001_1000()
{
for (i=0;i<1000;i++)
if ( playerConnection.packetstosend > 0)
send (playerConnection[i],,,,)
}
WorkerThread1001_2000()
{
for (i=1001;i<2000;i++)
if ( playerConnection.packetstosend > 0)
send (playerConnection[i],,,,)
}
WorkerThread2001_3000()
{
for (i=2001;i<3000;i++)
if ( playerConnection.packetstosend > 0)
send (playerConnection[i],,,,)
}
WorkerThread3001_4000()
{
for (i=3001;i<4000;i++)
if ( playerConnection.packetstosend > 0)
send (playerConnection[i],,,,)
}
WorkerThread4001_5000()
{
for (i=4001;i<5000;i++)
if ( playerConnection.packetstosend > 0)
send (playerConnection[i],,,,)
}
Then we split up the handling of the send in lots of 1000.
Question here is :
a)
would no #1 be faster than no #3 ? is there some sort of bottleneck anyway in the networkstack when sending UDP data to clients - or would i be dividing the time spent to handle all players there in 5 ?
b)
back in the days threads were to be used with caution so im nervous about doing a model like in #2 also dont feel its scaleable BUT if this is perfectly ok ( on linux ) and threads are lightweight then ofcourse it creates a nice and easy code but simply not sure if its the right way to do and i have the freedom to just spawn threads like it was candy ?
Thanks alot you & others here are really helping me alot here to understand what mechanisms and both opening some doors i havent thought of and closing some that i have - hope you guys dont get tired of me as i will continue asking and will also try to a diagram soon of the idea i have for a sharded setup but just need to get the concepts right here for the actual transport-part.