jdev - 2021-08-22


  1. mikeye has joined
  2. emus has joined
  3. Duncan Hart has joined
  4. scorch has left
  5. Duncan Hart has left
  6. mac has left
  7. Duncan Hart has joined
  8. Duncan Hart has left
  9. stuart.j.mackintosh has left
  10. scorch has joined
  11. stuart.j.mackintosh has joined
  12. Duncan Hart has joined
  13. Duncan Hart has left
  14. mikeye has left
  15. Duncan Hart has joined
  16. Duncan Hart has left
  17. wurstsalat has left
  18. mac has joined
  19. debacle has left
  20. mikeye has joined
  21. mikeye has left
  22. mikeye has joined
  23. Duncan Hart has joined
  24. dezant has left
  25. lovetox has left
  26. lovetox has joined
  27. mac has left
  28. mac has joined
  29. mikeye has left
  30. dezant has joined
  31. jgart has joined
  32. mac has left
  33. mac has joined
  34. paul has joined
  35. Duncan Hart has left
  36. Duncan Hart has joined
  37. Duncan Hart has left
  38. Duncan Hart has joined
  39. emus has left
  40. mikeye has joined
  41. dezant has left
  42. dezant has joined
  43. mikeye has left
  44. scorch has left
  45. mikeye has joined
  46. DebXWoody has joined
  47. Duncan Hart has left
  48. scorch has joined
  49. mikeye has left
  50. Duncan Hart has joined
  51. Duncan Hart has left
  52. mikeye has joined
  53. Duncan Hart has joined
  54. Duncan Hart has left
  55. _Liveware Problem_ has joined
  56. selurvedu has left
  57. Vaulor has left
  58. Vaulor has joined
  59. mikeye has left
  60. Duncan Hart has joined
  61. Duncan Hart has left
  62. Duncan Hart has joined
  63. 9lakes has left
  64. nephele has joined
  65. MattJ flow, smack+websockets question: https://stackoverflow.com/q/68872115/15996
  66. MattJ I saw https://github.com/igniterealtime/Smack/pull/399 merged, but I can't see it in a release or docs
  67. MattJ and https://download.igniterealtime.org/smack/docs/latest/documentation/ is empty
  68. MattJ (linked to from the readme)
  69. MattJ and I can't find a changelog
  70. hiran has joined
  71. mac has left
  72. nephele has left
  73. nephele has joined
  74. _Liveware Problem_ has left
  75. wurstsalat has joined
  76. goffi has joined
  77. dezant has left
  78. me9 has joined
  79. jgart has left
  80. scorch has left
  81. scorch has joined
  82. emus has joined
  83. dezant has joined
  84. Duncan Hart has left
  85. debacle has joined
  86. Duncan Hart has joined
  87. Duncan Hart has left
  88. Duncan Hart has joined
  89. lovetox has left
  90. Duncan Hart has left
  91. lovetox has joined
  92. DebXWoody has left
  93. flow MattJ, websocket support is not yet in a release (only in pre-releases)
  94. flow and thanks for pointing out that latest/documention is empty, will look into it
  95. Duncan Hart has joined
  96. 9lakes has joined
  97. hiran has left
  98. Squeaky Latex Folf has left
  99. Squeaky Latex Folf has joined
  100. antranigv has left
  101. antranigv has joined
  102. jgart has joined
  103. 9lakes has left
  104. antranigv has left
  105. antranigv has joined
  106. antranigv has left
  107. antranigv has joined
  108. antranigv has left
  109. antranigv has joined
  110. antranigv has left
  111. antranigv has joined
  112. antranigv has left
  113. antranigv has joined
  114. antranigv has left
  115. 9lakes has joined
  116. Duncan Hart has left
  117. laylolamb has joined
  118. inky has joined
  119. Yagizа has joined
  120. jgart has left
  121. Yagizа has left
  122. debacle has left
  123. dezant has left
  124. dezant has joined
  125. Yagizа has joined
  126. Yagizа has left
  127. Yagizа has joined
  128. Yagizа has left
  129. inky has left
  130. antranigv has joined
  131. laylolamb has left
  132. inky has joined
  133. inky has left
  134. laylolamb has joined
  135. inky has joined
  136. inky has left
  137. inky has joined
  138. inky has left
  139. mikeye has joined
  140. Alex has left
  141. mikeye has left
  142. jgart has joined
  143. spectrum has left
  144. nephele has left
  145. Alex has joined
  146. Squeaky Latex Folf has left
  147. Squeaky Latex Folf has joined
  148. hiran has joined
  149. hiran Hi there. It seems my smack client can send messages to a MUC successfully. But as I start and stop my client, more and more accounts get registered on the MUC. This does not look like a problem for me. But interestingly I start receiving messages several times. Sometimes they have the different JIDs, sometime they seem to be for the exactly same JID. How can my client application ensure every message is only received once?
  150. nephele has joined
  151. MattJ What server software is your account using?
  152. dezant has left
  153. hiran I am registered to https://xmpp.libretank.org/ In fact I am writing with that account right now. While I have no clue what that server is running it claims to be 100% compliant...
  154. MattJ Recent ejabberd, so it /should/ be correct
  155. MattJ You can't join a MUC multiple times from the same full JID, so with a correct server implementation you can only receive multiple messages by having multiple connections open
  156. jonas’ what are the chances that ejabberd re-routes type="groupchat" sent to a full jid to other domains?
  157. jonas’ what are the chances that ejabberd re-routes type="groupchat" sent to a full jid to other resources?
  158. jonas’ what are the chances that ejabberd re-routes type="groupchat" sent to an unavailable full jid to other resources?
  159. jonas’ no wait, an unavailable full jid shouldn't receive MUC messages anymore
  160. hiran stanza sent to <user>@xmpp.libretank.org/10715983031612837986184739 but my connection is for <user>@xmpp.libretank.org/15037136815575938774184803 And I am getting multiple such messages back for one that I send to the MUC
  161. MattJ That used to be a bug in some servers, but I've not seen it for a long time. I guess Holger could confirm (but he's not here)
  162. jonas’ even *if* it was unavailable, then the MUC should remove the user anyway
  163. jonas’ because unavailable => unavailable presence broadcast => removed from MUC => no messages anymore
  164. jonas’ and if it isn't unavailable, there's no reason to reroute the messages
  165. MattJ Right, but in the case of ghosts the MUC relies on an error bounce from the user's full JID
  166. jonas’ hiran, is your MUC also with libretank.org?
  167. hiran Yes it is
  168. MattJ If you are sending unavailable and still receive messages, there is clearly an issue with the MUC
  169. jonas’ so no s2s problems here
  170. hiran The muc address is <room>@muc.xmpp.libretank.org
  171. jonas’ hiran, do you have by any chance a log of the raw XML exchanged between the server and your client?
  172. jonas’ of a complete "join muc, send message, receive many" session?
  173. hiran I can try to create that
  174. jonas’ no warranty that it'll help any, but maybe there's something in there which'll help us figure out what's going on
  175. jonas’ in any case, what you're seeing is not the expected behaviour of a MUC :)
  176. nephele has left
  177. hiran I have a log of about 700 lines. How can I best share it with you?
  178. jonas’ hiran, you could put it on a thing like paste.debian.net
  179. hiran Going for pastebin.debian.net...
  180. nephele has joined
  181. DebXWoody has joined
  182. hiran Ok, the log is at https://paste.debian.net/1208577
  183. jonas’ ugh, smacks logs are so unreadable…
  184. jonas’ (not your fault :))
  185. Alex has left
  186. Alex has joined
  187. jonas’ hiran, should there be multiple connections in there?
  188. hiran No, that client only connects once. However while I develop I am starting, stopping, debbuggin, killing so probably it does not always logoff gracefully.
  189. jonas’ line 327 is the beginning of a new connection
  190. hiran Oh, there is something special I guess. When the player loads a savefile, the nickname gets set to the name from the savegame. I noticed that sending a 'rename' runs into timeouts sometimes. In that case the client will leave the muc and come back as new user. I did not notice that the entire connection is re-established. But the old one would no longer be used in that case, would it?
  191. jonas’ I don't know
  192. jonas’ I don't see it being shut down
  193. jgart has left
  194. hiran Ok, I can check whether there is a disconnect in my client when it shuts down. But if it crashes that message would not be sent either. The TCP connection is definitely gone.
  195. nephele has left
  196. nephele has joined
  197. hiran My Gajim client, which is connected to the same muc does not display the other user in the muc chat window. But the roster just increased from hiran (4) to hiran (6)
  198. Alex has left
  199. Alex has joined
  200. hiran But it seems correct that the server would forward a message sent to the muc to all online users on all online devices/JIDs. With that I could simply filter out those messages that contain the connection's JID as recipient.
  201. hiran Unfortunately there seems to be multiple copies of the same message with the correct recipient also. This is confusing me. So how would I efficiently prevent getting a message multiple times or at least filter out the duplicates?
  202. jonas’ I wonder if you're accidentally sending/receiving via all possibly still established connections at the same time?
  203. jonas’ the behaviour makes no sense and normally you shouldn't need any filtering like that – to me it sounds as if you accidentally have multiple connections open at this point
  204. stuart.j.mackintosh has left
  205. stuart.j.mackintosh has joined
  206. hiran Even if multiple connections were open (let's assume I do not properly close them and the Smack API keeps them open) my application holds only one reference to a connection and one reference to a muc. It is that one muc that is used to send the message.
  207. dezant has joined
  208. jonas’ maybe you can ask in xmpp:smack@conference.igniterealtime.org?join
  209. hiran For the log I sent the message "Hi there". You can find three occurrences. Once it is being sent, twice it is being received.
  210. emus has left
  211. jonas’ uhh, but the second reception is from the MUC history on join
  212. jonas’ and also there are definitely two connections open and active: see lines 603 and 629
  213. hiran History? Could make sense. How can I control that? Wither filter those out or prevent them from being sent at all
  214. jonas’ check the smack API. you have to tell the MUC server on join how much history you want
  215. jonas’ which you do… (line 634) but the server still gives you history
  216. jonas’ maybe try maxstanzas='0' instead of seconds='0'…
  217. hiran Hehe. Now that explains something. For the two lines/connections: You can see that the nickname changed. <presence to='oolite@muc.xmpp.libretank.org/Jameson/' I believe the /Jameson/ part is the nickname, isn't it? It is allowed for clients to change their nick during a connection?
  218. jonas’ yes
  219. jonas’ `Jameson/` is the nickname
  220. hiran Ok, am fine with that. so it makes sense for the new presence message to be sent.
  221. hiran But if the server sends history despite me asking for 0 seconds, I need to filter on the client side.
  222. jonas’ I think filtering history by seconds is not implemented everywhere
  223. jonas’ so just see if it helps if you switch to maxstanzas
  224. jonas’ then you don't have to bother with filtering
  225. jonas’ (and maxstanzas should be supported everywhere)
  226. hiran Ok, I will try that
  227. hiran Oh, Smack offers a 'requestNoHistory' method as well
  228. emus has joined
  229. hiran Looks much better this way
  230. hiran Thank you Jonas, I think now I do not need to filter on client side. :-)
  231. marmistrz has left
  232. jonas’ perfect :)
  233. marmistrz has joined
  234. hiran I can confirm now that the client did not really close the connection on shutdown. This is fixed, but when I kill the client during a debug session (or it crashes) this will still be the case.
  235. MattJ The OS will close your connection for you if the process exits or crashes
  236. Zash IFF that's the kind of crash that's referred to
  237. jonas’ though if you negotiate stream management it may take "a while" before the session is considered dead at the server
  238. MattJ True, but you still won't receive messages for those sessions
  239. Zash Were it ejabberd that would treat groupchat messages for non-existant sessions the same way as chat messages wrt redirecting to other sessions?
  240. dezant has left
  241. hiran When I talk about kill I mean the JVM running my Smack client terminates. For a crash this need not be the case but I terminate it as well. So the process exists, the OS should kill the TCP connection and the server has to live with that.
  242. hiran BTW I do neither own nor operate the server so my knowledge about it is fairly limited
  243. MattJ Yes, that's totally normal and happens all the time in the real world. In fact the only time streams are closed gracefully is when the user closes the app or logs out. For chat apps that happens rarely.
  244. Zash "are" - not sure that's 100% accurate either
  245. Zash Dealing in absolutes etc
  246. moparisthebest has left
  247. debacle has joined
  248. alacer has joined
  249. Vaulor has left
  250. Vaulor has joined
  251. dezant has joined
  252. hiran Another question about stanza IDs... From my XML log I can see that every stanza has an id attribute. All but those that my client creates (let's say the payload). Now I am wondering whether those IDs are set by Smack or is it left to me as developer?
  253. alacer has left
  254. hiran If the developer is responsible, this call makes sense: message.setStanzaId(chatMessage.msgid); Unfortunately I am using the builder pattern: MessageBuilder builder = StanzaBuilder.buildMessage(); ..... connection.sendStanza(builder.build()); The builder does not allow me to set a message ID, so I'd expect it takes care automatically...?
  255. alacer has joined
  256. me9 has left
  257. Alex has left
  258. pulkomandy has left
  259. flow hiran, smack will set a stanza id for you, but if I am not mistaken, the builder does also allow you to set one
  260. hiran I checked again. And yes, for text messages or muc messages it does. But then I also have custom messages where one player can directly send something to another player. These custom messages seem to not have any ID. So I may be responsible for providing one... <message to='oolite@muc.xmpp.libretank.org/Mogli/Hopeless' from='hiran@xmpp.libretank.org/4802130238238409943552226' type='chat'> <x xmlns='http://jabber.org/protocol/muc#user'> </x> <CommodityParcel xmlns='org.oolite.communicator.parcel' commodity='machinery' amount='1'> </CommodityParcel> </message>
  261. hiran There is a builder.getStanzaId() method, but nothing to set the id.
  262. alacer has left
  263. Alex has joined
  264. hiran Is it possible that only messages typed 'groupchat' do get an ID?
  265. alacer has joined
  266. alacer has left
  267. flow hiran, you don't need to set an ID if you don't make use of it
  268. flow and the fact that you currently work with IDless stanzas makes me believe that you don't need it
  269. hiran In case I want to send a response it might make sense to have IDs. Or when else would I need them?
  270. flow hiran, message delivery receipts are a prime example
  271. hiran Ok, then I will look that up
  272. flow hiran> There is a builder.getStanzaId() method, but nothing to set the id. see StanzaBuilder.buildMessage(String stanzaId)
  273. antranigv has left
  274. antranigv has joined
  275. hiran No! I did not expect that! LOL
  276. hiran Now THAT makes it straightforward again
  277. flow hiran, how are those ID-less custom messages constructed?
  278. hiran They are constructed like this: MessageBuilder builder = StanzaBuilder.buildMessage(); builder.addExtension(new MUCUser()); builder.to(recipient); builder.ofType(Message.Type.chat); builder.addExtension(new OoliteCommodityParcelExtension(commodity, amount)); connection.sendStanza(builder.build()); // send private message via connection, NOT via muc
  279. hiran So yes, I can change the first line and define an ID.
  280. flow hiran, you want "XMPPConnection.getSTanzaFactory()", which will set unique IDs for you
  281. flow unique per stream that is
  282. hiran Oh that would be great already. I will give it a try
  283. hiran I just changed the first line into MessageBuilder builder = StanzaBuilder.buildMessage("stanzaID"); and this is what I get in the logs now: <message xml:lang='en-US' to='hiran@xmpp.libretank.org/4168521073172461441552738' from='oolite@muc.xmpp.libretank.org/Mogli/Hopeless' type='chat' id='stanzaID'> <x xmlns='http://jabber.org/protocol/muc#user'/> <CommodityParcel xmlns='org.oolite.communicator.parcel' commodity='liquor_wines' amount='1'/> </message> So setting the ID works. Going for the factory now...
  284. flow hiran, so basically, in your example code above, replace 'StanzaBuilder' with 'connection.getStanzaFactory()'
  285. hiran It works. First line is now MessageBuilder builder = connection.getStanzaFactory().buildMessageStanza(); and the result <message to='oolite@muc.xmpp.libretank.org/Mogli/Hopeless' from='hiran@xmpp.libretank.org/12184814512061696210552866' id='AWFNU-9' type='chat'> <x xmlns='http://jabber.org/protocol/muc#user'> </x> <CommodityParcel xmlns='org.oolite.communicator.parcel' commodity='textiles' amount='1'> </CommodityParcel> </message>
  286. hiran Thank you flow :-)
  287. antranigv has left
  288. antranigv has joined
  289. antranigv has left
  290. antranigv has joined
  291. scorch has left
  292. antranigv has left
  293. antranigv has joined
  294. antranigv has left
  295. scorch has joined
  296. flow hiran, you are welcome
  297. scorch has left
  298. dezant has left
  299. scorch has joined
  300. dezant has joined
  301. moparisthebest has joined
  302. pulkomandy has joined
  303. me9 has joined
  304. pulkomandy has left
  305. pulkomandy has joined
  306. antranigv has joined
  307. Sam has left
  308. Sam has joined
  309. DebXWoody has left
  310. _Liveware Problem_ has joined
  311. hiran has left
  312. rom1dep has left
  313. rom1dep has joined
  314. nephele has left
  315. jgart has joined
  316. hiran has joined
  317. antranigv has left
  318. antranigv has joined
  319. antranigv has left
  320. dezant has left
  321. dezant has joined
  322. spectrum has joined
  323. antranigv has joined
  324. antranigv has left
  325. antranigv has joined
  326. antranigv has left
  327. antranigv has joined
  328. alex-a-soto has left
  329. alex-a-soto has joined
  330. emus has left
  331. jgart has left
  332. laylolamb has left
  333. laylolamb has joined
  334. debacle has left
  335. goffi has left
  336. dezant has left
  337. dezant has joined
  338. Duncan Hart has joined
  339. hiran has left
  340. laylolamb has left
  341. laylolamb has joined
  342. emus has joined
  343. _Liveware Problem_ has left
  344. laylolamb has left
  345. laylolamb has joined
  346. Duncan Hart has left
  347. Duncan Hart has joined
  348. laylolamb has left
  349. laylolamb has joined