You should not do that. The reason is simple: everytime you have a change you would try to inform them. And this comes with 3 major downsides:
1) You try to reach someone that maybe not reachable. Just because you think there is an open connection does not mean it really is. The information that is has been closed may not have reached you. Based on the implementation the data loss may be significant nor not.
2) You send a single information and not a package of information. Each information has the full overhead necessary for communication.
3) If the user just established a connection, you need to sync anyways. So it's only an additional option not the only way.
The passive approach is often the better one if not realtime sync is required.
If a user wants to use something, let him ask for a checkinfo if there are any news. The checkinfo can also be something simple as a date. When a user initiates the use, it tries to request the latest updates and changes. But identifying the changes can be difficult. So another way is working with a version number for information. Then you exactly know what have changed for the user and can provide any information the user has to get work with it.
As it may take a moment, its always good to work asynchron. To ensure a connected user has the newest information, implement a method that your communication also handles your latest info version number. If so, the client always know if it has to request an update. And then the update can be requested and updated.
Serverside, you can decide whether information is necessary for the user or optional. Optional information is e.q. for regions the user does not use regulary or unlikely or if something non relevant has changed the user may not work with. But that's maybe the next level.
The checkinfo is fine as a date in milliseconds. That should do the trick. And if the date already exists (in rare cases) just count up by 1. If it's even lower, take the newest and update the number. If you have too many updates in on ms level, you need to find another way for enrichment of your checkinfo.
Based on the amount of information, it can make sense to work with multiple versionings to shrink the required amount of information. Downside is, that it will be much more difficult to know what has changed and what not. So you have to group it or make sure you store another information what has been updated separately apart from the global stuff.
Minimizing the amount of data that is transported is one of the most important things to make it performant and reduce costs on all sides. But make sure you define a proper logic that is unbreakable. Otherwise think of a workaround if something went wrong - like a checksum over all information to compare with the server, and if there are any irregularities, try to zoom with different checksums of different elements to potentially reduce the amount of data sent. Receiving the full package everytime something is out of sync maybe too much.
Based on the size of your project you can decide which depth is appropiate. You do not need a solution that can scale huge but to have a solution that allows itself to exchange parts easily and allow you to scale larger. That like you dont need to know it all, if you have a lexikon at hand.
That basically has nothing to do with open sockets, it's just how information should be shared. Synchronization is not so trivial but active pushes should only be used if a realtime performance is required. From what you wrote, it does not seem to be necessary. So avoid it at any costs. Synchronize your data client sided to ensure the user received the desired amount of information. You almost never need to sync all data everytime. Make sure to also think of the situations that does not fit the in general case and to ensure they do not suffer much from desynchronization.
Better not think about "can I do that" but "should I do that".
