jdev - 2022-01-31

  1. qwestion has joined

  2. qwestion has left

  3. qwestion has joined

  4. doge has left

  5. atomicwatch has joined

  6. dezant has joined

  7. doge has joined

  8. doge has left

  9. suohua has joined

  10. qwestion has left

  11. qwestion has joined

  12. qwestion has left

  13. me9 has left

  14. emus has left

  15. sonny has left

  16. sonny has joined

  17. atomicwatch has left

  18. atomicwatch has joined

  19. SouL has joined

  20. Millesimus has left

  21. doge has joined

  22. mac has joined

  23. doge has left

  24. doge has joined

  25. wurstsalat has left

  26. al has joined

  27. J Marinaro has left

  28. J Marinaro has joined

  29. doge has left

  30. Millesimus has joined

  31. J Marinaro has left

  32. J Marinaro has joined

  33. J Marinaro has left

  34. J Marinaro has joined

  35. xnamed has left

  36. suohua has left

  37. doge has joined

  38. debacle has left

  39. suohua has joined

  40. sonny has left

  41. sonny has joined

  42. mac has left

  43. mac has joined

  44. SouL has left

  45. Kev has left

  46. Kev has joined

  47. larma has left

  48. nephele has joined

  49. nephele has left

  50. nephele has joined

  51. doge has left

  52. nephele has left

  53. sonny has left

  54. sonny has joined

  55. al has left

  56. mac has left

  57. mac has joined

  58. mac has left

  59. mac has joined

  60. marc0s has left

  61. marc0s has joined

  62. qy has left

  63. qy has joined

  64. doge has joined

  65. qwestion has joined

  66. qy has left

  67. qy has joined

  68. jgart has left

  69. Yagizа has joined

  70. doge has left

  71. doge has joined

  72. doge has left

  73. suohua has left

  74. suohua has joined

  75. doge has joined

  76. doge has left

  77. Vaulor has joined

  78. suohua has left

  79. suohua has joined

  80. suohua has left

  81. suohua has joined

  82. atomicwatch has left

  83. atomicwatch has joined

  84. suohua has left

  85. SouL has joined

  86. kikuchiyo has left

  87. nephele has joined

  88. kikuchiyo has joined

  89. nephele has left

  90. xecks has left

  91. mac has left

  92. msavoritias has joined

  93. qwestion has left

  94. Millesimus has left

  95. jubalh has joined

  96. marmistrz has joined

  97. xecks has joined

  98. Yagizа has left

  99. Yagizа has joined

  100. dezant has left

  101. wurstsalat has joined

  102. Apollo has left

  103. rafasaurus has left

  104. rafasaurus has joined

  105. Apollo has joined

  106. emus has joined

  107. goffi has joined

  108. dezant has joined

  109. mac has joined

  110. thomaslewis has left

  111. flow

    note that there is also message-based IBB, which appears to be not negotiated (maybe it should be)

  112. goffi has left

  113. goffi has joined

  114. jonas’

    flow, should it? IBB is always used within the context of another protocol, so it should be that protocol's job to figure it out (for instance, jingle)

  115. flow

    I think so yes, mostly because I don't see much of reason for message based IBB (besides not having to implement IQ semantics, which appears to be a weak argument)

  116. flow

    and being able to throttle IBB transfers by delaying the IQ response seems like a very important mechanism to have (not saying that each and every implementation has to use it)

  117. Alex has joined

  118. nephele has joined

  119. nephele has left

  120. nephele has joined

  121. rafasaurus has left

  122. nephele has left

  123. nephele has joined

  124. inky has left

  125. nephele has left

  126. Yagizа has left

  127. Yagizа has joined

  128. rafasaurus has joined

  129. goffi has left

  130. goffi has joined

  131. inky has joined

  132. mac has left

  133. mac has joined

  134. Laura has left

  135. Laura has joined

  136. Stefan has left

  137. Stefan has joined

  138. homebeach has left

  139. Matrix Traveler (bot) has left

  140. Matrix Traveler (bot) has joined

  141. homebeach has joined

  142. atomicwatch has left

  143. Neustradamus has joined

  144. atomicwatch has joined

  145. marmistrz has left

  146. marmistrz has joined

  147. 9lakes has left

  148. Apollo has left

  149. rom1dep has left

  150. rom1dep has joined

  151. Martin has left

  152. Martin has joined

  153. huhn has joined

  154. 9lakes has joined

  155. Wojtek has joined

  156. larma has joined

  157. mac has left

  158. mac has joined

  159. Apollo has joined

  160. spectrum has left

  161. marmistrz has left

  162. mac has left

  163. homebeach has left

  164. Matrix Traveler (bot) has left

  165. Matrix Traveler (bot) has joined

  166. homebeach has joined

  167. al has joined

  168. marc0s has left

  169. marc0s has joined

  170. huhn has left

  171. antranigv has joined

  172. huhn has joined

  173. antranigv has left

  174. antranigv has joined

  175. debacle has joined

  176. antranigv has left

  177. antranigv has joined

  178. raghavgururajan has joined

  179. mac has joined

  180. suohua has joined

  181. Sam

    I was thinking more about this yesterday and I think I'm just going to implement the error. Even if the other side doesn't understand it and terminates the connection, which isn't ideal, it's all I can do really. I still don't want to allow unrestricted buffer growth

  182. Millesimus has joined

  183. nephele has joined

  184. nephele has left

  185. Sam

    From the clients perspective I'm not sure that throttling gets you much since there aren't negotiated timeouts, so if you hold the IQ that would put you over your data query it may just time out and you'll receive it again and again

  186. Zash

    What buffer are you talking about?

  187. mh has left

  188. jonas’

    wait, clients re-send IQs which timed out?

  189. jonas’

    I sure hope not

  190. jonas’

    not by default anyway

  191. antranigv has left

  192. Kev

    I've not met one that does, that sounds like a terrible idea.

  193. Sam

    I dunno, maybe? Either way they either resend it or cancel the connection, a wait error at least indicates that they *should* resend it (even though they still might not if they don't support it), so same thing but slightly better

  194. spectrum has joined

  195. Sam

    oops, I meant the buffer of received data

  196. marc0s has left

  197. marc0s has joined

  198. Sam

    If for some reason it's not being read fast enough, I don't want that buffer to grow indefinitely, so at some point we limit it and I'm trying to figure out what to do in that case where it's maxed out and we can't receive more data until some gets read

  199. jonas’

    how about the lib doesn't buffer at all, but offers only a callback instead? :)

  200. antranigv has joined

  201. Zash

    Something Promise-ish? I imagine usually the data would go through the buffer and then into a file write or such. Returning the iq-response after writing might have sensible self-regulating effects I would think?

  202. Sam

    I thought about it, but I didn't like the semantics of that as much. I want to give the user stream semantics, not make them do it all themselves. Ie. I did an experiment with doing jingle and it was a *lot* easier if the underlying transports all had the same stream semantics

  203. cdcode has joined

  204. Sam

    Writing the IQ-response after the data gets written somewhere else (or from our perspective after it gets read) is the other option, but I think I'm more worried about IQ timeouts and the unknown of whatever that means for the connection state

  205. suohua has left

  206. Zash

    I wouldn't worry about timeouts.

  207. Sam

    Why's that? Wouldn't it cause problems?

  208. jonas’

    timeouts are always wrong

  209. msavoritias has left

  210. msavoritias has joined

  211. jonas’

    so making them more or less wrong on the responder side doesn't matter ;)

  212. msavoritias has left

  213. msavoritias has joined

  214. Sam

    Sure, but they exist and I feel like both sides have to agree what they mean if the stream is to continue

  215. Sam


  216. Sam

    Oops, I can never remember how to scroll in Mcabber despite doing it all the time.

  217. Sam

    The other problem is that if I hold the response, the other end times out waiting for it, and their response is to send the next packet I effectively end up just buffering it all anyways waiting for the data to be decoded and written

  218. al has left

  219. Sam

    I dunno, maybe it doesn't matter until I have a practical use for this or someone else starts using it.

  220. suohua has joined

  221. flow

    sending the next IBB data IQ if the response of previous times out doesn't appear the right thing to do™

  222. marc0s has left

  223. marc0s has joined

  224. Sam

    That doesn't mean the other side won't do it; the spec specifically says you don't have to wait for responses

  225. flow

    besides the case where the sender sends multiple IBB data IQs at once

  226. flow

    Sam, not arguing that there could be implementations that behave that way, just saying that it's probably not sensible

  227. marc0s has left

  228. marc0s has joined

  229. Sam

    Yah, totally agree; maybe it's worth clarifying the spec to say "this is how you say *back off*", or maybe that's just unnecessary complexity and I should just let the buffer grow

  230. Sam

    Let whatever larger protocol is using IBB deal with this.

  231. mac has left

  232. flow

    unbounded buffer grow also doesn't sound very appealing

  233. flow

    being able to delay the IBB IQ response is IMHO very sensible and sending entities should consider that

  234. Zash

    how weird would it be to throttle reading from your TCP connection?

  235. flow

    that said, I believe many implementations are just fine without

  236. Sam

    Indeed (to both of those)

  237. flow

    Zash, weird in a way that you would throttle everything that goes over that TCP connection

  238. Sam

    Throttling at the tcp level wouldn't necessarily fix the problem though, and would back up all the stanzas afterwards

  239. Sam

    Throttling in general wouldn't really fix it; you still might be reading slower than the throttled writes are coming in.

  240. flow

    well throttling also could mean annoucing a window size of 0, so hopefully there would be no more incoming writes coming in

  241. Millesimus has left

  242. flow

    where "window size" here refers to a concept on the XMPP layer, not the TCP window size

  243. flow

    in general, besides delaying the IBB IQ response, the IQ response could contain the remaining capacity of the buffer (or something similar)

  244. flow

    of course, we then would lack a mechanism to annouce that the capacity changes from zero to non-zero

  245. flow

    of course, we then would lack a mechanism to annouce that the capacity changed from zero to non-zero

  246. Sam

    Maybe I should just see what other implementations are doing (if anything) and do whatever that is

  247. flow

    I wanted to look what Smack does, but sadly did not had the time yet

  248. MattJ has left

  249. Sam

    Interesting; when I get a "close" from the other side I flush any data, Smack appears to consider the entire connection already closed and doesn't do that

  250. Sam

    Not sure that it matters, I just assumed my side wasn't closed until the close response goes through

  251. Kev

    I believe (from memory) that the RFC tells you what to do when sending closes (and I *think* it tells you to wait for the other side's close, but would need to check)

  252. Millesimus has joined

  253. debacle has left

  254. homebeach has left

  255. Matrix Traveler (bot) has left

  256. Matrix Traveler (bot) has joined

  257. homebeach has joined

  258. Sam

    flow: Smack appears to only buffer at max one block size; I'm not sure what it does if the buffer hasn't been cleared yet, block I guess, so maybe it's doing the IQ wait thing

  259. msavoritias has left

  260. msavoritias has joined

  261. Sam

    there's some sort of separate data queue, I guess I should go see if that has a limit

  262. Sam

    (doesn't seem to)

  263. Sam

    So nevermind, maybe smack just has unbounded buffer growth

  264. marc0s has left

  265. marc0s has joined

  266. PapaTutuWawa has joined

  267. goffi has left

  268. goffi has joined

  269. alacer has left

  270. alacer has joined

  271. larma has left

  272. goffi has left

  273. goffi has joined

  274. mh has joined

  275. SouL has left

  276. mac has joined

  277. wurstsalat has left

  278. SouL has joined

  279. doge has joined

  280. doge has left

  281. wurstsalat has joined

  282. Yagizа has left

  283. dezant has left

  284. suohua has left

  285. suohua has joined

  286. dezant has joined

  287. debacle has joined

  288. doge has joined

  289. antranigv has left

  290. mac has left

  291. antranigv has joined

  292. homebeach has left

  293. Matrix Traveler (bot) has left

  294. Matrix Traveler (bot) has joined

  295. homebeach has joined

  296. nephele has joined

  297. Yagizа has joined

  298. nephele has left

  299. antranigv has left

  300. me9 has joined

  301. larma has joined

  302. doge has left

  303. wurstsalat has left

  304. wurstsalat has joined

  305. xnamed has joined

  306. Wojtek has left

  307. Wojtek has joined

  308. dezant has left

  309. dezant has joined

  310. rafasaurus has left

  311. J Marinaro has left

  312. rafasaurus has joined

  313. serge90 has left

  314. J Marinaro has joined

  315. mac has joined

  316. antranigv has joined

  317. moparisthebest

    Sam: you can have stream semantics with a bounded buffer right? If it's full the write just blocks/writes nothing? That's how all stream APIs I can think of work anyway

  318. FireFly has left

  319. FireFly has joined

  320. Sam

    moparisthebest: this is for reads, but we actually do block from the users perspective. Ie. if data comes in via an IQ and there's space in the buffer we write it to the buffer. If there's not enough space left, I'm trying to figure out what to do. From the users perspective if there's anything in the buffer we read from it. If there's nothing in the buffer we block until something gets written to the buffer then we read it.

  321. mac has left

  322. Wojtek has left

  323. Wojtek has joined

  324. suohua has left

  325. moparisthebest

    ah yea, hairy situation

  326. xnamed has left

  327. marc0s has left

  328. marc0s has joined

  329. flow

    Sam, it appears Smack has an unbounded queue here, which is far from ideal. so yes, it is similar to an unbounded buffer

  330. xnamed has joined

  331. msavoritias has left

  332. suohua has joined

  333. mac has joined

  334. marc0s has left

  335. marc0s has joined

  336. marc0s has left

  337. marc0s has joined

  338. flow

    (technically the queue is not unbounded, but INT32_MAX bounded, but still)

  339. xnamed has left

  340. thomaslewis has joined

  341. PapaTutuWawa has left

  342. suohua has left

  343. thomaslewis has left

  344. jubalh has left

  345. xnamed has joined

  346. suohua has joined

  347. southerntofu has left

  348. southerntofu has joined

  349. thomaslewis has joined

  350. thomaslewis has left

  351. suohua has left

  352. emus has left

  353. paul has left

  354. qwe has joined

  355. suohua has joined

  356. dezant has left

  357. Millesimus has left

  358. emus has joined

  359. msavoritias has joined

  360. msavoritias has left

  361. msavoritias has joined

  362. suohua has left

  363. kikuchiyo has left

  364. kikuchiyo has joined

  365. qwe has left

  366. thomaslewis has joined

  367. thomaslewis has left

  368. Millesimus has joined

  369. me9 has left

  370. Laura has left

  371. PapaTutuWawa has joined

  372. suohua has joined

  373. mac has left

  374. mac has joined

  375. wurstsalat has left

  376. wurstsalat has joined

  377. mac has left

  378. mac has joined

  379. Laura has joined

  380. thomaslewis has joined

  381. thomaslewis has left

  382. Apollo has left

  383. jgart has joined

  384. jubalh has joined

  385. suohua has left

  386. suohua has joined

  387. paul has joined

  388. Apollo has joined

  389. suohua has left

  390. xecks has left

  391. mac has left

  392. antranigv has left

  393. antranigv has joined

  394. drops has left

  395. drops has joined

  396. nephele has joined

  397. nephele has left

  398. nephele has joined

  399. marc0s has left

  400. marc0s has joined

  401. nephele has left

  402. marc0s has left

  403. marc0s has joined

  404. nephele has joined

  405. nephele has left

  406. suohua has joined

  407. xecks has joined

  408. emus has left

  409. emus has joined

  410. nephele has joined

  411. antranigv has left

  412. antranigv has joined

  413. nephele has left

  414. nephele has joined

  415. thomaslewis has joined

  416. nephele has left

  417. antranigv has left

  418. Wojtek has left

  419. Wojtek has joined

  420. suohua has left

  421. marc0s has left

  422. marc0s has joined

  423. marc0s has left

  424. marc0s has joined

  425. J Marinaro has left

  426. J Marinaro has joined

  427. me9 has joined

  428. Wojtek has left

  429. Wojtek has joined

  430. marc0s has left

  431. marc0s has joined

  432. marc0s has left

  433. marc0s has joined

  434. marc0s has left

  435. marc0s has joined

  436. nephele has joined

  437. xnamed has left

  438. nephele has left

  439. nephele has joined

  440. antranigv has joined

  441. nephele has left

  442. marc0s has left

  443. marc0s has joined

  444. marc0s has left

  445. marc0s has joined

  446. mac has joined

  447. dezant has joined

  448. marc0s has left

  449. marc0s has joined

  450. marc0s has left

  451. marc0s has joined

  452. xnamed has joined

  453. Kev has left

  454. Kev has joined

  455. Millesimus has left

  456. Wojtek has left

  457. Kev has left

  458. Kev has joined

  459. me9 has left

  460. Millesimus has joined

  461. marc0s has left

  462. marc0s has joined

  463. marmistrz has joined

  464. marmistrz has left

  465. marmistrz has joined

  466. marc0s has left

  467. marc0s has joined

  468. al has joined

  469. Laura has left

  470. dezant has left

  471. selurvedu has joined

  472. Yagizа has left

  473. mac has left

  474. Alex has left

  475. Alex has joined

  476. Laura has joined

  477. selurvedu has left

  478. Millesimus has left

  479. selurvedu has joined

  480. Apollo has left

  481. cdcode has left

  482. rafasaurus has left

  483. Kev has left

  484. Kev has joined

  485. rafasaurus has joined

  486. PapaTutuWawa has left

  487. alacer has left

  488. alacer has joined

  489. Millesimus has joined

  490. kikuchiyo has left

  491. Kev has left

  492. Kev has joined

  493. thomaslewis has left

  494. kikuchiyo has joined

  495. marmistrz has left

  496. al has left

  497. Kev has left

  498. Kev has joined

  499. msavoritias has left

  500. me9 has joined

  501. jonathan has joined

  502. marc0s has left

  503. marc0s has joined

  504. SouL has left

  505. emus has left

  506. Kev has left

  507. Kev has joined

  508. goffi has left

  509. emus has joined

  510. SouL has joined

  511. antranigv has left

  512. antranigv has joined

  513. thomaslewis has joined

  514. Kev has left

  515. thomaslewis has left

  516. Kev has joined

  517. wurstsalat has left

  518. debacle has left

  519. Kev has left

  520. Kev has joined

  521. atomicwatch has left