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 NN
  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