Posts: 783
Threads: 12
Joined: Jan 2014
Thanks: 2
Given 73 thank(s) in 61 post(s)
I'm currently working on changing the way broadcasts work to go through the protocol encoding before going to the client. The problem is that the protocol and client handle classes are incredibly tightly coupled. So how would people feel about splitting broadcasts out of cProtocol?
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1075 thank(s) in 852 post(s)
(I've moved this into a separate thread)
What exactly do you mean by "broadcasts"? And how would you split them?
Posts: 783
Threads: 12
Joined: Jan 2014
Thanks: 2
Given 73 thank(s) in 61 post(s)
As in any packet that is broadcast to any client in a chunk. Eg anything you can send through the cWorld::Broadcast* methods. What I'm thinking of is moving those packets to a separate set of classes. The problem is that I've rigging up a system that lets clients subscribe to encoded broadcasts on a chunk. I've worked out how to handle separate protocol versions. However the cProtocol class is heavily tied to cClientHandle, but my scenario involves having a cProtocol instance that isn't associated with a specific player.
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1075 thank(s) in 852 post(s)
I have a feeling you already have something like this at the cBroadcaster level - it does a DoWithChunk() and in the callback it calls the specific SendXYZ call on cClientHandle. So cWorld, cChunkMap and cChunk should already be broadcast-less when this change is fully implemented.
I'm not sure if any more refactoring is a good idea, it might make things too twisted to understand. I'd go with the current refactor only and then see if that is satisfactory.
Posts: 783
Threads: 12
Joined: Jan 2014
Thanks: 2
Given 73 thank(s) in 61 post(s)
Ok, I'll finish with moving broadcasts into cBroadcaster. Then look at cClienthandle. And maybe the the issue of what to do with cProtocol will be obvious.