jdev - 2024-03-11


  1. MSavoritias (fae,ve)

    > moparisthebest: jingle can for example operate with only an xmpp connection this basically ^ compared to http whatever

  2. wgreenhouse

    MSavoritias (fae,ve): oob, sims, sfs, etc. can also point to gemini or finger or whatever, I think -- anything that can be encoded as a uri

  3. MSavoritias (fae,ve)

    ah gemini would be nice :P

  4. Schimon

    Good day everyone

  5. Schimon

    Would it be correct to assume that an agent/transport (server component) JID can not return ping? I ask because a function that pings to own JID appears to indicate that the JID does not return ping, when JID is component.

  6. jonas’

    no, it is not correct to assume.

  7. jonas’

    whether a thing is a component or not has no influence on whether it implements XMPP Ping or not

  8. jonas’

    (and in any case, as pointed out elsewhere, you should _always_ get a reply, even if it is just <service-unavailable/> (indicating that ping is not implemented))

  9. Schimon

    Could it be a server fault?

  10. Schimon

    I am testing a bot which has two modes, client and component. I set the same XEPs to both (except bookmarks)

  11. MattJ

    In "bot" mode, are you sending the ping to the bare or full JID?

  12. Schimon

    MattJ, bare jid `self.boundjid.bare`, unless I specify jid, which is not the case.

  13. Schimon

    Short answer: bare jid

  14. MattJ

    Then the bot is not answering the ping when it is connected as a client

  15. MattJ

    Servers answer iq stanzas that are addressed to a user's bare JID

  16. Schimon

    No, it does

  17. MattJ

    No, the server does

  18. MattJ

    The bot will not even receive it

  19. Schimon

    MattJ, the bot response to ping, when it is client mode.

  20. Schimon

    It appears to not respond when it is in component mode

  21. MattJ

    No, the bot will not receive the ping, if the ping is addressed to the bare JID

  22. MattJ

    The server will process it, and respond instead

  23. MattJ

    In component mode this does not happen, because all traffic is simply forwarded to the component

  24. Schimon

    MattJ, suppose the component is at `rss.matt.io` and the hostname is `matt.io`. To who the ping should be addressed?

  25. MattJ

    Who are you trying to ping?

  26. Schimon

    Currently, I try to ping from `rss.matt.io` to `rss.matt.io` (i.e. itself)

  27. MattJ

    Fine, then you will receive the ping and you need to respond to it

  28. Guus

    Schimon: try setting the 'from' address in the ping that your component sends.

  29. Guus

    Schimon: you might be hitting an Openfire bug.

  30. Schimon

    Guus, that might be a good solution, like messaging and presence?

  31. MattJ

    All stanzas that a component sends MUST have a 'from' attribute

  32. Guus

    \o/ not an Openfire bug :)

  33. Schimon

    Guus, MattJ, this is the code I engage. ``` async def ping(self, jid=None): if not jid: jid = self.boundjid.bare while True: rtt = None try: rtt = await self['xep_0199'].ping(jid, timeout=10) logging.info('Success! RTT: %s', rtt) except IqError as e: logging.error('Error pinging %s: %s', jid, e.iq['error']['condition']) except IqTimeout: logging.warning('No response from %s', jid) if not rtt: logging.warning('Disconnecting...') self.disconnect() break await asyncio.sleep(60 * 1) ``` The bot constantly disconnects as a result of "failing" to receive ping.

  34. Schimon

    MattJ, Guus, thank you. I will add attribute "from"

  35. MattJ

    The most likely explanation is that you do not have code to respond to the ping

  36. Guus

    I'm seeing errors on the server that Schimon is using

  37. Guus

    > Unable to process a stanza that has no 'from' attribute

  38. MattJ

    Oh well, that also explains it :)

  39. Schimon

    This is a server kindly sponsored by Guus ;)

  40. Guus

    for client connections, Openfire will always overwrite/set the 'from' from inbound stanzas

  41. Guus

    which probably is why this _is_ working when you run in 'client' mode

  42. MattJ

    Yes, correct behaviour. External components need to explicitly set 'from' themselves.

  43. Guus

    I can see how that gets confusing fast, if you use the same bit of code for both connections.

  44. Schimon

    Guus, yes, it is the same code for both, when possible.

  45. Guus

    I don't think it hurts to _always_ set a 'from' attribute.

  46. Schimon

    Guus, yes, it is the same code for both, when possible. I habdle this with "self.is_component". ``` def send(self, jid, status_message, presence_type=None, status_type=None): jid_from = str(self.boundjid) if self.is_component else None self.send_presence(pto=jid, pfrom=jid_from, pshow=status_type, pstatus=status_message, ptype=presence_type) ```

  47. Schimon

    Great. I have found the option "ifrom" in /slixmpp/plugins/xep_0199/ping.py: ``` async def ping(self, jid: Optional[JID] =None, ifrom: Optional[JID] = None, timeout: Optional[int] = None) -> float: ```

  48. Guus

    Right, so it allows you to optionally set the 'from' attribute. That seems like a good way to resolve this.

  49. Schimon

    I am testing this right now

  50. Schimon

    It seems stable. Thank you Guus and MattJ!

  51. lovetox

    the <hash-used> element in jingle ft, do i unsterstand correctly that, i send the receiver the hash algo i will use at the end of the file transfer, so that he can also check with the same algo while he receives the file?

  52. lovetox

    do we know of any famous clients who still dont use unique message ids?

  53. lovetox

    or lets say, not even trying like 1, 2, 3, 4

  54. lovetox

    we talked once about that we need something that a client can signal that he uses unique ids

  55. lovetox

    i think the idea was to use origin-id for that and so have finaly some valid use for it

  56. singpolyma

    Psi is somewhat famous? using quite short ids