For TCP I use a thread that is initialized from the main server protocol thread; when a change occurs to the main data structure, which needs to be sent to each client, a static boolean is set and sends that relevant data to the client, which also has a thread that is implemented off the main client protocol thread to listen and implement those changes.
I use a token passing system to lock access into the data structure, so a client can only make changes when their token is called. I tag each token, so that the static var isn't set to false until each user has received the data to be changed.
This is more a challenge in logic than utilizing a single line of code. Regardless any library interface would have to use similar logic in the sense it must contact (n) number of clients.
In my case, this usage reduces client calls and allows for the passing of only data that has been changed. Unlike an initial load where the entire data structure is passed, but I do something similar that is also connected to traversing the data structure and saving it to hard disk. This means a reduction in data that is passed over the network and keeps the main protocol thread open longer so that those that really need access get it.
edit: so that no one complains, I'm talking straight TCP/IP and not UDP, where the connection needs to be established. UDP does use a multicast concept and setting it up is rather easy. Beware, it is prone to being a security risk, and even though it does provide some efficiency, it's scope of use should be viewed as limited.