Welcome to the Forum Archive!

Years of conversation fill a ton of digital pages, and we've kept all of it accessible to browse or copy over. Whether you're looking for reveal articles for older champions, or the first time that Rammus rolled into an "OK" thread, or anything in between, you can find it here. When you're finished, check out the boards to join in the latest League of Legends discussions.


XMPP implementation, missing MUC status update

Comment below rating threshold, click here to show it.


Junior Member


Dear RIOT employees,

1. Disclaimer
I did not know where to post this problem of mine, since it is unclear to me if what concerns me is a bug, an intended temporary or permanent measure. So I post it here.

2. Problem
This problem of mine concerns part of your XMPP implementation on the european servers (I don't really know which XMPP server software you're using). I noticed that it recently stopped forwarding presence stanzas sent to Multi-User Chatrooms (MUC) (as in XEP-0045) to users "in" that MUC when changing one's game status (the initial stanzas while joining are still sent). This renders it impossible to know whether someone in a MUC is in a game (inGame), not in a game (outOfGame), hosting a custom game (hostingPracticeGame) or indulging in any other activity the client usually broadcasts in the "gameStatus" XML element of the status message.

If this should indeed be a bug, then this is a bug report.

If it however is intentional, then I guess I can understand the reasons behind that decision. I'll go out on a limb here and assume it's to cut down on traffic (due to the O(n²) nature of traffic involved in MUCs).

3. Suggestion / Solution
My suggestions to solve this issue without sacrificing the game status transmission feature in MUCs alltogether are:

  • 1. Make clients only send incremental status updates to MUCs.

    Since the initial presence stanza still sends the whole status message, e.g.
    • <body><profileIcon>1</profileIcon><level>30</level><wins>1234</wins><leaves>123</leaves><odinWins>432</odinWins><odinLeaves>32</odinLeaves><queueType>RANKED_SOLO_5x5</queueType><rankedWins>246</rankedWins><rankedLosses>135</rankedLosses><rankedRating>3210</rankedRating><tier>DIAMOND</tier><statusMsg>Some "random" message</statusMsg><gameStatus>inQueue</gameStatus><timeStamp>1350730195597</timeStamp><skinname>Zileas</skinname></body>

    whose size is 628 byte (after expanding the “<” and “>” into “&lt;” and “&gt;”), an incremental status message could just consist of
    • <body><gameStatus>inQueue</gameStatus></body>

    whose size would now be 70 byte (after expansion). With the typical MUC presence stanza
    • <presence from='pu~da39a3ee5e6b4b0d3255bfef95601890afd80709@conference.pvp.net/AvgUserName' to='sum87654321@pvp.net/xiff'><show>chat</show><status>$STATUSMSG</status><priority>0</priority></presence>

    of 189 bytes, this would cut down the typical MUC presence stanza from (189 + 628 = 817) bytes to (189 + 70 = 259) bytes, so to approximately 30% of the presence update traffic. Further traffic reduction could be achieved by dropping the "<body />" XML tags.
  • 2. Don't use XML as the status message format, but e.g. CSV.

    The status message from above would then be reduced to:
    • 1,30,1234,123,432,32,RANKED_SOLO_5x5,,246,135,3210,DIAMOND,"Some \"random\" message",inQueue,1350730195597,Zileas

    That's 113 bytes left, so a reduction to (189 + 113) / (189 + 628) = 35% across the board (even for initial status messages). It can be combined with incremental game status updates, by e.g. assigning the first CSV slot to the game status (inQueue, outOfGame, etc.) and then only sending the first CSV entry (or using a bitmask integer as first entry to signal which CSV entries are sent). This already comes pretty close to the theoretical maximum of compression of 189 byte / (189 + 628) byte = 23% and you cut down on initial presence stanza traffic as well.

    The CSV approach also does not require any binary data packing. Another advantage of CSV of XML is the easier parsing and thus alleviation of stress upon the CPUs involved.

Unfortunately I do not know how far you modified the XIFF source code, so I cannot simply send in a diff / patch.

4. Motivation
I write this not without ulterior motives or out of the goodness of my heart. While it is inconvenient in itself not knowing who is actually in game and who is not, we at The Gentlemen's Club (both group and chat room name) have been using a XMPP bot for game organisation (a looking for group (lfg) service of kinds) that has been serving us well, until recently. Since the bot cannot any longer detect if someone who was looking for people to play with has joined a queue, the looking for men (lfm) requests do not terminate when the seeking member actually joins a queue. This is confusing and very inconvenient.

5. Closing words
I would very much appreciate if this issue was at least acknowledged. If you cannot implement any of the suggestions due to license, budget, personal or religious reasons, that is fine. I would just like to know if somebody even read this.

I apologize if this request sounded presumptuous or condescending. I think you are doing a good job under the circumstances.

Comment below rating threshold, click here to show it.


Senior Member