Show Idle (>14 d.) Chans
← 2022-07-24 | 2022-07-26 → ↓
asciilifeform: $ticker btc usd
busybot[asciilifeform]: Current BTC price in USD: $21920.93
phf[asciilifeform]: http://logs.nosuchlabs.com/log/asciilifeform/2022-07-25#1112217 << reddit knowledge is required to make online points, not actually make products
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 oblig. naggum : what do you have that threatens to 'be large code base' ? (maybe wait until the problem actually
phf[asciilifeform]: hmm, strangely i didn't get dulapbot packet. possibly will arrive, but it's already been a minute and it's still not here
phf[asciilifeform]: and now i'm getting a bunch of getdata packets (which i'm at the moment not responding to)
phf[asciilifeform]: 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…
phf[asciilifeform]: and *now* i got dulapbot's quote
phf[asciilifeform]: so 10:12 to 10:19 est, that's 7 minutes
phf[asciilifeform]: lol and a few minutes later a dupe arrives of that same dulapbot packet
phf[asciilifeform]: 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
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
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)
phf[asciilifeform]: 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"
asciilifeform: could approximate this by asking folx for debug log snippets (lemme know if need one)
asciilifeform: iirc at one point awt had his 'live' to www
phf[asciilifeform]: well, the interesting question is probably "how did that packet end up here" at different times
asciilifeform: phf: as asciilifeform currently understands, 100% of the odd delays in messages currently are from hearsay buffering
phf[asciilifeform]: 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
phf[asciilifeform]: asciilifeform, yeah, i figured it's hearsay, but why ~7 minute delay~. that's quite obv longer than hearsay spool
phf[asciilifeform]: and then another 3 minutes pass and i get a dupe
asciilifeform: aha, makes no obvious sense per asciilifeform's head model
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
asciilifeform: so logically this kinda thing has to be a blattaism
awt[asciilifeform]: I'm seeing this morning a large dump of old dulapbot log quote messages. Looks like somehow the clog was cleared.
awt[asciilifeform]: http://logs.bitdash.io/pest/2022-07-25#1010349 << how often are you getting dupes? Any shared characteristics of the dupes?
bitbot[asciilifeform]: 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
awt[asciilifeform]: Perhaps there's a case where a getdata response is received and rebroadcast multiple times before it makes it into the long buffer.
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)
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)
awt[asciilifeform]: blatta marks "expected" messages aka getdata responses and at least tries not to rebroadcast them.
asciilifeform: awt: seems that it'd be simple to unambiguously identify'em, neh
awt[asciilifeform]: 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.
asciilifeform: ( when requested, added to list; when received, is interned into db; and if recv'd again subseqently, marked dupe and similarly not rebroadcast )
awt[asciilifeform]: 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 ...
awt[asciilifeform]: asciilifeform's station
awt[asciilifeform]: and somehow not yet in the long buffer at that point.
asciilifeform: awt: this'd fall under dupe, neh?
awt[asciilifeform]: is dulapbot peered with another station?
asciilifeform: awt: peered w/ asciilifeform & billymg's 2 bots currently
awt[asciilifeform]: ah ok so likely your station would have received a dupe via billymg or some other station.
asciilifeform: possibly, but dupes in theory oughta vanish rather than keep jumping
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)
awt[asciilifeform]: obviously should vanish, obviously didn't
awt[asciilifeform]: 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.
awt[asciilifeform]: because either the self or net chain for that message was broken
phf[asciilifeform]: 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
phf[asciilifeform]: 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)
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?
dulapbot: Logged on 2022-07-25 10:24:47 phf[asciilifeform]: http://glyf.org/screenshots/pest-packets.png
bitbot[asciilifeform]: 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
phf[asciilifeform]: 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
phf[asciilifeform]: but i don't have any further insight into things. i'm mostly observing the state of pest net for my own benefit
asciilifeform: phf: dulapbot defo behaves peculiarly at times; less so nao than prev. when was only peered via asciilifeform
asciilifeform: but even nao periodically 'sits on' msgs for coupla min
asciilifeform still not instrumented own station to find why still periodically dies on utfism; tho, peculiarly, not seen this effect on dulapbot's
phf[asciilifeform]: crashed and lost my packets :(
whaack[asciilifeform]: !e view-height
trbexplorer[asciilifeform]: block_height: 746530
trbexplorer[asciilifeform]: mins_since_last_block: -2
awt[asciilifeform]: 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.
asciilifeform: wb mod6
phf[asciilifeform]: 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
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
asciilifeform: phf: obv. correct
asciilifeform: phf: given that luby convergence aint deterministic, also would make sense to define a 'stop, we're done'
asciilifeform: (and an interval after which transmitter stops regardless)
phf[asciilifeform]: i haven't read the paper yet, i somehow missed the part where signpost picked this particular direction up
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
asciilifeform: phf: was originally his suggestion, but nfi where he currently is re subj
asciilifeform must bbl
phf[asciilifeform]: why not torrent
phf[asciilifeform]: 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.
dulapbot: Logged on 2022-07-25 22:29:37 phf[asciilifeform]: why not torrent
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?
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 → ↑
Random(pest) | Download hourly DB snapshot | Get Source Code