SendAddonMessage() was designed to make it easy for addons to CHEAPLY receive only their own messages. However, if the addon/lib is doing more than a simple string equality compare on the first arg (I believe AceComm uses it to pass info about fragmented messages) then you've got the lovely cost of performing string ops on EVERY SINGLE MESSAGE THAT IS RECEIVED.
Use that first arg as a simple token, like it was designed, and your listener will be fast enough that it shouldn't matter who is spamming, unless they are spamming with your message token (and then you're prolly gonna have other errors to deal with anyway).
It's the standard issue, use the API as it was designed and it works great... try to make it do more than it was designed for... YMMV.
I don't think that there will be ever some sort of player controlled server side processing .. maybe the option to disable addon communication completly but never registering/unregistering to potentialliy unlimited player created events on server side.
The SendAddonMessage()api is definetly an issue for players on weak lines.
As many players insist on having X number of syncing addons running while raiding they can cause issues for many other players.
I pray for the day when blizzard actaully add server side processing of those messages so they are only sent to players who register for them.
Would be best if blizzard implemented it proplery i'd say.. granted we alway want more than what's given after it's given :\
The origional thread that threatened WoW with a commom comms lib was legendary.. so many good ideas about how it should work...
As it stands the SAM() api should have everything it already has and..
-Specific Registration for a Prefix to a frame at the game lvl and not at the addon level.. (won't happen)
-Global Distro (also won't happen)