+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: Move broadcasts out of cProtocol (/thread-1916.html)
Move broadcasts out of cProtocol - worktycho - 05-07-2015
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?
RE: Move broadcasts out of cProtocol - xoft - 05-07-2015
(I've moved this into a separate thread)
What exactly do you mean by "broadcasts"? And how would you split them?
RE: Move broadcasts out of cProtocol - worktycho - 05-07-2015
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.
RE: Move broadcasts out of cProtocol - xoft - 05-07-2015
I still don't quite understand. Can you provide some pseudocode example? Is it the cBroadcaster class that you're implementing in PR https://github.com/mc-server/MCServer/pull/1951 ? Or something else?
RE: Move broadcasts out of cProtocol - worktycho - 05-07-2015
Its a development of PR 1951.
Basically at the moment broadcast packets go like this with methods spercific to each packet in every class.
cWorld -> cChunkMap -> cChunk -> cClientHandle (for each client) -> cProtocol (for each client) -> cClientHandle -> cTCPLink.
I'm trying to change it to this, where classes on the lower line are providing a generalized API.
Code:
cBroadcaster cChunkBroadcastManager -> cProtocol(For every protocol version) -> cClientHandle -> cTCPLink
v ^
cWorld -> cChunkMap -> cChunkLonger tem I suspect the better solution would be to split the data sending parts of cClientHandle out into a separate class, then remove all of cProtocol's dependencies on cClientHandle, but I don't want to get into a second refactor in the middle of this one.
RE: Move broadcasts out of cProtocol - worktycho - 05-08-2015
@xoft do you need more explanation of what I'm trying to do, or are you happy with the split?
RE: Move broadcasts out of cProtocol - xoft - 05-08-2015
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.
RE: Move broadcasts out of cProtocol - worktycho - 05-08-2015
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.