Show Idle (>14 d.) Chans


← 2022-07-24 | 2022-07-26 →
10:01 asciilifeform $ticker btc usd
10:01 busybot Current BTC price in USD: $21920.93
10:12 phf http://logs.nosuchlabs.com/log/asciilifeform/2022-07-25#1112217 << reddit knowledge is required to make online points, not actually make products
10:15 phf hmm, strangely i didn't get dulapbot packet. possibly will arrive, but it's already been a minute and it's still not here
10:15 dulapbot (asciilifeform) 2022-07-25 asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2022-07-25#1112212 << proper package support, for one thing. ( and e.g. ada's 'generic' package thing is useful, see example. ) but see also [https://www.xach.com/naggum/articles/32335327
10:16 phf and now i'm getting a bunch of getdata packets (which i'm at the moment not responding to)
10:19 phf i was unfortunately discarding them, and also not providing much detail, and by the time i patched, that's when the last message came in…
10:19 phf and *now* i got dulapbot's quote
10:20 phf so 10:12 to 10:19 est, that's 7 minutes
10:22 phf lol and a few minutes later a dupe arrives of that same dulapbot packet
10:23 phf 10:22
10:24 phf http://glyf.org/screenshots/pest-packets.png
10:33 phf kind of wish for while we're exploring pest there was a "travel path" data in packets. like each hop adds itself to a list of stations
~ 18 minutes ~
10:52 asciilifeform phf: even if packets were somehow as large as one likes, rather than mtu-sized -- a principle of pestronics is that one doesn't necessarily have any biz knowing anyffin concrete about stations with whom not directly peered
10:53 asciilifeform the 1 concession in the current protocol is the bounce counter (which, observe, is entirely promisetronic, a defective or mischevious station could set it to whatever)
10:53 phf asciilifeform, that's why i said "while exploring", because we're at least for the next few months if not longer will be observing distributed emergent behaviors of pest stations, and while that's happening it would've been useful to have "debugging information"
10:53 asciilifeform right
10:54 asciilifeform could approximate this by asking folx for debug log snippets (lemme know if need one)
10:54 asciilifeform iirc at one point awt had his 'live' to www
10:55 phf well, the interesting question is probably "how did that packet end up here" at different times
10:55 asciilifeform phf: as asciilifeform currently understands, 100% of the odd delays in messages currently are from hearsay buffering
10:56 phf like for example why did i get a dupe of dulapbot packets. i'm only connected to one station, so that stations filtering ought to not retransmit
10:56 asciilifeform indeed
10:56 phf asciilifeform, yeah, i figured it's hearsay, but why ~7 minute delay~. that's quite obv longer than hearsay spool
10:57 phf and then another 3 minutes pass and i get a dupe
10:57 asciilifeform aha, makes no obvious sense per asciilifeform's head model
10:58 * asciilifeform in experiments w/ udp, not found any instances of macroscopic propagation delay ( i.e. moar than one'd expect from 'ping time' ) from anywhere to anywhere
10:58 asciilifeform so logically this kinda thing has to be a blattaism
~ 58 minutes ~
11:57 awt I'm seeing this morning a large dump of old dulapbot log quote messages. Looks like somehow the clog was cleared.
12:03 awt http://logs.bitdash.io/pest/2022-07-25#1010349 << how often are you getting dupes? Any shared characteristics of the dupes?
12:03 bitbot Logged on 2022-07-25 10:56:15 phf[awt]: like for example why did i get a dupe of dulapbot packets. i'm only connected to one station, so that stations filtering ought to not retransmit
12:07 awt Perhaps there's a case where a getdata response is received and rebroadcast multiple times before it makes it into the long buffer.
~ 33 minutes ~
12:41 * asciilifeform neglected to nail this down in spec, but getdata responses ought not to be rebroadcast (and if they are currently being rebroadcast, oughtn't make it past stale filter, unless bug)
12:43 asciilifeform a getdata response is only useful to the requester (others, who haven't asked for that msg to be replayed, have no way to distinguish it from enemy replay)
12:54 awt blatta marks "expected" messages aka getdata responses and at least tries not to rebroadcast them.
12:55 asciilifeform awt: seems that it'd be simple to unambiguously identify'em, neh
12:55 awt This message in particular was actually not a getdata response, come to think of it. Was just stuck in the order buffer for a while.
12:55 asciilifeform ( when requested, added to list; when received, is interned into db; and if recv'd again subseqently, marked dupe and similarly not rebroadcast )
12:55 asciilifeform a
12:58 awt no way to know right now if a) message somehow originated twice from dulapbot (unlikely) or b) broadcast from asciilifeform's station to some peer, then reflected back later to ...
12:59 awt asciilifeform's station
12:59 awt and somehow not yet in the long buffer at that point.
12:59 asciilifeform awt: this'd fall under dupe, neh?
13:00 awt is dulapbot peered with another station?
13:00 asciilifeform awt: peered w/ asciilifeform & billymg's 2 bots currently
13:02 awt ah ok so likely your station would have received a dupe via billymg or some other station.
13:02 asciilifeform possibly, but dupes in theory oughta vanish rather than keep jumping
13:03 asciilifeform the 1 case where not, is when 1) it aint a getdata response + 2) from receiver's pov it aint a dupe (1st time station sees $msg)
13:03 awt obviously should vanish, obviously didn't
13:03 asciilifeform aha
13:04 awt in this case the message was likely in the order buffer of all dulapbot peers for a while before being stored in the long buffer and rebroadcast.
13:07 awt because either the self or net chain for that message was broken
~ 51 minutes ~
13:58 phf well, there's an obv failure point here (ignoring the whys and the hows of the original sin): awt's station rebroadcast same message twice and the delay between messages was >10m
13:59 phf http://logs.nosuchlabs.com/log/pest/2022-07-25#1010586 << http://logs.nosuchlabs.com/log/pest/2022-07-25#1010568 that's the entirety of the story (i've seen dupes like that before, but this is first time i took note of it)
13:59 dulapbot Logged on 2022-07-25 12:03:21 awt[asciilifeform]: http://logs.bitdash.io/pest/2022-07-25#1010349 << how often are you getting dupes? Any shared characteristics of the dupes?
13:59 bitbot Logged on 2022-07-25 10:56:15 phf[awt]: like for example why did i get a dupe of dulapbot packets. i'm only connected to one station, so that stations filtering ought to not retransmit
13:59 dulapbot Logged on 2022-07-25 10:24:47 phf[asciilifeform]: http://glyf.org/screenshots/pest-packets.png
14:04 phf the weirdness i think is actually with dulapbot, because more often than not, when i send something that requires his response, i get a bunch of getdata messages
14:05 phf but i don't have any further insight into things. i'm mostly observing the state of pest net for my own benefit
14:13 asciilifeform phf: dulapbot defo behaves peculiarly at times; less so nao than prev. when was only peered via asciilifeform
14:13 asciilifeform but even nao periodically 'sits on' msgs for coupla min
14:14 * asciilifeform still not instrumented own station to find why still periodically dies on utfism; tho, peculiarly, not seen this effect on dulapbot's
~ 23 minutes ~
14:38 phf http://glyf.org/screenshots/pest-fonts-and-colors.png
14:38 asciilifeform nifty
~ 55 minutes ~
15:34 phf crashed and lost my packets :(
~ 3 hours 28 minutes ~
19:03 whaack !e view-height
19:03 trbexplorer block_height: 746530
19:03 trbexplorer mins_since_last_block: -2
~ 28 minutes ~
19:31 awt I probably won't spend too much time debugging this particular dupe, since it's related to the order buffer, which is slated for removal.
~ 1 hours 34 minutes ~
21:06 mod6 wb
~ 1 hours 11 minutes ~
22:18 asciilifeform wb mod6
22:24 phf http://logs.nosuchlabs.com/log/asciilifeform/2022-07-25#1112234 << it only makes sense for their to be a control message that announces data, an equivalent of a torrent record, that allows to initiate a transfer mechanism that's otherwise completely different from pest broadcast operation
22:24 dulapbot (asciilifeform) 2022-07-25 asciilifeform: jonsykkel: signpost did not yet post his scheme, but asciilifeform assumed that transfer would begin with e.g. a series of (chained) msgs giving hashes of, say, 1MB slices. then transfer 1 at a time
22:24 asciilifeform phf: obv. correct
22:25 asciilifeform phf: given that luby convergence aint deterministic, also would make sense to define a 'stop, we're done'
22:26 asciilifeform (and an interval after which transmitter stops regardless)
22:27 phf i haven't read the paper yet, i somehow missed the part where signpost picked this particular direction up
22:28 * asciilifeform considers that there aint any point to attempting lubyism b/w l2+; it oughta be strictly b/w peers, otherwise threatens to get ridiculously bw-hungry and complicated
22:29 asciilifeform phf: was originally his suggestion, but nfi where he currently is re subj
22:29 * asciilifeform must bbl
22:29 phf why not torrent
22:32 phf i only briefly looked into relationship between fountain codes and torrent protocol, and not knowing either don't have much to add to conversation yet. my initial guess was that one can probably significantly simplify torrent protocol, when knowing topology of trusted counterparties. but maybe not.
~ 1 hours 3 minutes ~
23:35 * crtdaydreams recalls
23:35 crtdaydreams http://logs.nosuchlabs.com/log/pest/2022-07-25#1010637 << when mentioned earlier, flamed
23:35 dulapbot Logged on 2022-07-25 22:29:37 phf[asciilifeform]: why not torrent
23:35 dulapbot (asciilifeform) 2022-03-21 crtdaydreams: re DHT/PEST: perhapse we could utilize some form of bittorrent while wrapping i.e. a tracker in pest?
23:35 dulapbot (asciilifeform) 2022-03-21 signpost: time to stop trying to satisfy your urges by making noise, and read *deeply* the pest spec, all of loper-os, and come back with questions or not at all.
← 2022-07-24 | 2022-07-26 →