jdev - 2021-02-28


  1. suohua has joined
  2. Zash has left
  3. Zash has joined
  4. paul has left
  5. belong has left
  6. raghavgururajan has joined
  7. COM8 has left
  8. lovetox_ has left
  9. belong has joined
  10. debacle has left
  11. belong has left
  12. belong has joined
  13. mikeye has joined
  14. tiaod has left
  15. SouL has left
  16. mikeye has left
  17. wurstsalat has joined
  18. fade123 has left
  19. Vaulor has left
  20. Vaulor has joined
  21. mac has joined
  22. suohua has left
  23. wurstsalat has left
  24. larma has left
  25. larma has joined
  26. mikeye has joined
  27. mikeye has left
  28. mikeye has joined
  29. SouL has joined
  30. Ge0rG has left
  31. Ge0rG has joined
  32. mikeye has left
  33. mac has left
  34. lovetox_ has joined
  35. lovetox_ has left
  36. lovetox_ has joined
  37. kikuchiyo has left
  38. goffi has joined
  39. kikuchiyo has joined
  40. mikeye has joined
  41. tiaod has joined
  42. John has joined
  43. John has left
  44. John has joined
  45. John has left
  46. John has joined
  47. John has left
  48. asterix has left
  49. asterix has joined
  50. belong has left
  51. mikeye has left
  52. mikeye has joined
  53. Martin has left
  54. Martin has joined
  55. tsk has left
  56. tsk has joined
  57. COM8 has joined
  58. mikeye has left
  59. debacle has joined
  60. oibalos has joined
  61. goffi has left
  62. goffi has joined
  63. tiaod has left
  64. tiaod has joined
  65. tiaod has left
  66. wurstsalat has joined
  67. mikeye has joined
  68. goffi has left
  69. tiaod has joined
  70. tiaod has left
  71. tiaod has joined
  72. paul has joined
  73. mikeye has left
  74. asterix has left
  75. asterix has joined
  76. asterix has left
  77. asterix has joined
  78. belong has joined
  79. mikeye has joined
  80. lovetox_ has left
  81. marmistrz has joined
  82. lovetox_ has joined
  83. pasdesushi has joined
  84. asterix has left
  85. asterix has joined
  86. pasdesushi has left
  87. pasdesushi has joined
  88. asterix has left
  89. asterix has joined
  90. goffi has joined
  91. COM8 has left
  92. pasdesushi has left
  93. lovetox_ has left
  94. asterix has left
  95. asterix has joined
  96. Guus has joined
  97. Guus has left
  98. floretta has left
  99. Martin What would you consider a reasonable timeout for connecting to an xmpp server?
  100. floretta has joined
  101. lovetox in total?
  102. lovetox or to one connection point before you try the next
  103. lovetox actually i dont think i have a timeout
  104. Freddy has joined
  105. lovetox not sure why i should, if i cant connect it does not change anything if i abort after a timeout, its not like i can suddenly connect after trying again
  106. lovetox but i guess there is a timeout usually from your network libs
  107. lovetox so i take whatever they do and when the return with "could not reach remote" or whatever
  108. Sam Whited lovetox: presumably you want to go back to the start screen and say "Something's wrong, please wait and try again later" or something eventually right, and not just say "Connecting" forever even though it will never happen?
  109. Sam Whited eg. if something was broken and the server stops responding, or the TCP connection hangs, or any number of other things happen.
  110. lovetox hm its not like it will be stuck there forever though
  111. Sam Whited Why not?
  112. Sam Whited The point of a timeout isn't in case you hit an actual error, it's in case it gets stuck forever :)
  113. lovetox because usually if you open a socket to some server, the network lib tells you after some time that something does not work
  114. lovetox so yeah maybe these libs have timeouts implemented already
  115. Martin lovetox: The timeout before trying to connect to the next port (SRV records).
  116. Sam Whited That's fine if it's at the TCP layer, not if you're connecting to something that's accidentally slow loris-ing you because it's overprovisioned and is returning 1 byte per minute or something very slowly by mistake
  117. lovetox dont know how they determine that a host is not reachable
  118. lovetox sorry Martin i dont do this right now
  119. Sam Whited ah okay, those are two different things though. Between SRV records I'm not sure
  120. lovetox_ has joined
  121. lovetox_ has left
  122. Sam Whited I don't actually know if people treat different ports on the same host as different resources for rate limiting purposes, I would assume not. So maybe exponential fallback starting with 10ms or something would be a good baseline?
  123. Martin I just set it to 10 seconds while playing right now. Prior to setting it I blocked outgoing traffic on 5222 and it didn't continue for a minute, so whatever the underlying network libs use for a timeout, it seems to be terribly high.
  124. mikeye has left
  125. Martin But I think I'd rather set it to 1s or so.
  126. Sam Whited Your network library waits 10 seconds before trying the next thing in a set of SRV records? That does seem like a long time.
  127. Martin No, I set it to 10 seconds to speed things up. According to mattn/go-xmpp there is no timeout when you don't set it. But I don't know if there will apply a timeout from the underlying network libs.
  128. Sam Whited Oh, you mean it will jus tinstantly reconnect to the next one by default?
  129. Martin So it seems I would be stuck forever if I can't connect to the first record and don't set a timeout.
  130. Sam Whited oops, too soon, not instantly, stuck forever. Gotcha.
  131. Martin But just trying all xmpp-client records, then all xmpps-client records is surprisingly easy. I'm not yet sure whether I should try xmpp on 5222 and xmpps on 5223+443 if no SRV records are provided. How is the common sense?
  132. Sam Whited That's technically what people do as a fallback if no srv records are provided, but there was some discussion recently that it was a mistake. Right now I do that in my library too, but I keep going back and forth on whether it's worth it.
  133. Sam Whited See https://tools.ietf.org/html/rfc6120#section-3.2.2
  134. Martin You can still specify it manually with `--jserver=example.com:5222` so maybe I should not bother and just use SRV records and don't care about fallbacks.
  135. tiaod has left
  136. Sam Whited That sounds sane to me, FWIW
  137. tiaod has joined
  138. Sam Whited Or if there are no SRV records it would make sense to default to using that
  139. tiaod has left
  140. debacle has left
  141. Martin I'll think about it. Thanks for your input. :)
  142. tiaod has joined
  143. tiaod has left
  144. Sam Whited Sure thing; let us know what you decide, I keep changing my mind on how I should do this too so I'll be curious what you do.
  145. Martin I tend to use 5222 if there are no srv records as I think servers either use the standard port or provide srv records.
  146. mikeye has joined
  147. tiaod has joined
  148. pasdesushi has joined
  149. pasdesushi has left
  150. pasdesushi has joined
  151. defanor I think it's nice to let the underlying system to decide on TCP timeouts, since those can be tweaked per-system and system-wide, depending on its connection or requirements. But as reference values, RFC 1122 suggests at least 100 seconds, and Linux's tcp(7) mentions the default of about 13 to 30 minutes.
  152. Sam Whited I thought he was asking how long to wait between connection attempts to different SRV records, not for TCP timeouts, but maybe I'm still confused.
  153. Martin I really don't want to wait for minutes while my tool tries to connect. Rather try the next srv record.
  154. defanor Oh, after a failure, and before trying the next one? Why to wait between those at all?
  155. Sam Whited Maybe you shouldn't, I'm not really sure. But if all the SRV records are just different ways to connect to the same service you may want to wait to avoid triggering rate limiting (this is why the old xmpp.net scanner waited, IIRC)
  156. Martin When I locally blocked outgoing traffic on 5222 and had no timeout set it didn't go on to the next srv record for one minute. That's why I added a timeout of 1s now as I want to try the next port quickly if I can't connect there.
  157. defanor One solution may be to extend "happy eyeballs" to cross SRV records. To neither give up on connections too quickly, nor wait too much if others are available.
  158. Sam Whited This doesn't include timeouts, but I think this is up to date if you're curious how we're connecting: https://mellium.im/issue/2#issuecomment-735241044
  159. mikeye has left
  160. lovetox defanor, yeah but happy eyeballs does not do this
  161. lovetox and i think its even for a xmpp lib kind of advanced to implement happy eyeballs themself, not to speak from extending it to multipls srvs
  162. lovetox im in luck that GLib supports happy eyeballs with just passing a srv record
  163. lovetox but they fixed multiple bugs over the years on that code
  164. lovetox i also think there is not much use for this cross srv thing in the wilid
  165. lovetox i also think there is not much use for this cross srv thing in the wild
  166. pasdesushi has left
  167. pasdesushi has joined
  168. pasdesushi has left
  169. pasdesushi has joined
  170. pasdesushi has left
  171. pasdesushi has joined
  172. pasdesushi has left
  173. pasdesushi has joined
  174. Martin > This doesn't include timeouts, but I think this is up to date if you're curious how we're connecting: https://mellium.im/issue/2#issuecomment-735241044 You look up xmpp and xmpps records in parallell?
  175. Sam Whited I look up both records in parallel, then try xmpps first if they existed
  176. pasdesushi has left
  177. Martin I look up xmpp-client records, try them and if I can't connect look up xmpps-client records and connect. Should xmpps-client have higher priority?
  178. pasdesushi has joined
  179. kikuchiyo has left
  180. defanor The XEP suggests to mix them, so that priorities would be defined by a hostmaster. I was lazy to do that, and just prioritising xmpps too for now (after querying them in parallel as well).
  181. kikuchiyo has joined
  182. pasdesushi has left
  183. marmistrz has left
  184. marmistrz has joined
  185. larma has left
  186. Sam Whited The XEP is wrong IMO. It's breaking the SRV RFC and just makes no sense with how SRV records work.
  187. fredyy has joined
  188. Sam Whited I personally try xmpps-client first, but I'm not sure that it matters. In theory if xmpp-client is first you could negotiate without STARTTLS when TLS is available (if you support plain connections, which you shouldn't or should at least hide it behind some kind of flag or option)
  189. Zash There's prior art in the SRV for email RFC IIRC
  190. Zash Whether it's a good idea not is a separate issue
  191. Sam Whited TIL: email discovery with SRV.
  192. Sam Whited huh, fair enough, it recommends mixing imap, imaps, pop3, and pop3s.
  193. shaarad has joined
  194. Sam Whited This RFC makes it *much* clearer how priorities and weights are supposed to be used, it's somewhat convincing. Although it still seems like it's just unnecessary difficulty because libraries that query and connect aren't going to support this most likely.
  195. moparisthebest How can xep368 be more clear in that aspect?
  196. moparisthebest Crap libraries exist is not a reason to change a spec I think
  197. Sam Whited This isn't crap libraries, this is the standard library of every programming langauge I've ever used, I think.
  198. moparisthebest It's ok, standard libraries can be crap too
  199. Sam Whited Actually, maybe not the standard library, but everything that does SRV.
  200. Zash Sam Whited, hold on, you're saying there's languages with SRV support? Other than Go?
  201. Sam Whited Zash: that's why I said "maybe SRV libraries", I realized I'm not sure outside of Go if I had to download something else or not :)
  202. Sam Whited But still, LookupSRV(service, proto, name) seems sane and simple. Having to provide multiple isn't something I've ever seen done because the SRV RFCs don't work that way.
  203. Zash The Go network lib is the only I've ever seen, with actual SRV aware connection support. Not counting pure DNS libraries.
  204. moparisthebest This is the only way to do it with SRV, but SRV2 fixes this by letting you specify *how* to connect to each endpoint
  205. Sam Whited moparisthebest: or don't do it and just say "Prefer this one if supported or then look up this other one"
  206. Sam Whited Or leave it entirely up to the clients which one to do first.
  207. moparisthebest "never do new things" is not a good process to follow, but in this case, this wasn't even a new thing
  208. moparisthebest That's what it says
  209. Sam Whited I didn't say "never do new things" just "don't do things that the SRV RFC didn't anticipate because it makes it needlessly difficult for no reason"
  210. moparisthebest You should mix them, if you don't want to, do whatever, have fun
  211. moparisthebest It might even be a may now?
  212. Sam Whited It did have a MAY I think.
  213. Sam Whited Well, it's a SHOULD, but then had a "MAY" for "or you can ignore this"
  214. Sam Whited NOt really sure what that means
  215. moparisthebest It's not needlessly difficult, it's not difficult at all actually
  216. moparisthebest Just because some go library programmer didn't anticipate it
  217. Sam Whited It is because I have to re-implement all the sorting and stuff instead of just calling LookupSRV (or the equivalent in your DNS Library of choice)
  218. Sam Whited It's not a Go thing, it's the SRV RFCs and literally every library.
  219. moparisthebest If you have your own srv code it's a 2 minute change
  220. moparisthebest I know because I made the change in Conversations
  221. Zash 2 minutes to what?
  222. Sam Whited I don't want my own SRV code, I want to download a DNS library and make queries and get back to writing XMPP stuff.
  223. Sam Whited Even if it is 2 minutes it's 2 minutes I shouldn't have had to do.
  224. moparisthebest 2 minutes to look up another record, and mix them
  225. Zash and keep track of if it's the 's' variant
  226. shaarad has left
  227. Sam Whited And not accidentally be buggy and do the wrong thing, or mix the ports wrong, etc. and write tests for all of it, and… I'm not saying it's impossible, or even hard, just that it's extra stuff that could have been done for me.
  228. moparisthebest Sam Whited: I could say I don't want to implement my own styling library, after all, that's much harder than this
  229. moparisthebest Guess we should have just used html since that would have been easier :D
  230. Sam Whited Lots of things are harder than this, we can talk about saving time there too maybe, but right now we're talking about this and the way literally every library does things and the way the SRV RFC makes it sound.
  231. Sam Whited That's a strawman, we discussed that and "it's easier" was in fact a valid argument for HTML.
  232. moparisthebest Except the ones mentioned
  233. Sam Whited Obviously SRV records does not have the same other concerns though.
  234. Sam Whited What ones mentioned?
  235. moparisthebest And the author of srv took a look and said he thought it was fine
  236. moparisthebest Email
  237. Sam Whited Right; just one other thing does it this way, but no library does and as far as I can tell the SRV RFC sounds like it defeats the point.
  238. moparisthebest I've never seen a library that does SRV at all
  239. moparisthebest But regardless, it's optional, feel free to do whatever you want
  240. Sam Whited Sure, and I do, I'm just not sure the XEP should confuse people into doing something that adds a ton of edge cases either way. Though like I said, the email RFC at least has some justification for it so we'll see, maybe I'll come around.
  241. moparisthebest The reason it ends up being optional is "client doing whatever they want" and "client being behind restrictive firewall" is indistinguishable to the server operator anyway
  242. Sam Whited makes sense
  243. moparisthebest Like I said if you already write your own (trivial) srv code mixing these in is equally trivial
  244. Sam Whited "trivial" is never a good argument for "add more code".
  245. Sam Whited I mean, if there's some compelling reason to do it that's fine, but "it's easy so why not?" just isn't that. That's how bugs get introduced.
  246. Sam Whited Not to mention that now it's a lot of SRVs to read and code and tests to write and edge cases to handle, so I don't believe for a second that this is "trivial" just because it's easier than some other things.
  247. Sam Whited (FWIW, I did also implement this at one point and then changed it, it wasn't the most difficult thing in the world, sure, but it's not "trivial" by any means)
  248. Sam Whited moparisthebest: ignoring all this for a minute, what is the purpose of letting the server decide between STARTTLS and implicit TLS? It just occured to me, I don't even know why it would make a difference (assuming both are supported, if one isn't it will be a '.' record either way or have no response so it won't matter regardless of mixing/connection strategy)
  249. Freddy has left
  250. kikuchiyo has left
  251. moparisthebest Sam Whited: just because SRV let's server set priority and weight, that made sense to carry forward
  252. belong has left
  253. belong has joined
  254. pasdesushi has joined
  255. kikuchiyo has joined
  256. pasdesushi has left
  257. mac has joined
  258. lovetox Zash‎: The Go network lib is the only I've ever seen, with actual SRV aware connection support
  259. lovetox > Zash‎: The Go network lib is the only I've ever seen, with actual SRV aware connection support
  260. lovetox does this count in GLib
  261. lovetox https://lazka.github.io/pgi-docs/#Gio-2.0/classes/SocketClient.html#Gio.SocketClient.connect_to_service_async
  262. lovetox Gio.SocketClient.connect_to_service_async(example.net, "xmpps-client", ....)
  263. Zash Never used GLib, so hadn't seen that. But yeah, that's two.
  264. lovetox it resolves, afterwards does happy eyeballs
  265. lovetox thats the reason i dont do the mixing, this method exists its a oneliner for me
  266. lovetox doing the mixing, means i cant use that and now have to implement a lot myself
  267. lovetox fuck that
  268. lovetox :)
  269. fade123 has joined
  270. mac has left
  271. mac has joined
  272. Freddy has joined
  273. adityaborikar has left
  274. adityaborikar has joined
  275. Freddy has left
  276. Freddy has joined
  277. belong has left
  278. mac has left
  279. belong has joined
  280. lovetox_ has joined
  281. lovetox_ has left
  282. lovetox_ has joined
  283. lovetox_ has left
  284. lovetox_ has joined
  285. lovetox_ has left
  286. lovetox_ has joined
  287. lovetox_ has left
  288. lovetox_ has joined
  289. lovetox_ has left
  290. lovetox_ has joined
  291. lovetox_ has left
  292. asterix has left
  293. asterix has joined
  294. pasdesushi has joined
  295. lovetox_ has joined
  296. pasdesushi has left
  297. kikuchiyo has left
  298. pasdesushi has joined
  299. pasdesushi has left
  300. pasdesushi has joined
  301. pasdesushi has left
  302. asterix has left
  303. asterix has joined
  304. asterix has left
  305. asterix has joined
  306. asterix has left
  307. asterix has joined
  308. asterix has left
  309. asterix has joined
  310. asterix has left
  311. asterix has joined
  312. asterix has left
  313. asterix has joined
  314. asterix has left
  315. asterix has joined
  316. asterix has left
  317. asterix has joined
  318. asterix has left
  319. asterix has joined
  320. belong has left
  321. asterix has left
  322. asterix has joined
  323. asterix has left
  324. asterix has joined
  325. asterix has left
  326. asterix has joined
  327. asterix has left
  328. asterix has joined
  329. belong has joined
  330. asterix has left
  331. asterix has joined
  332. asterix has left
  333. asterix has joined
  334. asterix has left
  335. asterix has joined
  336. asterix has left
  337. asterix has joined
  338. tiaod has left
  339. tiaod has joined
  340. asterix has left
  341. asterix has joined
  342. belong has left
  343. asterix has left
  344. asterix has joined
  345. belong has joined
  346. belong has left
  347. belong has joined
  348. xecks has left
  349. xecks has joined
  350. belong has left
  351. debacle has joined
  352. marmistrz has left
  353. belong has joined
  354. oibalos has left
  355. lovetox_ has left
  356. oibalos has joined
  357. marmistrz has joined
  358. alacer has joined
  359. alex-a-soto has joined
  360. fade123 has left
  361. alex-a-soto has left
  362. fade123 has joined
  363. lovetox_ has joined
  364. lovetox_ has left
  365. alex-a-soto has joined
  366. fade123 has left
  367. fade123 has joined
  368. fredyy has left
  369. goffi has left
  370. floretta has left
  371. mac has joined
  372. oibalos has left
  373. mac has left
  374. pasdesushi has joined
  375. asterix has left
  376. asterix has joined
  377. asterix has left
  378. asterix has joined
  379. marmistrz has left
  380. oibalos has joined
  381. pasdesushi has left
  382. pasdesushi has joined
  383. pasdesushi has left
  384. pasdesushi has joined
  385. pasdesushi has left
  386. pasdesushi has joined
  387. pasdesushi has left
  388. pasdesushi has joined
  389. pasdesushi has left
  390. pasdesushi has joined
  391. pasdesushi has left
  392. pasdesushi has joined
  393. pasdesushi has left
  394. raghavgururajan has left
  395. raghavgururajan has joined
  396. wurstsalat has left
  397. fade123 has left
  398. tiaod has left
  399. tiaod has joined
  400. asterix has left
  401. asterix has joined
  402. oibalos has left
  403. lovetox has left
  404. lovetox has joined
  405. eta has left
  406. kikuchiyo has joined
  407. asterix has left
  408. xecks has left
  409. asterix has joined
  410. tiaod has left
  411. tiaod has joined
  412. eta has joined
  413. debacle has left